CentOS Stream 9（RHEL系）からUbuntuサーバーへ移行した際、定時実行（タスクスケジューラ）に対するアプローチや運用の手触りの違いに驚いたため、技術比較メモとしてまとめます。
1. 思想の違い：統合管理（RHEL） vs 手軽さ重視（Ubuntu）
-
CentOS Stream 9 (RHEL系): プロセス管理をsystemdへ一本化する方針が強く、従来のcronより
systemd-timerの利用が強く推奨されます。 -
Ubuntu (Debian系):
systemd-timerも当然動作しますが、公式パッケージやWordOps等の周辺ツールも含め、依然として伝統的なcrontab(cronデーモン) が標準的かつ現役で愛用されています。
2. 実装・運用コマンドの比較
| 項目 | CentOS Stream 9 (systemd-timer) |
Ubuntu (cron) |
|---|---|---|
| 設定場所 |
/etc/systemd/system/ (.service と .timer の2ファイル) |
crontab -e (または /etc/cron.d/) |
| 設定形式 |
[Timer] セクション (OnCalendar=...) |
* * * * * (5つの星形式) |
| 一覧・状態確認 | sudo systemctl list-timers |
crontab -l |
| 手動テスト実行 | sudo systemctl start <サービス名>.service |
コマンド直接実行 |
| ログ確認 |
journalctl -u <サービス名>.service (完全分離) |
/var/log/syslog (リダイレクト個別指定が必要) |
3. 設定手順の具体例
systemd-timerの場合 (CentOS Stream 9 推奨)
タスクを1つ登録するために2つのユニット定義とデーモンのリロードが必要です。
# /etc/systemd/system/backup.service
[Unit]
Description=Daily Backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# /etc/systemd/system/backup.timer
[Unit]
Description=Daily Backup Timer
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
# 反映と有効化
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
crontabの場合 (Ubuntu での手軽な登録)
1コマンド・1行追記で即座にスケジューリングが完了します。
crontab -e
# 毎日午前3時に実行（ログを明示的にリダイレクト）
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
4. それぞれのメリット・デメリットまとめ
systemd-timer の強み:
- journalctl -u でジョブ単体の標準出力・エラー出力が自動で綺麗に分離される
- 依存関係（ネットワーク起動後など）や失敗時の再試行（Retries）を宣言的に制御できる
crontab の強み:
- 記述コストが極めて低く、設定完了まで数秒で済む
- WordOps等のミドルウェアとの連携が素直
大規模環境や厳密な監視が必要なら systemd-timer が優勢ですが、単体Webサーバー運用などでは crontab の圧倒的な手軽さも依然として強力な選択肢です。
※ブログ本編では、WordOps環境での定期実行事情や、cron記述時の環境変数・ログ出力の罠を回避するTipsなども詳しく掘り下げています。
👉 【Stream9ユーザーが送る】systemd-timer全盛のStream9から、まだcrontabが現役なUbuntuの世界へ