
長年CentOS(RHEL系)でサーバーを触ってきた管理人ですが、WordOpsを使うためにUbuntuサーバーを構築しました。
結論から言うと、「定時実行(タスク管理)に対する押し出しが全然違う」ので、CentOS Stream 9(RHEL9世代)感覚で構えていると拍子抜けします。
今回は、RHELで推奨されるモダンな systemd-timer と、Ubuntuで今なおバリバリ現役で愛されている従来型 crontab の思想の違いについてメモしておきます。
💡 モダン(RHEL) vs 伝統(Debian/Ubuntu)
サーバーのバックアップやログ回転など、特定の時間に自動でコマンドを実行させる仕組みですが、RHEL系とDebian/Ubuntu系では、現在の「推し」が異なります。
- CentOS Stream 9(RHEL系)スタイル:
systemd-timer
RHEL8/9世代から、従来のcron(crondサービス)は非推奨(デフォルト非インストールの場合も)になり、systemdが持つタイマー機能(systemd-timer)への移行が強力に推されています。「全てのプロセス管理をsystemdに統合する」というカッチリした思想です。 - Ubuntu(Debian系)スタイル:
crontab(cronデーモン)
もちろんUbuntuでもsystemd-timerは動きます。しかし、OS標準のジョブや多くのドキュメント、WordOpsの設定などを見ても、依然としてcrontab -eでおなじみの伝統的なcronシステムが現役で広く使われています。「シンプルで動きゃあ良い」という思想です。
CentOS時代に「これからはtimerの時代だ!」と慣れ親しんだ .timer と .service ファイルの作成から、Ubuntuでは再び crontab -e の世界へ逆戻りすることになります。
🔍 コマンドと設定方法の徹底対比
日常的に使うタスク管理のコマンドを比較してみましょう。
| 操作内容 | CentOS Stream 9 (systemd-timer) | Ubuntu (cron) |
|---|---|---|
| 設定の場所 | /etc/systemd/system/ (2ファイル作成) | crontab -e (1行追記) |
| 記述形式 | [Timer] セクション (OnCalendar=…) | * * * * * (5つの星) 形式 |
| 状態確認 | sudo systemctl list-timers | なし(sudo systemctl status cron で生存確認) |
| 即時実行(テスト) | sudo systemctl start (対応する.service) | なし(手動でコマンドを叩く) |
| ログ確認 | journalctl -u (対応する.service) | /var/log/syslog(他のログと混ざる) |
🛠️ CentOSユーザーがUbuntuの crontab に感じる「再会」
1. crontab -e の圧倒的な手軽さ
CentOS Stream 9でタスクを1つ追加しようとすると、以下の手順が必要でした。
- 実行するコマンドを書いた
.serviceファイルを作成 - スケジュールを書いた
.timerファイルを作成 systemctl daemon-reloadsystemctl enable --now (timer名)
これに対し、Ubuntuのcronはこうです。
crontab -eを開く0 3 * * * /path/to/backup.shと追記して保存
「手軽っ!!」
「脱cron」の波に乗っていた身としては、このあまりのシンプルさに、長年連れ添った老舗の定食屋に戻ってきたような安心感すら覚えます。
🛠️ 手動設定が面倒な方へ
最新のIP復元・バッファ設定を含んだ設定ファイルを即時生成できる無料Webツールを公開しています。

2. WordOpsもcronを前提に動いている
WordPressの管理ツールであるWordOpsも、内部の定期タスク(WordPressのCron代替やSSL証明書の更新など)は、内部でcron(/etc/cron.d/ 等)を前提とした設計になっています。
Ubuntuへお引越ししたなら、甘んじて伝統的なcronの世界を受け入れるのが、システムと喧嘩せずに済むコツです。
⚠️ でもやっぱり寂しい:systemd-timer のログ機能
Ubuntuのcronの手軽さに感動する反面、CentOS時代に享受していた systemd-timer の強力なメリットが恋しくなる瞬間もあります。
それは 「ログの追いやすさ」 です。
- CentOS (
systemd-timer):journalctl -u backup.serviceを叩けば、そのバックアップジョブがいつ始まり、いつ終わり、どんな標準出力(ログ)を出したかが、他のログと一切混ざらずに完全に独立して表示されます。失敗した時の再試行(Retries)も容易です。 - Ubuntu (
cron):デフォルトでは実行されたこと自体が/var/log/syslogに1行出るだけ。コマンド自身の出力を見ようとすると、自分で>> /var/log/backup.log 2>&1のようにリダイレクトを指定する必要があります。
📝 まとめ:カッチリ守るStream9 vs シンプルに動かすUbuntu
今回は、CentOS Stream 9からUbuntuへ移行して感じた「タスクスケジューラ思想の違い」について解説しました。
- CentOSは「systemdに統合して、ログも依存関係もカッチリ管理する」モダン型(
systemd-timer) - Ubuntuは「
crontab -eでサクッと設定して、とにかくシンプルに動かす」伝統型(cron) - Ubuntuでもsystemd-timerは使えるが、cronが現役バリバリで標準的
正直、大規模なシステム運用なら systemd-timer の方が堅牢で調査も楽ですが、WordOps+WordPressを動かす程度の単体サーバーなら、Ubuntuの crontab -e の「設定完了まで10秒」というスピード感はクセになりますw
次回は、サーバー運用で一番大切な、障害対応の最前線、『/var/log/messagesがない!?Ubuntuで障害調査するときに着地するログの定位置』についてメモしていきます。お楽しみに!



コメント