【保存版】systemctl startでエラーが出た時の「プロの確認順序」完全フローチャート｜AlmaLinux 9

「起動しない」画面の前で、途方に暮れているあなたへ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
これまでの連載で、Linuxサーバーの構築方法を学んできましたが、現場で最も必要なスキルは何だと思いますか？

それは、「構築したはずなのに、動かない時」の対応力です。
コマンドを叩いた瞬間、無慈悲に表示される Job for httpd.service failed... という赤い文字。
「何が悪いんだ！？」とパニックになり、闇雲に再起動を繰り返していませんか？
エラーには必ず「原因」があり、それを突き止めるための「正しい手順」が存在します。

本記事では、AlmaLinux 9 をベースに、systemctl start が失敗した際の調査手順を、初動の確認から深層ログの解析、そしてRHEL系特有のSELinux対策まで、フローチャート形式で徹底解説します。

---

Step 0：エラーメッセージを直視する

まず、エラーが出た時の画面をよく見てみましょう。

$ sudo systemctl start httpd
Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.

多くの初心者はここで思考停止してしまいますが、ここには重要なヒントが書かれています。
「コントロールプロセスがエラーコードを吐いて終了した」と言っています。
つまり、Systemd自体が壊れたのではなく、「httpd（Apache）を実行しようとしたけど、Apache側が『無理！』と言って落ちた」ということです。

そして、次にやるべきコマンドも親切に教えてくれています。
systemctl status と journalctl です。

---

Step 1：現状把握「systemctl status」

まずは、サービスの「今の状態」を確認します。
-l (long) オプションをつけることで、ログが途中で省略されずに表示されます。

sudo systemctl status httpd -l

見るべきポイントとExit Codeの意味

1. Active: failed (Result: exit-code):
   現在停止しており、正常終了ではなくエラー終了したことがわかります。
2. Main PID: 1234 (code=exited, status=1/FAILURE):
   プロセスがどのような状態で終了したかを示します。

Status Code	意味	推測される原因
1 / FAILURE	一般的なエラー	設定ファイルの構文ミス、権限不足など
126 / 127	実行不可 / コマンドなし	実行ファイルのパス間違い、実行権限がない
203 / EXEC	実行失敗	スクリプトのShebang間違い、バイナリ破損
Killed	強制終了	メモリ不足（OOM Killer）、タイムアウト

画面下部のログ (CGroup) に Syntax error などの具体的なメッセージがあれば、この段階で解決できます。
しかし、詳細な原因が載っていない場合は、次のステップへ進みます。

---

Step 2：ログの深掘り「journalctl」の活用

Linuxのシステムログを一手に引き受ける journalctl は、トラブルシューティングの要です。
エラーメッセージにあった -xe だけでは不十分なことが多いです。

最強の絞り込みテクニック

闇雲にログを見るのではなく、ターゲットを絞り込みます。

1. 特定のサービスのログだけ見る (-u)

# Apacheのログだけを表示
sudo journalctl -u httpd

これなら、関係のないメールサーバーやcronのログに埋もれることがありません。

2. エラー発生時刻で絞る (–since)

過去の膨大なログはいりません。「今日」または「10分前」からのログを見ます。

# 今日以降のログを見る
sudo journalctl -u httpd --since today

# 直近10分のログを見る（no-pagerで行末まで表示）
sudo journalctl -u httpd --since "10 min ago" --no-pager

3. リアルタイムで監視する (-f)

ログを流しっぱなしにした状態で、別のターミナルから systemctl start を実行し、何が出力されるか観察します。これが最も原因特定しやすい方法です。

sudo journalctl -u httpd -f

---

Step 3：設定ファイルの「構文チェック」

journalctl で「設定ファイルがおかしい」という雰囲気を感じ取ったら、各ミドルウェアが持っている「構文チェックコマンド（Lint）」を使います。
systemctl を経由せず、直接バイナリにチェックさせることで、より詳細なエラー箇所（行番号や理由）を教えてくれます。

Apache (httpd) の場合

sudo apachectl configtest
# または
sudo httpd -t

出力例：
Syntax error on line 10 ... Invalid command 'ServerNam', perhaps misspelled...
（ServerNameのスペルミスだ！と分かります）

Nginx の場合

sudo nginx -t

MariaDB (MySQL) の場合

MySQLは設定ファイルのミスで起動しないことが多いです。エラーログのパスを確認します。

mysqld --validate-config

または、直接エラーログを見に行きます。

sudo tail -n 50 /var/log/mariadb/mariadb.log

PHP-FPM の場合

sudo php-fpm -t

---

Step 4：AlmaLinuxの伏兵「SELinux」を疑う

設定ファイルは完璧。構文エラーもない。それでも起動しない。
そんな時に9割の確率で犯人なのが、RHEL系OSの守護神 SELinux です。

SELinuxは、「Apacheは /var/www/html 以外見てはいけない」「Apacheは勝手にポートを変えてはいけない」といった厳しいルールを強制します。
あなたがドキュメントルートを変更したり、ポート番号を標準以外（8080など）に変えた場合、SELinuxにブロックされている可能性があります。

1. 一時的に無効化してテストする

これが最も手っ取り早い切り分け方法です。

# SELinuxを一時的に無効化（Permissiveモード）
sudo setenforce 0

# 起動を試みる
sudo systemctl start httpd

もしこれで起動できたら、犯人はSELinuxで確定です。

2. ブロックログの確認と対処 (audit2allow)

なぜブロックされたかを確認します。

sudo ausearch -m avc -ts recent

denied という文字とともに、アクセスしようとしたファイルやポートが表示されます。

また、「なぜブロックされたか、どうすれば許可できるか」を教えてくれる便利なコマンドがあります。

# 拒否ログを解析して、解決策を提案させる
sudo ausearch -m avc -ts recent | audit2allow -w

3. 恒久対策（コンテキストの修正）

テストが終わったら必ずSELinuxを有効に戻し（setenforce 1）、正しい設定を行います。

# ファイルのラベルを確認
ls -Z /var/www/html/index.html

# 正しいラベルを付与（例：Webコンテンツとして読み取り許可）
sudo chcon -t httpd_sys_content_t /var/www/html/index.html

# ディレクトリ全体に適用する場合
sudo restorecon -Rv /var/www/html/

---

Step 5：ポートの競合（Address already in use）

「Apacheを起動しようとしたら、すでにNginxが80番を使っていた」というケースです。
ログに Address already in use: make_sock: could not bind to address 0.0.0.0:80 と出ていたらこれです。

ポート使用状況の確認

ss コマンドを使って、誰がポートを使っているか特定します。

# -t:TCP, -u:UDP, -l:Listening, -p:Process, -n:Number
sudo ss -tulpn | grep :80

出力例：
tcp LISTEN 0 128 *:80 users:(("nginx",pid=1234,fd=6))

この場合、Nginx（PID 1234）が犯人です。
Nginxを止めるか、Apacheのポートを変える必要があります。

---

Step 6：権限（Permission）と所有者

「ログファイルに書き込めなくて起動失敗」というパターンです。
特に、ログの出力先ディレクトリを手動で作成した場合に発生します。

所有者の確認

Apacheは通常 apache ユーザーとして動作します。
ログディレクトリが root 所有になっていて、書き込み権限がないと落ちます。

# ログディレクトリの権限確認
ls -ld /var/log/httpd

# 所有者の修正
sudo chown -R apache:apache /var/log/httpd
sudo chmod 755 /var/log/httpd

---

Step 7：ユニットファイルの記述ミス

自分で作成したサービス（例：Perlアプリの自動起動設定）の場合、.service ファイル自体の記述ミスも考えられます。

Systemdの設定再読み込み

ユニットファイルを書き換えた後は、必ず以下のコマンドが必要です。
これを忘れると、古い設定のまま起動しようとして失敗します。

sudo systemctl daemon-reload

ユニットファイルの検証

記述ミスがないかチェックするコマンドがあります。

systemd-analyze verify /etc/systemd/system/myapp.service

例えば Type=forking なのにPIDファイルを指定していない、などの論理矛盾を指摘してくれます。

---

Step 8：リソース不足と「OOM Killer」

「設定は合っているのに、起動した瞬間に死ぬ」
「ログが途中で途切れている」
こんな場合は、メモリ不足でLinuxカーネルに強制終了させられている可能性があります（Out Of Memory Killer）。

カーネルログの確認

dmesg コマンドでカーネルの声を聞きます。

sudo dmesg | grep -i "killed"

Out of memory: Kill process 1234 (mysqld) のようなログが出ていたら、メモリ不足です。
VPSのプランを上げるか、スワップ領域を作成するなどの対策が必要です。

---

まとめ：エラー解決の「チートシート」

最後に、トラブルシューティングの流れをまとめました。
エラーが出たら、上から順に試してください。

「エラーが出る」ということは、システムが正常に動作するための条件が満たされていないというシグナルです。
決して悪いことではありません。
この手順をマスターすれば、あなたはもうエラー画面を見て動揺する初心者ではありません。
冷静にログを読み、原因を特定し、解決できる「頼れるエンジニア」です。

さあ、ターミナルに戻って、あの赤いエラーメッセージと向き合ってみましょう。
解決への鍵は、必ずそこにあります。