systemctlでLinuxサービスを操作する基本：起動・停止・状態確認を実務で使う
LinuxサーバーでWebサイトやWordPressを運用していると、「Webサーバーを再起動したい」「PHP-FPMが動いているか見たい」「自動起動になっているか確認したい」という場面がよくあります。そこで使う基本コマンドが systemctl です。
systemctl は、Linuxのサービス管理を担う systemd を操作するためのコマンドです。サービスを今すぐ起動・停止するだけでなく、サーバー再起動後に自動で立ち上げる設定や、失敗した理由の確認にも使います。
この記事では、Web制作・WordPress・小規模サーバー運用でよく使う範囲に絞って、systemctl の基本を整理します。
- まず覚える操作は
status、start、stop、restart、enable、disable startは「今すぐ起動」、enableは「次回起動時から自動起動」- うまく動かないときは
systemctl statusとjournalctl -uをセットで見る - 設定ファイルを書き換えた場合は、必要に応じて
reload、restart、daemon-reloadを使い分ける
対象環境は、systemd を採用している一般的なLinuxディストリビューションです。Ubuntu、Debian、AlmaLinux、Rocky Linux、CentOS Streamなどのサーバーでは多くの場合利用できます。確認時点は2026年7月です。
systemctlは何を操作しているのか
systemctl は、Linux上で動くサービスを「unit」という単位で操作します。
Webサーバー、データベース、PHP-FPM、cronのような常駐プロセスは、多くの環境で *.service というunitとして管理されています。たとえば、Nginxなら nginx.service、MariaDBなら mariadb.service のような名前です。
公式の systemctl マニュアルでも、systemctl は systemd のシステム・サービスマネージャーの状態を調べたり制御したりするコマンドとして説明されています。
ここがポイント:
systemctlは「プロセスを直接探してkillする道具」ではなく、サービスを管理する仕組みに対して起動・停止・状態確認を依頼するコマンドです。
実務では、次のような場面で使います。
- WordPressの表示が重く、
nginxやphp-fpmの状態を確認する - SSL証明書を更新したあと、Webサーバー設定を反映する
- サーバー再起動後にデータベースが自動起動するか確認する
- 自作スクリプトをサービス化して、落ちたときに再起動させたい
まず覚える基本コマンド
最初は「今の状態を見る」「起動する」「止める」「再起動する」「自動起動を設定する」の5系統だけで十分です。
以下では例として nginx を使います。環境によってサービス名は異なるため、Apacheなら apache2 または httpd、PHP-FPMなら php8.3-fpm や php-fpm のように読み替えてください。
状態を確認する
sudo systemctl status nginx
status は、人が読むための状態確認に向いたコマンドです。公式マニュアルでも、status は実行時の状態情報と最近のログを表示するものとして説明されています。
よく見る行は次の3つです。
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: active (running) since Tue 2026-07-07 10:15:21 JST; 2h ago
Main PID: 1234 (nginx)
読み方はこうです。
Loaded: unitファイルが読み込まれているか、自動起動設定がどうなっているかActive: 今動いているか、停止しているか、失敗しているかMain PID: 実際に動いている主プロセスのID
Active: active (running) なら、サービスは起動中です。inactive なら停止中、failed なら起動に失敗した状態です。
起動・停止・再起動する
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
それぞれの意味はシンプルです。
start: サービスを今すぐ起動するstop: サービスを今すぐ停止するrestart: 停止してから起動し直す
Webサーバー設定を変えたあとに restart する場面は多いですが、稼働中サイトでは一瞬でも接続が切れる可能性があります。設定だけを再読み込みできるサービスなら、次の reload も候補になります。
sudo systemctl reload nginx
ただし、reload はサービス側の設定再読み込みです。systemd のunitファイルそのものを書き換えた場合は、後述する daemon-reload が必要になります。
startとenableを混同しない
systemctl で初心者が最もつまずきやすいのは、start と enable の違いです。
start は今すぐ動かす操作、enable は次回起動時に自動で立ち上げる設定です。公式マニュアルでも、enableはunitファイルの [Install] セクションに基づいてシンボリックリンクを作る操作であり、それだけではサービスを起動しないと説明されています。
実務では次のように使い分けます。
# 今すぐ起動する
sudo systemctl start nginx
# サーバー起動時に自動起動するよう設定する
sudo systemctl enable nginx
# 自動起動を設定しつつ、今すぐ起動する
sudo systemctl enable --now nginx
状態確認も分けて考えます。
# 今動いているか
systemctl is-active nginx
# 自動起動が有効か
systemctl is-enabled nginx
入力例と出力例です。
$ systemctl is-active nginx
active
$ systemctl is-enabled nginx
enabled
この2つは別物です。active でも disabled のサービスはあります。手動で起動したが、再起動後には立ち上がらない状態です。逆に enabled でも、今は停止していることがあります。
WordPress運用でよくある確認パターン
WordPressやWeb制作のサーバー作業では、サービス名を正しく見つけて、状態とログを順番に確認する流れが重要です。
サービス名を探す
サービス名が分からないときは、一覧から探します。
systemctl list-units --type=service --state=running
Web関連だけざっくり探すなら、環境に合わせて grep を使います。
systemctl list-units --type=service | grep -E 'nginx|apache|httpd|php|mysql|mariadb'
出力例です。
nginx.service loaded active running A high performance web server
php8.3-fpm.service loaded active running The PHP 8.3 FastCGI Process Manager
mariadb.service loaded active running MariaDB database server
この例なら、WordPressの表示に関係しやすいサービスは nginx、php8.3-fpm、mariadb です。エラーの種類によって見る順番が変わります。
- 502 Bad Gateway:
nginxとphp-fpmを確認する - データベース接続エラー:
mariadbまたはmysqlを確認する - サイト全体につながらない: Webサーバー、ファイアウォール、DNS、証明書も切り分ける
ログを確認する
systemctl status だけではログの量が足りないことがあります。その場合は journalctl を使います。
sudo journalctl -u nginx --since "1 hour ago"
直近のログを追いかけるなら次の形です。
sudo journalctl -u nginx -f
-u はunitを指定するオプションです。たとえば php8.3-fpm を見るなら、次のようにします。
sudo journalctl -u php8.3-fpm --since "today"
エラー対処では、コマンドをいきなり何度も実行するより、ログに出ている原因を先に見たほうが早いです。設定ファイルの構文エラー、ポートの競合、権限不足、ファイルパスの間違いはログに出ることが多いです。
reload、restart、daemon-reloadの違い
設定反映で迷いやすい3つのコマンドは、対象が違います。
| コマンド | 何をするか | 使う場面 |
|---|---|---|
reload | サービス自身に設定を再読み込みさせる | Nginxなどで設定変更を反映したい |
restart | サービスを停止して起動し直す | reload非対応、または確実に再起動したい |
daemon-reload | systemdが読むunit定義を再読み込みする | /etc/systemd/system/*.service を追加・変更した |
公式マニュアルでも、reload はサービス固有の設定を再読み込みする操作であり、unitファイルの再読み込みとは別だと説明されています。unitファイルを変更した場合は、daemon-reload を使います。
たとえば自作のサービスファイルを編集したときは、次の順番です。
sudo systemctl daemon-reload
sudo systemctl restart my-worker.service
sudo systemctl status my-worker.service
Nginxの設定ファイルだけを変えた場合は、通常は次のような流れです。
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx
nginx -t はNginx設定の構文チェックです。systemctl の機能ではありませんが、設定ミスでサービスを止めないために実務ではよく組み合わせます。
よくある失敗と対処
systemctl のエラーは、コマンド名の間違いだけでなく、サービス名、権限、設定ファイル、依存サービスなど複数の原因で起きます。
Unit not found
Unit nginx.service could not be found.
サービス名が違う、またはパッケージがインストールされていない可能性があります。
確認します。
systemctl list-unit-files | grep nginx
Apache系なら、Ubuntu/Debianでは apache2、RHEL系では httpd という名前になることがあります。名前が違うだけで、操作の考え方は同じです。
Activeがfailedになる
Active: failed (Result: exit-code)
起動に失敗しています。まずログを見ます。
sudo systemctl status nginx
sudo journalctl -u nginx --since "10 minutes ago"
よくある原因は次の通りです。
- 設定ファイルの構文エラー
- すでに別プロセスが同じポートを使っている
- 証明書ファイルやログディレクトリのパスが違う
- 実行ユーザーに読み取り権限がない
enableしたのに今すぐ動かない
これは仕様です。enable は自動起動設定であり、起動操作ではありません。
今すぐ動かしたい場合は、次のどちらかを使います。
sudo systemctl start nginx
または、設定と起動を同時に行います。
sudo systemctl enable --now nginx
代替手段と使い分け
systemctl だけでサーバー運用のすべてを確認できるわけではありません。目的ごとに別のコマンドと組み合わせます。
journalctl: systemd journalのログを見るps: プロセスが存在するか確認するss: ポートの待ち受け状況を見るnginx -t、apachectl configtest: Webサーバー設定の構文チェックをするservice: 古い環境や互換レイヤーで使われるサービス操作コマンド
たとえば「Nginxは起動しているのにサイトにつながらない」場合、systemctl status nginx だけでは不十分です。ポート80・443で待ち受けているかを見るなら、次のように確認します。
sudo ss -ltnp | grep -E ':80|:443'
出力例です。
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=7))
このように、systemctl は「サービス管理の入口」です。ネットワーク、設定ファイル、アプリケーションログまで一緒に見ると、原因の切り分けが速くなります。
実務で使う最小チェックリスト
最後に、サーバー作業でよく使う流れをまとめます。
# 1. 状態を見る
sudo systemctl status nginx
# 2. 自動起動設定を見る
systemctl is-enabled nginx
# 3. 直近ログを見る
sudo journalctl -u nginx --since "30 minutes ago"
# 4. 設定変更後に構文チェックする
sudo nginx -t
# 5. 設定を反映する
sudo systemctl reload nginx
# 6. 反映後の状態を見る
sudo systemctl status nginx
自作サービスやunitファイルを扱う場合は、ここに daemon-reload が加わります。
sudo systemctl daemon-reload
sudo systemctl restart my-worker.service
sudo systemctl status my-worker.service
次に見るべき分岐点は、「操作したいのがサービス自身の設定なのか、systemdのunit定義なのか」です。ここを分けて考えるだけで、reload、restart、daemon-reload の迷いはかなり減ります。