systemd Unitを作成
Unitファイルを生成し、権限、再起動条件、実行ユーザーなどの注意点と適用前の確認コマンドを表示します。
ExecStartのパス誤り、実行ユーザーの権限不足、再起動ループ、依存関係不足などを適用前に確認します。
systemctlで操作するときの名前です。英数字・ハイフンを推奨します。例：example-app → example-app.service
systemctl statusなどに表示されるサービスの説明です。運用時に用途が分かる内容にします。
実行方法に合わせてUnitの内容を調整します。「単発バッチ」は処理完了後に終了するジョブ向けです。
サービスを動かすLinuxユーザーです。未指定の場合はrootで実行されるため、専用ユーザーの利用を推奨します。
相対パスで設定ファイルやデータを参照するときの基準位置です。通常は絶対パスを指定し、systemdでは特別値~も使用できます。
実行ファイルと引数を入力します。このジェネレーターでは環境差を避けやすい絶対パスを推奨します。systemd自体は、スラッシュを含まない単純な実行ファイル名を標準検索パスから解決できます。例：/usr/bin/python3 /opt/example/app.py
通常の常駐アプリは「異常終了時のみ」が無難です。「常に再起動」は正常終了後も再起動します。
外部通信など、サービスが起動時に設定済みネットワークを厳密に必要とする場合だけ選びます。選択するとWants=network-online.targetとAfter=network-online.targetを追加します。外部サイトへの疎通成功そのものを保証する設定ではありません。
セキュリティ強化設定
子プロセスを含め、追加の権限取得を防ぎます。一般的なサービスで有効にしやすい設定です。
サービス専用の一時領域を使用します。他プロセスと/tmpを共有する必要がある場合は注意してください。
システム領域を読み取り専用にします。アプリが設定・ログ・データを書き込む場所を事前に確認してください。
ホームディレクトリへのアクセスを制限します。ホーム配下の設定や鍵を読むサービスでは動作に影響します。
「影響あり」の設定は、意味を確認せず有効にするとサービスが起動しない可能性があります。
適用・確認コマンド
注意点
生成後は、実行ユーザーの権限、ファイルの存在、SELinux、書き込み先などを確認してください。
生成後に必ず確認すること
生成できたことは正常起動の保証ではありません。systemd-analyze verifyで構文を確認し、実行ユーザーからExecStart・WorkingDirectoryへアクセスできるか確認してください。
判定範囲と実環境での確認
このツールで確認できること
Unitファイルを生成し、実行ユーザー、パス、再起動条件、権限、依存関係の基本項目を確認します。
このツールだけでは分からないこと
アプリ固有の起動要件、秘密情報の扱い、SELinux、ネットワーク到達性、バージョン固有のディレクティブまでは完全には判定できません。
実環境で追加確認すること
systemd-analyze verify、systemctl cat、systemctl show、journalctlで構文と読み込み後の設定を確認してください。
適用時の注意
systemctl restartはサービス停止を伴います。まず検証し、可能ならテスト環境やreloadで確認してください。
よくある質問
Unitを作成した後、すぐstartしてよいですか？
先に systemd-analyze verify、systemctl daemon-reload、systemctl cat で構文と読み込み内容を確認してください。既存サービスなら停止影響や依存関係も確認します。
AIが作ったUnitで見落としやすい点は？
実行ユーザー、WorkingDirectory、絶対パス、環境変数、再起動ループ、ファイル権限、ネットワーク準備前の起動です。
restartとreloadはどう使い分けますか？
restartはプロセスを再起動します。reloadはサービスが対応している場合に設定だけ再読み込みします。停止影響を避けたい場合はreload対応可否を先に確認してください。
判定がおかしい・対応してほしい設定がありますか？
OSや環境差による判定漏れ、分かりにくい表示、追加してほしい確認項目をお知らせください。設定内容は機密部分を伏せてください。