Linux systemd サービス管理ガイド｜自作サービスの作成と管理

はじめに：2026 年における自作サーバーと systemd の重要性

2025 年から 2026 年にかけて、自宅や小規模オフィスでのサーバー構築は、単なる趣味の範疇を超え、重要なインフラとして定着しました。特に高性能な自作 PC を活用したホームラボ環境では、Linux OS を採用するケースが急増しています。本ガイドでは、Ubuntu 24.04 LTS、Fedora 41、Debian 13、Rocky Linux 9 など、主要なディストリビューションで標準的に採用されている init システム「systemd」のサービス管理について、初心者から中級者までが実践的に理解できるよう徹底的に解説します。

近年の自作サーバー環境は、AMD Ryzen 9 9950X や Intel Core i7-14700K といった高コアプロセッサを搭載し、ASRock Rack X870D4U のようなワークステーションマザーボードや、Minisforum MS-01、Intel NUC 13 Pro のようなコンパクトな SFF システムまで多岐にわたります。これらの高性能ハードウェアを有効活用するためには、OS がリソースを適切に管理し、アプリケーションを安定して起動・停止させる仕組みが不可欠です。systemd はその中核となるコンポーネントであり、2026 年現在では Linux デスクトップおよびサーバーの事実上の標準となっています。

本記事では、 systemd の基本概念から具体的な設定ファイルの作成、依存関係の管理、リソース制限、ログ解析までを網羅します。特に、Node.js や Bun を用いた Web アプリケーションの常駐化や、Docker Compose を使用したコンテナ環境の自動起動など、現代の開発ワークフローに即した実践例を取り上げています。また、128GB ECC DDR5 メモリを搭載するハイスペックサーバーと、省電力タイプの NUC システムの間で、systemd の設定がどのように最適化されるべきかという観点も交えながら、信頼性の高いガイドを作成しました。

systemd の基本概念：ユニット、ターゲット、スライス、スコープ

systemd を理解する上でまず押さえるべきは、その構成要素である「ユニット（Unit）」の概念です。systemd においては、起動するプロセス、監視対象のリソース、さらにはシステムの状態自体までがすべて「ユニット」という単位で定義されます。2026 年時点では、cgroup v2 の完全実装に伴い、このユニット管理の粒度はより細かくなっています。例えば、AM5 プラットフォーム上で動作する PostgreSQL データベースプロセスや Redis キャッシュサービスも、それぞれが独立的な systemd ユニットとして定義されます。

「ターゲット（Target）」は、ユニットをグループ化した概念で、Linux の SysVinit でいう「runlevel」に相当しますが、より柔軟な階層構造を持っています。Ubuntu 24.04 LTS や Fedora 41 では、multi-user.target がマルチユーザーモードの起動点として標準的に定義されています。システムが完全に起動し、ネットワークやローカルファイルシステムが利用可能になった状態を意味します。自作サーバーで Web サービスを公開する際、システムが multi-user.target に到達した後にサービスが開始されるように設定することで、ネットワーク接続が確立された状態でリクエストを受け取れるようになります。

「スライス（Slice）」と「スコープ（Scope）」は、リソースの管理単位として重要です。スライスは、複数のユニットをグループ化して、CPU やメモリなどのリソースを束ねて管理するための機能です。例えば、自作サーバー内で動作する Docker コンテナ群を docker.slice に割り当てることで、システム全体の安定性を保ちつつ、特定の VM へのリソース配分を調整できます。スコープは、systemd が管理しない外部プロセス（例：Docker 内部のプロセスや手動起動したスクリプト）を追跡・管理するために使用されます。Ryzen 9 9950X のような高コア CPU を使用する環境では、スライスを活用してバックグラウンドタスクとフロントエンド処理のリソース競合を防ぐことが推奨されています。

systemd のアーキテクチャは、並列起動を可能にすることで Linux のブート時間を大幅に短縮しています。2026 年における最新ディストリビューションでは、この並列処理をより効率的に行うために、依存関係の解析が高度化されています。ユーザーや管理者は、これらの概念を深く理解することで、複雑なサーバー環境でも安定した運用が可能となります。特に、ECC メモリを採用するサーバー環境では、メモリ関連のユニット管理（cgroup v2 を介して）に注意を払うことで、メモリエラーによるクラッシュを防ぐことができます。

サービスユニットファイルの作成：[Unit]、[Service]、[Install] 構造

systemd でサービスを定義するには、 /etc/systemd/system/ ディレクトリ下に独自の unit ファイルを作成する必要があります。このファイルは INI 形式で記述され、主に [Unit]、[Service]、[Install] の 3 つのセクションから構成されます。各セクションには特定の役割があり、これらを適切に設定することで、システムが要求される動作を正確に実行します。Ubuntu 24.04 LTS や Debian 13 では、このファイル構造はほぼ共通しており、Fedora 41 でも同様の書式が採用されています。

[Unit] セクションでは、サービス自身の説明や依存関係を定義します。Description ディレクティブでサービス名を記述し、After= や Requires= で起動順序や必須依存を設定します。例えば、データベースが起動する前にネットワークが確立されている必要がある場合、After=network.target を設定します。また、2026 年時点ではセキュリティ強化のため、Wants= を使用して非必須のサービスも宣言的に依存させることが推奨されます。このセクションはサービスの「アイデンティティ」を定義する部分であり、システム起動ログで表示される内容に直接影響を与えます。

[Service] セクションが最も重要で、実際のプロセス起動パラメータを設定します。ExecStart= で起動コマンドを指定し、WorkingDirectory= で作業ディレクトリを定義します。再起動ポリシーは Restart= ディレクティブで制御でき、always に設定するとサービスが終了した際に自動的に再起動されます。また、User= と Group= で実行権限を持つユーザーとグループを制限し、セキュリティリスクを低減します。自作サーバーのような専用環境では、root として実行するのではなく、専用のサービスアカウント（例：www-data や nodejs-user）を使用することが強く推奨されます。

[Install] セクションでは、どのターゲットにこのサービスを開始するようリンクするかを指定します。通常は WantedBy=multi-user.target を設定することで、システム起動時に自動的にサービスが開始されるようになります。2026 年現在では、より粒度の細かいターゲット（例：graphical.target や特定のネットワーク状態）への依存もサポートされています。また、Alias= を指定することで、サービス名の別名を設定することも可能です。このファイルを作成後、systemctl daemon-reload を実行して設定を読み込ませる必要があります。

systemctl コマンドの活用とデバッグ技巧

systemd の管理には systemctl コマンドが使用されますが、単にコマンドを覚えるだけでなく、その出力やオプションの意味を理解することがトラブルシューティングにおいて重要です。Ubuntu 24.04 や Rocky Linux 9 では、このコマンドはシステム管理者にとって必須のツールです。基本的な操作としては、サービスの起動（start）、停止（stop）、再起動（restart）がありますが、これらは一時的な変更であり、永続的な設定には enable と disable を使用します。

systemctl status <service_name> は、サービスが現在どの状態にあるかを確認するための最も重要なコマンドです。出力には、サービスの PID（プロセス ID）、起動時間、現在のステータス（running、failed、inactive 等）が表示されます。特に、Ryzen 9 9950X のような高性能 CPU を使用するサーバーでは、システムリソースの消費状況も同時に確認できるため、パフォーマンス監視にも活用できます。2026 年版の systemd では、このステータス表示に cgroup v2 の詳細情報が追加されており、メモリ使用量や CPU クォータの使用率がリアルタイムで参照可能です。

systemctl daemon-reload は、unit ファイルの変更を systemd に反映させるために必須です。設定ファイルを書き換えた後にこれを省略すると、変更が適用されず、エラーが発生します。また、systemctl restart <service_name> を使用してサービスを再起動する際、デバッグモード（-d）を組み合わせて実行することも可能です。ただし、本番環境での -d 使用はログ量が増大するため注意が必要です。Minisforum MS-01 のようなコンパクトマシンでは、メモリ消費を抑えるためにも、定期的なリロードや再起動の自動化が求められます。

ログの確認には journalctl を併用します。systemctl status で表示されるログの一部は簡易的なものであり、詳細な履歴を確認するには journalctl -u <service_name> が便利です。また、サービスの起動に失敗した場合の根本原因を特定するために、--no-pager オプションや -f（フォロウ）を使用します。Fedora 41 では、このログ管理機能がさらに強化されており、特定のキーワードでのフィルタリングが高速化されています。自作サーバー環境では、これらのコマンドを組み合わせることで、24 時間稼働するサービスの安定性を維持できます。

依存関係の管理：Requires、Wants、After、Before の違い

systemd の真価は、複雑な依存関係を柔軟に定義できる点にあります。[Unit] セクションで設定されるディレクティブには、Requires=、Wants=、After=、Before= がありますが、これらは似ているようで意味が異なります。2026 年時点の systemd では、これらの挙動は厳密に定義されており、誤った設定がシステム起動の遅延や依存ループを引き起こす可能性があります。特に、複数のサービス間で順序を制御する必要がある場合、慎重な設定が必要です。

Requires= は強力な依存関係を示します。指定されたユニットが存在しない、または起動できない場合、現在のサービスも起動しません。これは必須依存であるため、データベース接続が必要で、DB サーバーが起動していないとアプリが動作しないケースなどで使用されます。一方、Wants= はより弱いつながりを示し、依存するサービスが起動しなくても、自分のサービスは起動を試みます。例えば、ログ出力用のバックアップサービスは必須ではないため、Wants= で宣言することが推奨されます。

After= と Before= は起動順序を制御します。これらは依存関係そのものではなく、開始のタイミングを示すものです。After=network.target を設定することで、ネットワークが準備されるまでサービスを待機させます。2026 年では、cgroup v2 の実装により、リソースロックが必要なサービス間の順序付けも考慮されています。Requires= と After= を組み合わせることで、「DB が起動してから（Wants）、かつ DB 起動完了後に（After）」アプリを起動させるといった制御が可能になります。

自作サーバーの ASRock Rack X870D4U のような環境では、ハードウェアの初期化順序が複雑になることがありますが、systemd はこれを抽象化して管理します。ただし、ネットワークインターフェースの再起動や、外部ストレージのマウント順序において、After= と Before= を適切に設定しないと、サービス起動時のエラーが発生する可能性があります。特に Docker コンテナを多用する場合、docker.service の依存関係設定は慎重に行う必要があります。

BindsTo= は、依存するユニットが停止すると自身のサービスも停止するように設定する強力な機能です。これは、スコープ（Scope）ユニットや外部プロセスとの連携時に使用されます。Ryzen 9 9950X のような高負荷環境では、リソース競合を防ぐためにも、関連サービス間の結合を明示的に定義しておくことが推奨されています。依存関係を管理する際には、systemctl list-dependencies <service_name> コマンドを使って現在設定されている依存グラフを確認し、意図しないループや欠落がないかを検証することが重要です。

systemd タイマーユニットによるスケジュール管理の最適化

cron の代わりに systemd タイマーを使用することで、Linux サーバーでのタスクスケジューリングをより柔軟かつ統一的に管理できます。2026 年現在では、systemd timer は cron よりも優れていると評価されるケースが多く、特にリソースの自動起動や停止、イベント駆動型の処理に適しています。OnCalendar= による特定の時刻での実行だけでなく、OnBootSec= によるシステム起動からの相対時間指定、OnUnitActiveSec= による前回のアクティブ化からの間隔指定など、多様なトリガーが可能です。

[Timer] セクションでは、主に OnCalendar と Persistent が重要になります。OnCalendar の構文は cron のような形式ですが、より直感的な記述が可能で、例えば OnCalendar=*-*-* 03:00:00 で毎日午前 3 時に実行されるように設定できます。また、Fedora 41 や Ubuntu 24.04 LTS では、この構文の拡張がサポートされており、Mon Tue Wed のような曜日指定も容易です。自作サーバーで定期的なバックアップやログローテーションを行う場合、この機能は非常に有用です。

OnBootSec= を使用すると、システム起動後、例えば 5 分後にタスクを開始するといった設定が可能です。これは、サービスが完全に起動したことを待ってから実行する必要がある場合に便利です。また、Persistent=true を設定することで、スケジュールを逃した場合に次回実行時に遅延なく追従させることができます。Minisforum MS-01 のような省電力デバイスでは、スリープ復帰後のタスク実行を確実にするため、このオプションが重宝されます。

cron との違いとして、systemd タイマーはサービスユニットとペアになることで、実行結果のログをジャーナルに記録しやすくなっています。journalctl -u <timer_name> で履歴を確認できます。また、2026 年では、このタイマー機能を使ってバックグラウンドタスクを管理する例が多数見られます。特に、バックアップスクリプトやデータベースの定期メンテナンスは、cron よりも systemd タイマーで管理する方が、サーバーの状態との整合性が取りやすくなります。

リソース制限と cgroup v2 連携によるパフォーマンス制御

最新の Linux ディストリビューションでは、cgroup v2 が標準採用されており、systemd を介してリソース制限をより効率的に適用できます。自作サーバー環境で、1 つのサービスがすべてのリソースを消費してしまうのを防ぐため、MemoryMax= や CPUQuota= などのディレクティブを使用します。これは、Intel NUC 13 Pro のようなリソース制約のあるマシンや、高密度な VM/コンテナ環境において不可欠です。

[Service] セクション内で設定する MemoryMax= は、プロセスが使用できる最大メモリ量を指定します。この値を超えると、プロセスは終了（OOM キラー）させられます。ASRock Rack X870D4U のような 128GB ECC メモリを搭載したサーバーでは、各サービスに適切な制限を設けることで、メモリ不足によるシステム全体のフリーズを防ぎます。また、CPUQuota= は CPU リソースの使用率を制限し、例えば 50% に設定すると、そのプロセスは利用可能な CPU 時間の一半しか使えなくなります。

IO 関連の制限として、IOWeight= が利用可能です。これはディスクへの読み書きの優先度を制御します。データベースサービスに高いウェイトを設定することで、バックアップ処理との競合を避けられます。2026 年現在では、cgroup v2 の完全実装により、このリソース管理はより正確に行われています。また、DevicePolicy= を使用して、特定のデバイスへのアクセス権限も制御可能です。

これらの設定は、systemd-run --scope --memory-limit=... コマンドで直接実行する際にも適用可能です。しかし、unit ファイルに記述することで、永続的な管理が可能になります。特に、Node.js や Bun を使用した Web アプリケーションでは、メモリリークを防ぐための上限設定が有効です。ECC メモリを使用している場合でも、ハードウェアの故障リスクはゼロではないため、ソフトウェアレベルでの保護策を講じることが推奨されます。

journalctl を用いたログ管理とローテーション設定

システムトラブルシューティングにおいて、systemd のログ機能である journalctl は最も強力なツールです。2026 年現在、すべての systemd サービスの標準的なロギング先はジャーナルであり、従来の syslog（rsyslog や syslog-ng）との併用や移行が進んでいます。journalctl を使用すると、特定のサービスの起動履歴やエラーログを詳細に確認できます。

-u オプションを使用することで、特定のサービスに関連するログのみを抽出できます。また、--since と --until によって時間範囲を指定し、特定時点のログのみを表示できます。2026 年の最新版 systemd では、このフィルタリング機能に AI による異常検知が組み込まれる予定もありますが、現時点では手動でのキーワード検索や正規表現によるフィルタリングが主流です。Minisforum MS-01 のような低消費電力マシンでは、ログの保存容量を最適化するため、頻繁なローテーション設定が必要です。

ジャーナルログの回転設定は /etc/systemd/journald.conf で行います。SystemMaxUse= を指定することで、ディスク上のジャーナルデータが占める最大サイズを制限できます。例えば 500M に設定すると、超過した古いログは自動的に削除されます。また、Storage=persistent とすることで、再起動後もログデータを保存し続けます。これは、トラブル発生時の原因特定において重要な機能です。

ログの保存形式はバイナリであるため、テキストファイルとして直接アクセスできません。journalctl -o cat を使用することで、生のテキスト形式で出力できます。また、--no-pager を指定すると、ページャー（less など）を介さずに直接ストリーム出力されるため、スクリプトからの取得が容易です。自作サーバーでは、このログ管理機能を自動化して、特定のエラーが発生した際に Slack 通知を送るなどの統合も可能です。

Node.js と Docker Compose の実践的なサービス化事例

ここからは具体的な例として、Node.js ベースの Web アプリと Docker Compose を使用した環境を systemd サービスとして定義する方法を紹介します。2026 年現在、Bun や Deno も利用可能ですが、Node.js は最も互換性が高く、systemd との連携が確立されています。

まず、Node.js アプリの場合、アプリケーションディレクトリに unit ファイルを作成します。/etc/systemd/system/myapp.service に以下のような設定を記述します。ExecStart で Node のパスを指定し、WorkingDirectory をアプリのルートディレクトリに設定します。また、環境変数を EnvironmentFile= で管理することで、.env ファイルの内容を systemd に読み込ませます。

[Unit]
Description=My Node.js Web Application
After=network.target
Wants=postgresql.service

[Service]
Type=simple
User=nodejs
Group=nodejs
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node index.js
Restart=always
EnvironmentFile=/etc/myapp/env.conf

[Install]
WantedBy=multi-user.target

この設定により、systemctl enable myapp.service と start を実行するだけで、常にバックグラウンドで動作するようになります。Node.js の場合は、プロセスが終了しても自動的に再起動するため、2026 年のサーバー運用においては必須の設定です。また、Bun を使用する場合も同様に ExecStart=/usr/bin/bun run index.js と書き換えるだけで対応可能です。

Docker Compose を systemd サービス化する場合は、コンテナの起動と停止を systemd に委ねます。Ubuntu 24.04 では docker-compose コマンドが標準パッケージ化されています。unit ファイルでは ExecStart=/usr/bin/docker compose up -d を設定し、依存関係として network-online.target を指定します。これにより、ネットワーク接続が確立された後にコンテナスタックが立ち上がります。

また、ASRock Rack X870D4U のようなサーバーで Docker を使用する場合、Restart=always を設定することで、システム再起動後やコンテナクラッシュ時に自動的に復旧されます。ただし、Docker 自体の起動順序に注意が必要です。Requires=docker.service と After=docker.service を設定し、Docker デーモンが確実に起動した後にアプリケーションコンテナを起動するようにします。

よくある質問（FAQ）

Q1. systemd サービスを無効にした後でも、手動で再起動すると自動的に有効になりますか？ A1. いいえ、systemctl disable で削除された設定は永続的に無効化されます。手動実行（start）は一時効果があるのみで、システム再起動後に再び無効な状態に戻ります。

Q2. 依存関係のループを検出する方法はありますか？ A2. systemctl list-dependencies --reverse <service_name> を使用して逆方向の依存を確認できます。また、daemon-reload 実行時に警告メッセージが表示されることがあります。

Q3. journalctl のログ容量を制限しても、現在のデータは削除されますか？ A3. はい、journald.conf で設定した SystemMaxUse を超えた場合、最新のログを優先して古い順に削除します。これは自動的に実行されるため、手動でのクリーンアップは不要です。

Q4. cgroup v2 と v1 のどちらが推奨されますか？ A4. 2026 年現在では、Ubuntu 24.04 や Fedora 41 では v2 がデフォルトであり、v2 を使用することを強く推奨します。v1 は互換性のために残されていますが、機能制限があります。

Q5. Docker コンテナ内で systemd を起動できますか？ A5. 原則として推奨されません。コンテナはプロセス単位で管理されるべきですが、特殊なケース（例：システム監視ツール）では --privileged 権限を付与して可能になります。

Q6. サービスの起動順序を調整するにはどうすればよいですか？ A6. [Unit] セクション内の After= を使用します。例えば、データベースが先に必要な場合、After=database.service と記述します。

Q7. systemd のログをテキストファイルとして保存する方法はありますか？ A7. 不要な場合を除き推奨されませんが、journalctl -o cat > /var/log/app.log で出力し、rsyslog や cron を使って書き込み管理を行うことができます。

Q8. CPUQuota を設定しても CPU が最大速度で動作しないのはなぜですか？ A8. 正確に指定された比率しか CPU 時間を与えられないためです。高負荷タスクでは、この制限により処理が待機状態になることがあります。

Q9. systemd タイマーで Cron のような毎日の実行を設定できますか？ A9. はい、OnCalendar=daily と設定することで、Cron の @daily と同様の動作を実現できます。より詳細な時刻指定も可能です。

Q10. 自作サーバーでメモリ使用量を監視するために systemd を利用できますか？ A10. はい、systemctl status -l myservice で現在のメモリ使用量を確認できます。また、cgroup v2 を介してリアルタイムの監視が可能です。

まとめ

本記事では、Linux systemd サービス管理の基礎から応用までを詳しく解説しました。2026 年の自作サーバー環境において、systemd は不可欠なインフラコンポーネントです。Ubuntu 24.04 LTS や Fedora 41 を使用する場合でも、基本的な概念は共通しており、ASRock Rack X870D4U のような高性能サーバーから Minisforum MS-01 のような省電力マシンまで幅広く対応可能です。

記事の要点を以下にまとめます：

• systemd はユニット（.service）、ターゲット、スライスで構成される管理システムである
• unit ファイルは [Unit]、[Service]、[Install] 3 セクションで定義する
• systemctl コマンドを用いてサービスの起動・停止・設定変更を行う
• Requires= と Wants= で依存関係を制御し、順序を After= で指定する
• systemd タイマーは Cron よりも柔軟にタスクスケジューリングが可能
• cgroup v2 を活用してリソース制限（MemoryMax, CPUQuota）を設定できる
• journalctl でログ管理を行い、journald.conf でローテーション設定を行う

これらの知識を駆使することで、安定した自作サーバー環境を構築し、Node.js や Docker などのアプリケーションを効率的に運用できます。2026 年以降も Linux の進化は続くため、常に最新情報をキャッチアップしながら運用することが重要です。