【第6回】Linuxシステム管理の心臓部！systemdとサービス管理(systemctl)を完全攻略

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Linuxエンジニアになるための基礎」連載、第6回へようこそ。前回は top や ps コマンドを駆使して、サーバー内で暴走するプロセスを特定し、リソースを監視する技術を学びました。

今回は、Linuxインフラ管理において最も重要な機能である「サービス管理とデーモン（systemd / systemctl）」について、圧倒的な情報密度で解説します。サーバー上で動作するWebサーバーやデータベースなどのソフトウェアを、OSの起動と同時に立ち上げ、仮にクラッシュしても自動で復旧させる「自動化の心臓部」に迫ります。

---

第1章：すべてのプロセスの母「systemd」とデーモンの概念

サーバー上で24時間365日、ユーザーからの要求（リクエスト）を待ち受け続けるバックグラウンドプログラムのことを、Linuxの世界では「デーモン（Daemon）」と呼びます。Webサーバー（httpd/nginx）、データベース（mysqld）、SSHサーバー（sshd）など、末尾に「d」がつくプロセスはすべてデーモンです。

1-1. systemdの登場と革命

昔のLinux（CentOS 6以前）では、「SysVinit（シスブイイニット）」という仕組みでデーモンを管理していました。しかし、スクリプトを上から順番に1つずつ実行していくため、OSの起動に非常に時間がかかるという弱点がありました。

そこで AlmaLinux（RHEL 7以降）などのモダンなOSで標準採用されたのが「systemd」です。
systemdは、OSが起動した直後に立ち上がる「PID 1（プロセスIDの1番）」のプロセスであり、そこからネットワーク、ストレージ、各種デーモンを並列（非同期）に高速起動し、それらの依存関係を完璧に管理する「絶対的な支配者」です。

# システムのPID 1がsystemdであることを確認する
ps -p 1 -o comm=
# 出力結果: systemd

インフラエンジニアは、この systemd に対して命令を下すための専用コマンドである systemctl を駆使して、サーバー全体をコントロールします。

---

第2章：systemctlコマンドの基本（起動・停止・状態確認）

systemctl コマンドは、サービスの現在の状態を操作・確認するための最も基本的なインターフェースです。ここでは Nginx を例に解説します。

2-1. 状態の確認（status）

何かしらのサービスに異常を感じたら、まずは status を確認するのがプロの鉄則です。

# Nginxの現在の稼働状態と、直近のログを確認する
sudo systemctl status nginx

出力結果の中で必ずチェックすべきは Active: の行です。

• active (running): 正常に起動し、稼働中。
• inactive (dead): 停止している状態。
• failed: 何らかのエラーで起動に失敗、または異常終了した状態。

status コマンドが優れているのは、単に生死を確認するだけでなく、画面下部に「なぜ失敗したのか」を示す直近のログ（journaldからの抜粋）を一緒に表示してくれる点です。

2-2. 起動と停止（start / stop）

サービスを手動で起動、または停止させます。実行しても画面には何も表示されない（サイレント）のが正常な挙動です。

# サービスの起動
sudo systemctl start nginx

# サービスの停止
sudo systemctl stop nginx

---

第3章：自動起動の制御とプロのセキュリティ（enable / mask）

冒頭でコウ君が陥った「再起動したらWebサイトが見れなくなった」という問題は、自動起動（OSブート時の起動登録）を行っていなかったことが原因です。

3-1. 自動起動の有効化と無効化

パッケージマネージャ（dnfなど）でソフトウェアをインストールした直後は、基本的に自動起動は「無効」になっています。サービスを本番稼働させる際は、必ず enable コマンドを実行します。

# OS起動時に自動で立ち上がるように設定する（シンボリックリンクが作成される）
sudo systemctl enable nginx

# 自動起動を解除する
sudo systemctl disable nginx

# 現在、自動起動が有効になっているかを確認する
systemctl is-enabled nginx
# 出力結果: enabled または disabled

3-2. 究極の封印魔法「mask」によるセキュリティ対策

サーバー内に複数の似たような機能を持つソフトが存在する場合、誤って起動してしまうとシステムが破壊されることがあります。
例えば、AlmaLinuxの標準ファイアウォールは firewalld ですが、高度な要件で iptables や nftables を直接使いたい場合、firewalld が裏で勝手に起動するとルールが競合して通信が完全に遮断されます。

単なる disable では、他のサービスから呼ばれた際（依存関係）に起動してしまう可能性があります。これを完全に防ぐのが mask コマンドです。

# サービスを「/dev/null」にリンクし、手動でも絶対起動できないように完全封印する
sudo systemctl mask firewalld

# 封印を解く場合
sudo systemctl unmask firewalld

この mask を使いこなせるようになれば、セキュリティ監査にも耐えうる堅牢なシステム構築が可能になります。

---

第4章：無停止反映！restart と reload の決定的な違い

設定ファイル（例：/etc/nginx/nginx.conf）を書き換えた後、その設定をプロセスに読み込ませる必要があります。初心者は何も考えずに restart を使いますが、プロの現場（本番環境）において、不用意な restart は「システム障害（ダウンタイム）」を引き起こす危険行為です。

4-1. restart（再起動）：プロセスの強制的な殺戮と再生

systemctl restart は、内部的に「プロセスを完全に停止（kill）し、ゼロから新しいプロセスを起動する」という動作をします。
つまり、実行した瞬間にそのサーバーにアクセスしていたユーザーの通信は強制的に切断（502 Bad Gateway や接続エラー）されます。

# 通信が一時的に切断されることを覚悟の上で再起動する
sudo systemctl restart nginx

4-2. reload（再読み込み）：プロの無停止オペレーション

一方、systemctl reload は、メインのプロセスを落とすことなく「設定ファイルだけを安全に再読み込みしてね」というシグナル（SIGHUP）を送ります。
Nginxなどの優れたソフトウェアはこれを受け取ると、古い設定で通信中のユーザーにはそのまま処理を継続させつつ、新しいユーザーからのアクセスは新しい設定で受け付ける「グレースフル・リロード（無停止反映）」を行います。

# 本番環境で設定ファイルだけを安全に反映させる（通信断なし）
sudo systemctl reload nginx

インフラエンジニアは、「設定を変えたらまずは reload」。どうしてもプロセス全体を再起動しなければならない重大な変更（SSL証明書の更新など、ソフトによってはrestartが必要な場合）のみ restart を使う、という厳密な使い分けをしています。

---

第5章：Unitファイルの徹底解剖（サービスの設計図）

systemctl で操作している「サービス」の正体は、単なるテキストファイルです。これを「Unit（ユニット）ファイル」と呼びます。

5-1. Unitファイルの配置場所

Unitファイルは主に以下の2つのディレクトリに配置されます。この違いを理解することが極めて重要です。

ディレクトリパス	役割と優先度
/usr/lib/systemd/system/	dnf 等でインストールしたパッケージ（公式）が提供するデフォルトのUnitファイル置き場。管理者が直接編集してはいけません。（パッケージ更新で上書きされるため）
/etc/systemd/system/	システム管理者が自作した独自のサービスや、デフォルト設定を上書き（オーバーライド）するためのファイル置き場。優先度が最も高い。

5-2. Unitファイルの基本構造

NginxのデフォルトUnitファイル（/usr/lib/systemd/system/nginx.service）の中身を見てみましょう。大きく3つのセクションに分かれています。

[Unit]
Description=The nginx HTTP and reverse proxy server
After=network-online.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

• [Unit]セクション： サービスの説明と、依存関係（起動する順番）を定義します。After=network-online.target は「ネットワークが完全に繋がってからNginxを起動せよ」という指示です。
• [Service]セクション： 実際のプロセスの起動コマンド（ExecStart）や停止コマンド（ExecStop）を定義します。
• [Install]セクション： systemctl enable した際に、どのタイミングで自動起動に組み込まれるか（WantedBy）を定義します。

---

第6章：【実践】独自Webアプリをデーモン化して自動復旧させる

モダンな開発現場では、Python（FastAPI）やNode.js、Go言語などで自作したWebアプリケーションをサーバーで動かす機会が頻繁にあります。単にターミナルから node app.js と実行しただけでは、ターミナルを閉じた瞬間にアプリも死んでしまいます。
プロのインフラエンジニアは、自作アプリ用のUnitファイルを作成し、systemdの管理下に置くことで「本番稼働に耐えうる堅牢なデーモン」へと昇華させます。

6-1. 独自サービス（my_webapp.service）の作成

ここでは、/opt/myapp/ に配置したNode.jsアプリをデーモン化する手順を実践します。
管理領域である /etc/systemd/system/ に新規ファイルを作成します。

# 独自サービスのUnitファイルを作成する
sudo vi /etc/systemd/system/my_webapp.service

以下の内容を記述します。

[Unit]
Description=My Custom Node.js Web Application
After=network.target mysql.service

[Service]
# アプリケーションを実行するユーザーを制限（rootで動かさないためのセキュリティ）
User=myapp_user
Group=myapp_user

# アプリの作業ディレクトリを指定
WorkingDirectory=/opt/myapp

# 起動するコマンドのフルパスを指定
ExecStart=/usr/bin/node /opt/myapp/app.js

# 【重要】プロセスがクラッシュ（異常終了）した場合、自動的に再起動させる
Restart=always
# 再起動するまでの待機時間
RestartSec=5

# 標準出力（ログ）をsyslog/journaldに送る
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=my_webapp

[Install]
WantedBy=multi-user.target

6-2. daemon-reload とサービスの起動

新しくUnitファイルを作成したり、既存のファイルを書き換えた場合は、systemdにその変更を認識させるための再読み込みが絶対に必要です。これを忘れるとエラーになります。

# systemdデーモン自体に、新しい設定ファイルを読み込ませる
sudo systemctl daemon-reload

# 独自アプリを起動し、さらにOS起動時の自動立ち上げも有効にする
sudo systemctl enable --now my_webapp.service

# ステータスを確認し、正常に稼働（active）しているかチェック
sudo systemctl status my_webapp.service

---

第7章：パッケージ更新を耐え抜くオーバーライド技術（systemctl edit）

既存の公式パッケージ（例えばNginxやMariaDB）の設定を少しだけ変えたい場面があります。
「Nginxのファイルディスクリプタ（LimitNOFILE）の上限を増やしたい」といった場合、/usr/lib/systemd/system/nginx.service を直接編集してしまうと、将来 dnf upgrade でNginxのバージョンが上がった瞬間に、ファイルが上書きされて設定が吹き飛んでしまいます。

7-1. プロの流儀：systemctl edit による差分適用

パッケージのアップデートに耐えるため、systemdには「ドロップイン（Drop-in）ファイル」という差分だけを上書き（オーバーライド）する仕組みが用意されています。これを安全に行う専用コマンドが systemctl edit です。

# NginxのUnit設定を安全に上書きするためのエディタを立ち上げる
sudo systemctl edit nginx.service

エディタが開いたら、変更したい差分のセクションと設定値だけを記述して保存します。

# この2行だけを追記して保存する
[Service]
LimitNOFILE=65536

これを保存すると、裏側で自動的に /etc/systemd/system/nginx.service.d/override.conf という専用の差分ファイルが作成され、daemon-reload まで自動で実行してくれます。
これにより、本体のNginxパッケージが何度アップデートされても、あなたのカスタム設定（オーバーライド）は永遠に守られ続けます。これが、長期運用を見据えたインフラエンジニアの設計術です。

---

総まとめ：サーバーのライフサイクルを完全に掌握せよ

第6回「systemdとサービス管理の完全攻略」、いかがだったでしょうか。
かつてのブラックボックスだったOSの起動プロセスは、systemdの登場により、すべてが透明で制御可能な「Unitファイル」というコードで記述できるようになりました。

• status： 異常発生時の第一手。ログも含めてプロセスの生死を確認する。
• enable --now： インストール直後の基本セット。起動と自動化を同時に完了させる。
• reload vs restart： 本番環境では無停止反映の reload を優先し、通信断を極小化する。
• Restart=always： 独自アプリのUnitファイルに記述し、障害時の自動復旧（自己治癒）を実現する。
• systemctl edit： パッケージのアップデートに破壊されない、安全なオーバーライドを構築する。

これらのコマンドと概念をマスターすることで、あなたは単なる「Linuxの操作者」から、インフラのライフサイクル全体を設計・支配する「アーキテクト」へと大きく進化しました。

次回、第7回は「システムログの確認とトラブルシューティング（journalctl）」です。systemdが管理している膨大なログ情報を、まるで検索エンジンのように自在にフィルタリングし、過去の障害の痕跡をピンポイントで発掘する技術を解説します。お楽しみに！リナックス先生でした！