systemd status=203/EXECの原因と確認手順
systemctl start後に status=203/EXEC が出たとき、ExecStart=の実行対象・権限・shebang・マウント条件を順番に確認し、プロセス実行前に失敗している原因を切り分けます。
このページの目的
systemctl start後にstatus=203/EXECが出た場合だけを対象に、実行ファイルを起動できない原因を絞ります。ExecStart=の書き方そのものは別ページへ分けています。
最初にやること
systemctl statusとjournalctl -uでエラーを確認し、Unitに指定された実行ファイルの存在・到達権限・shebangを順番に確認します。
関連するsystemdトラブル・設定ガイド
ExecStart=の書き方
ExecStart=の実行パス・引数・シェルを使う場合の書き方を確認します。
設定を確認 →トラブルsystemdが起動しない・failedになる
203/EXEC以外を含むfailed全般を、statusとjournalctlから切り分けます。
原因を切り分ける →トラブルPermission deniedを切り分ける
実行ユーザー、所有者、モード、ディレクトリ到達権限を確認します。
権限を確認 →status=203/EXECはsystemdのEXIT_EXECで、実際のプロセス実行に失敗した状態です。ExecStart=の引用符・引数・リダイレクトなどの設計はExecStart=の書き方、203/EXEC以外のfailedはsystemdが起動しないガイドを確認してください。Unitを変更する前に確認
ExecStart、User、WorkingDirectoryなどの設定を貼り付けて、適用前に注意点を確認できます。
status=203/EXECは「実行そのものに失敗」
203/EXECは、サービスのアプリが起動してから異常終了したというより、systemdが設定されたプログラムを実行する段階で失敗したときに出ます。まずアプリ内部の設定より、実行対象へ到達できるかを確認します。
最初にstatus・journal・Unit実体を確認
まずログにNo such file or directoryやPermission deniedなどがないか確認し、実際に読み込まれているExecStart=と実行ユーザーを一致させます。
実行ファイル・親ディレクトリ・実行ユーザーを確認
namei -lでは、ファイル本体だけでなく/optなど親ディレクトリに実行ユーザーが到達できるかも確認します。UnitにUser=appuserがあるなら、そのユーザーで確認します。
systemctl show -p UserとUnitを確認します。スクリプトならshebang・改行コード・インタープリタを確認
先頭が#!/bin/bashなどのshebangなら、そのインタープリタが実際に存在するか確認します。Windows由来のCRLFがshebangへ混ざると、見た目では分かりにくい実行失敗になることがあります。
/bin/shへ置き換えると別の障害になります。元の実行要件を確認します。権限が正しければnoexecやセキュリティ制御も確認
対象ファイルシステムがnoexecでマウントされていると実行できません。SELinuxやAppArmorなどの拒否が疑われる場合も、無効化を先に試すのではなくログで拒否理由を確認します。
確認結果から次の対応を決める
| 確認結果 | 次に見る場所 |
|---|---|
| ExecStartのパスが存在しない | Unitのパスとパッケージ・配置手順を確認。書き方はExecStartガイドへ |
| 親ディレクトリで到達できない | 所有者・モード・ACLを確認。Permission deniedガイドへ |
| 実行ビットがない | そのファイルが直接実行される設計か確認してから権限を修正 |
| shebang先がない / CRLF | インタープリタの存在とファイル形式を修正 |
| noexec | マウント設計と実行ファイルの配置場所を確認 |
| SELinux/AppArmorの拒否 | 監査ログから対象ルールを特定し、必要な許可だけ検討 |
修正後はUnit再読込とログまで確認
Unitファイル自体を変更した場合はdaemon-reload後に起動します。実行ファイルだけを修正した場合は、Unit定義を変更していなければdaemon-reloadが必須とは限りません。