systemd サービスファイル生成

Node.js、Python、Go のプログラムを Linux サーバーで動かし続け、起動時に開始し、クラッシュしたら再起動する設定を、systemd のオプションを覚えなくても作れます。コマンドとユーザーを入力し、再起動の方針と環境変数を選ぶと、.service ファイルとインストール・起動用のコマンドをまとめてコピーできます。「スケジュールで実行」にチェックすると、cron に代わる新しい方法として .timer も生成されます。

ブラウザ内で動作 — 入力した内容はアップロードされません

サービス名

ファイル名になります（例: myapp → myapp.service）

説明

コマンド（ExecStart）

プログラムのフルパスを指定します（例: /usr/bin/python3 app.py）

作業ディレクトリ

実行ユーザー

グループ

Type

コマンドがフォアグラウンドで動き続けます（ほとんどの Web アプリやスクリプト）。

Restart

再起動までの待ち時間（秒）

環境変数

1 行に 1 つ KEY=value の形式で入力します。空白を含む値は自動で引用符で囲まれます。

環境ファイル

最大オープンファイル数（LimitNOFILE）

0 ならシステムの既定値のままにします。

ネットワークがオンラインになってから起動基本的なハードニング（新しい権限を禁止、/tmp を分離、システムを読み取り専用に）スケジュールで実行（.timer を作成）

myapp.service

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

インストールと起動

sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF'
[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service
journalctl -u myapp.service -f

コマンドはサーバー上で root としてそのまま貼り付けてください。ユニットファイルを編集したら、もう一度 systemctl daemon-reload を実行します。ログは journalctl -u <name> で確認できます。

使い方

サービス名、フルパスのコマンド、作業ディレクトリを入力します。
実行ユーザー、再起動の方針、必要な環境変数を設定します。
必要に応じて基本的なハードニングやスケジュール（OnCalendar）を追加し、タイマーを作成します。
生成されたファイルをコピーするか、インストール用コマンドをサーバーの root シェルに貼り付けます。

オプションの説明

Type: simple はフォアグラウンドで動き続けるプログラム向け、oneshot は定期ジョブのように 1 回だけ実行するスクリプト向けです。
Restart: 「失敗時」はエラー終了やクラッシュのときにサービスを再起動し、「常に」は正常終了した場合も再起動します。
OnCalendar: タイマーが動作する時刻の指定です。例: daily、毎日午前 3 時なら *-*-* 03:00:00。式は systemd-analyze calendar で確認できます。

例: 毎晩のジョブをタイマーで実行する

スクリプトを毎晩午前 3 時に実行するには、「コマンド（ExecStart）」を /usr/local/bin/backup.sh、サービス名を backup、Type を oneshot、Restart を「再起動しない」にし、「スケジュールで実行（.timer を作成）」と「基本的なハードニング」にチェックを入れます。ユーザーと作業ディレクトリが既定のままなら、ジェネレーターは 2 つのファイルを出力します。まず backup.service です。

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/srv/myapp
ExecStart=/usr/local/bin/backup.sh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only

次に backup.timer です。

[Unit]
Description=Run backup on a schedule

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

タイマーを有効にすると、2 つの点が変わります。サービスファイルから [Install] セクションがなくなります（タイマーがサービスを起動するため）。また、インストール用のコマンドは、サービスではなくタイマーを有効にします。

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -f

タイマーのオプションにチェックを入れても Type は自動では変わらないため、処理が終わるジョブには自分で oneshot を選んでください。oneshot のサービスと Restart の「常に」の組み合わせは無効なので、ジェネレーターは Restart を出力せず、警告を表示します。

よくある質問

ファイルはどこに置きますか？

/etc/systemd/system/ に置き、systemctl daemon-reload と systemctl enable --now <name>.service を実行します。生成されるコマンドがこの手順をすべて行います。

「Executable path is not absolute」で失敗するのはなぜ？

古い systemd では ExecStart にプログラムのフルパスが必要です。which で調べられます（例: which node）。

タイマーと cron はどちらがよいですか？

タイマーはジャーナルにログを残し、サーバー停止中に逃した実行を後から取り戻せ、同時に二重実行されることもありません。cron は 1 行で済む用途には簡単で、今も問題なく使えます。

プライバシー

このツールはすべてブラウザ内で動作します。ファイルやテキストはお使いの端末上で処理され、当サイトのサーバーにアップロードされることはありません。