systemdサービス定義ファイルと関連ディレクトリの設計についての考察
1. はじめに
せっかく作ったアプリケーション、毎回コマンドを叩いて起動するのではなくサービスとして自動起動したくなりますよね。
Linuxでサービスを常駐させる仕組みは、現在ではほぼ全てのディストリビューションでsystemdが採用されています。systemdサービス定義ファイルの配置場所や関連ディレクトリの整理方法を理解しておくと、運用やトラブルシューティングの際に大きな助けになります。
本記事では、RockyLinux9(RHEL系)を基準に解説しますが、Ubuntu(Debian系)など他のディストリビューションでも基本的な考え方は共通かと思います。
2. サービス定義ファイルの配置場所
systemdではサービス定義ファイル(.service)の配置場所によって役割が分かれています。
/usr/lib/systemd/system/… パッケージ標準で提供されるサービス定義/etc/systemd/system/… システム管理者が上書き・追加するサービス定義/etc/systemd/system/<unit>.d/… ドロップイン設定（部分的な上書きや追加）
基本的な理解として「OSやOS標準パッケージ由来のファイルは/usr/lib、システム管理者が編集する可能性があるファイルは/etcの配下」と覚えておくと良いかと思います。
3. サービス定義ファイルの命名規則の指針
systemdのサービス定義ファイル(.service)は、配置場所だけでなくファイル名の付け方も運用効率に大きな影響を与えます。特に自作アプリや社内システムの場合、一貫性のある命名規則を決めておくことが重要です。
筆者の環境では自作アプリ・社内システムのサービス実行ユーザは以下の基本方針に従って命名しています。
「絶対にこうでなくてはならない」というものではないのですが、実際に長年運用しながら調整をしてきた結果、この方針に落ち着きました。
※ .service以外にも.socket、.timerといったサービス定義ファイルの形式がありますがここでは.serviceについて記述します。
- 小文字・半角英数字で統一する。
- 外部ベンダ提供アプリは
<vendor>-<app>.service（例：xvendor-sfa.service） - 自作アプリ・社内システムは<vendor>を社名やプロジェクト名などに置き換える。
- 複数のインスタンスを立ち上げるサービスはテンプレートユニットの活用を検討する。
例えば自作アプリでgunicornを複数立ち上げる場合はgunicorn-<vendor>-@<app>.service
4. サービス実行ユーザとの関係
systemdサービスファイル内ではUser=ディレクティブでサービス実行ユーザを指定できます。
ここで2本目の記事で紹介したサービス実行ユーザ命名規則を適用すれば、サービスとユーザの対応関係が一目で分かるようになります。
ユーザ名やディレクトリ構成を整理しておけば、テンプレートユニットを活用してサービス定義を一本化でき、個別ファイルを量産せずに済みます。
- OSSは既存の慣習ユーザを利用（例：
nginx、postgres） - 自作アプリ・社内システムは
<mycorp>-<app>（例：xcorp-crm） - 外部ベンダ提供アプリ用のユーザ名は
<vendor>-<app>（例：yvendor-sfa） - 自作アプリ・社内システム用のユーザ名は<vendor>を社名やプロジェクト名などに置き換える。
5. ログと設定ファイルの整理
自作アプリ・社内システムをsystemdでサービスとして起動する際は、ログや設定ファイルの配置も合わせてルール化しておくと管理が容易です。
例：
/var/log/<vendor>-<app>/にアプリ個別ログを出力する/etc/<vendor>/<app>/に設定ファイルを配置するExecStartのコマンドから上記を参照する形にする
こうしておくと、アプリケーションの構成が「systemdサービス定義・ユーザ・ログ・設定ファイル」で一貫し、誰が見ても理解しやすい構造になります。
6. まとめ
systemdサービス定義ファイルの配置は、Linuxサーバ運用の基本ルールのひとつです。
「/usr/libはOS標準、/etcはシステム管理者」という切り分けに従いつつ、サービス実行ユーザの命名規則やログ・設定ファイルの配置方針をセットで設計しておくと、長期運用での混乱を避けられます。
小さなルールづくりですが、障害調査やセキュリティ監査の際に「なぜそのように運用しているのか」を説明しやすくなり、結果的に大きなコスト削減につながります。