Linuxサーバを運用していると、サービスを起動しようとした際に
sudo systemctl start httpdのようなコマンドを実行しても、エラーが出てサービスが立ち上がらないことがあります。
この「systemctl start が失敗する」問題は原因が多岐にわたりますが、順序立てて確認すれば解決できるケースがほとんどです。本記事では、代表的な原因と確認・解決方法を整理して紹介します。
1. journalctl でログを確認する
まずは「なぜ失敗したのか」を確認することが重要です。
sudo journalctl -xeu サービス名例: Apache (httpd) の場合
sudo journalctl -xeu httpdここでエラーメッセージを確認しましょう。
よくあるメッセージには以下のようなものがあります：
- ポート競合（既に別プロセスが使用中）
- 設定ファイルの記述ミス
- 必要な権限が不足している
ポイント: エラーメッセージを無視せず、必ずチェックすること。
2. 依存サービスが起動していない
systemd では、サービスごとに依存関係が定義されています。たとえば：
httpd→network.serviceが必要mariadb→networkやsystemd-sysctlが必要
依存関係を確認するには：
systemctl list-dependencies サービス名もし依存サービスが起動していない場合は、先にそちらを起動する必要があります。
sudo systemctl start network3. SELinux がブロックしている
CentOS / RHEL 系ディストリビューションでありがちな原因が SELinux です。
SELinux はセキュリティを強化する仕組みですが、設定によってサービスの起動をブロックすることがあります。
SELinux の状態確認
getenforceEnforcing→ SELinux 有効Permissive→ ログは残すがブロックはしないDisabled→ 無効
SELinux が原因か調べる方法
試しに一時的に Permissive にしてみます。
sudo setenforce 0その後サービスが起動するなら、SELinux のポリシー設定を見直す必要があります。
例:
sudo semanage port -a -t http_port_t -p tcp 8080で httpd に 8080 ポートの利用を許可するなど。
4. 設定ファイルのエラー
設定ファイルの文法エラーで起動に失敗することも多いです。
Apache の例
sudo apachectl configtestNginx の例
sudo nginx -t設定のテスト機能を活用し、修正後に再度 systemctl start を試しましょう。
5. 権限やファイル所有者の問題
- PID ファイルのディレクトリに書き込み権限がない
- ログディレクトリの権限がおかしい
- 実行ユーザーが正しくない
といった原因もあります。ls -l で権限を確認し、必要に応じて chown や chmod で修正しましょう。
まとめ
systemctl start が失敗した場合は、焦らず以下の順に確認するとスムーズです：
journalctlでログを確認- 依存サービスが起動しているか確認
- SELinux の影響を確認
- 設定ファイルをテスト
- 権限や所有者を確認
