Systemdの習得：最初のカスタムサービスユニットファイルの作成

Systemdは、システムの起動初期化から実行中のユーザー空間サービスの管理まで、すべてを担う最新のLinuxディストリビューションで普及しているサービスマネージャーとなりました。カスタムユニットファイルの作成方法を理解することは、アプリケーションのデプロイを自動化し、サービスが正しく再起動することを保証し、独自プロセスをオペレーティングシステムのライフサイクルにシームレスに統合するための基本となります。

この包括的なガイドでは、Systemdサービスユニットファイルの基本的な構造を順を追って説明し、重要な[Unit]、[Service]、[Install]セクションを網羅します。このチュートリアルの終わりまでに、独自のカスタムサービスを定義、有効化、管理できるようになります。

前提条件

設定に入る前に、管理者権限（sudo）とLinuxファイルシステムに関する基本的な理解があることを確認してください。このガイドは、Systemdを使用している最新のディストリビューション（例：Debian、Ubuntu、Fedora、CentOS 7以降/RHEL 7以降）で作業していることを想定しています。

Systemdユニットファイルの理解

A Systemdユニットファイルは、Systemdによって管理されるリソースを記述するINIスタイルの設定ファイルです。サービスの場合、これらのファイルは通常、カスタムまたは管理者定義のサービスの場合は/etc/systemd/system/に、ベンダー提供のサービスの場合は/lib/systemd/system/に格納されます。

サービスユニットファイルは.serviceという拡張子で終わる必要があります（例：mydaemon.service）。構造は必須セクションとオプションセクションに分かれており、最も重要な3つが[Unit]、[Service]、[Install]です。

ステップ1：サービススクリプト（実行可能ファイル）の作成

ユニットファイルを作成する前に、サービスが管理する単純なスクリプトまたはアプリケーションが必要です。この例では、10秒ごとにメッセージをログに記録する基本的なスクリプトを作成します。

スクリプトのディレクトリとファイルの作成：

bash sudo mkdir -p /opt/my-custom-service sudo nano /opt/my-custom-service/reporter.sh
reporter.shに次のコンテンツを追加します：

```bash

!/bin/bash

LOG_FILE="/var/log/reporter.log"
while true; do
echo "$(date +'%Y-%m-%d %H:%M:%S') - Custom service heartbeat active." >> $LOG_FILE
sleep 10
done
```
スクリプトの実行権限を付与します：

bash sudo chmod +x /opt/my-custom-service/reporter.sh

ステップ2：カスタムサービスユニットファイルの定義

次に、Systemdにスクリプトをどのように実行させるかを伝えるSystemdユニットファイルを作成します。

サービスファイルの作成：

bash sudo nano /etc/systemd/system/my-reporter.service
ファイルに標準セクションを記述します：

[Unit]セクション

このセクションには、サービスに関するメタデータが含まれ、他のユニット（サービス、ソケット、マウントポイントなど）との関係を定義します。

Description: サービスの人間に読みやすい名前です。
After: リストされたユニットが正常に開始された後にのみ、このサービスを開始することを指定します。

[Unit]
Description=My Custom Reporter Daemon
# 基本的なネットワーキングおよびロギングサービスが動作した後でのみ開始
After=network.target

[Service]セクション

これはコアセクションであり、どのコマンドを実行するか、およびSystemdがプロセスをどのように管理するかを定義します。

Type: プロセスの起動タイプを定義します。継続的にフォアグラウンドで実行されるスクリプトの場合、simpleが標準です。
User/Group: プロセスを実行するユーザーコンテキストを指定します（セキュリティのために強く推奨されます）。
ExecStart: サービス起動時に実行されるコマンドまたはスクリプトの絶対パスです。
Restart: 自動再起動ポリシーを定義します（例：on-failure、always）。

[Service]
Type=simple
User=your_username # 重要：可能な限りroot以外のユーザーで'your_username'を置き換えてください
Group=your_group # オプション、通常はユーザーグループと一致します

# Systemdが実行するコマンド
ExecStart=/opt/my-custom-service/reporter.sh

# 再起動ポリシー
Restart=on-failure
RestartSec=5s # 再起動を試みる前に5秒待機
StandardOutput=journal # 出力をSystemdジャーナルにリダイレクト
StandardError=journal

セキュリティ警告： 必要な場合を除き、カスタムサービスをrootユーザーとして実行しないでください。アプリケーションプロセス専用の、権限が最小限のユーザーを定義してください。

[Install]セクション

このセクションは、サービスをどのように有効化するかを指定します。具体的には、どのターゲットにリンクさせ、起動時に自動的に開始させるかを指定します。

WantedBy: このサービスを取り込むターゲットを指定します。標準的なシステム起動時に開始すべき標準的なシステムサービスの場合、multi-user.targetが標準の選択肢です。

[Install]
WantedBy=multi-user.target

ステップ3：サービスの再読み込み、有効化、開始

ユニットファイルを作成または変更した後、Systemdに構成デーモンを再読み込みさせ、次に新しいサービスを管理するように指示する必要があります。

Systemdマネージャー構成の再読み込み：
ユニットファイルが追加または変更された場合は、この手順が必須です。

bash sudo systemctl daemon-reload
サービスの有効化（起動時の自動起動）：
これにより、適切なターゲットディレクトリ（例：multi-user.target.wants/）からサービスファイルへのシンボリックリンクが作成され、システム起動時に自動的に開始することが保証されます。

bash sudo systemctl enable my-reporter.service
出力でシンボリックリンクの作成が確認されます。
サービスの開始：
これにより、ExecStartで定義されたプロセスが即座に開始されます。

bash sudo systemctl start my-reporter.service

ステップ4：サービスの状態とログの確認

サービスが正しく開始され、意図どおりに実行されていることを確認することが重要です。

ステータスの確認：
statusコマンドは、現在の状態、最近のログ行、実行の詳細を提供します。

bash systemctl status my-reporter.service

出力でActive: active (running)を探してください。
ログの表示 (Journalctl)：
[Service]セクションでジャーナルにリダイレクトしたため、journalctlを使用して実行メッセージを確認できます。

bash journalctl -u my-reporter.service -f
ファイル出力の確認：
スクリプトで指定したログファイルを確認します：

bash tail -f /var/log/reporter.log

必須管理コマンド

定義されたら、systemctlコマンドを使用してサービス管理は簡単です。

アクション	コマンド
サービスの停止	`sudo systemctl stop my-reporter.service`
サービスの再起動	`sudo systemctl restart my-reporter.service`
自動起動の無効化	`sudo systemctl disable my-reporter.service`
ステータスの確認	`systemctl status my-reporter.service`

まとめと次のステップ

[Unit]、[Service]、[Install]セクションを習得することで、Systemdを使用して堅牢で管理されたサービスを正常に構築できました。この基盤により、複雑なアプリケーションのライフサイクルを管理し、信頼性の高い起動順序、障害発生時の自動再起動、Systemdジャーナルを介した一元化されたロギングを保証できます。

より高度なユースケースについては、設定読み込みのためのEnvironmentFileや、従来のデーモン管理のためのTypeをforkingに変更するなど、[Service]セクション内のオプションを探ってください。