cronより断然おすすめ！systemd timersのここが最高な理由

cronに代わる管理手法として、systemd timersを推したい。なぜなら、単なるスケジュール実行を超えた柔軟な制御が可能で、ログ管理や依存関係の解決もsystemdの流儀で統合できるからだ。一度使い始めると、もう昔ながらのcrontabには戻れない。

NixOSはsystemd標準搭載だから、管理のメインツールとしてフル活用してる。特にmacOSのlaunchdから来た身としては最高だね。NixOS向けにツールを配布する時も、適当な後付けじゃなくてsystemdにしっかり寄り添った設計にできるのがいい。Linux全体をターゲットにしたライフサイクル管理系のツールを配るならどうするのがベストなのか、systemdが ubiquitious（どこにでもある）じゃない現状を考えると悩ましいところだね。ちなみに俺はbtrfsのプールを月次でスクラブするためにsystemdタイマーを使ってる。ユーザーが手動でスクラブを開始した時は次のスケジュールをスキップするとか、マシンの電源が落ちてて6ヶ月間実行できなかったタスクをどう扱うか（まとめて一発にするか等）みたいな、実用的な挙動を細かく制御できるのがすごくクールだよ。

cronieからsystemdタイマーに切り替えたよ。起動時間の変動に強いからね。バックアップ戦略として、毎日決まった時間にborgのアーカイブを作成してるんだけど、cronieだとその時間にマシンが起動してないとダメだった。systemdタイマーなら、マシンが利用可能になった瞬間にサービスを実行してくれるからすごく助かる。ちなみにバックアップ自動化のレポはこれね： https://github.com/gchamon/borg-automated-backups

タイマーは任意のユニットと連携できるから（名前が同じサービスユニットだけじゃない）、驚くほど柔軟だよね。サーバーで毎朝「restic backup」「restic prune」「restic forget」のサイクルを回すbackup.targetをタイマーで起動してるんだけど、開始時間をランダム化したり通知を出したりするのも簡単。実際のrestic関連ユニットはPodman Quadletsにしてるから、Podmanとsystemdさえ入っていれば、サーバーの中身に関係なく環境を構築できるよ。ただ、正直タイマーがsystemdの中で一番とっつきにくいのは認めざるを得ないな。ファイルが2つに分かれてたり、startとenableで構文が違ったりする理由はわかるけど、たまには「スクリプトを実行するファイルを1つ作るだけで完了」みたいな手軽さが欲しくなるよ。

キヤノンのプリンター使ってるんだけど、しばらく放置するとインク詰まりが不安でね。だからClaudeに頼んで、毎週愛犬の写真を印刷するsystemdスクリプトを書かせてるよ。インクをしっかり消費させるためにCMYKのスペクトルが十分に含まれるようにしてるんだ。月曜の朝にデスクに座ると、プリンターから写真が勝手に出てきてて地味に嬉しいサプライズになってるよ :)

Linux歴20年以上、systemd歴10年以上だけど、それでも学べる新しいことは常にあるし、便利なツールとして再評価する価値はあるよね。

systemdタイマーを使い込んでないから反論はできないんだけど、「曖昧な$PATH設定のせいでcronスクリプトの実行結果が予測しづらい」ってどういう意味？crontab内でPATHを直書きすればいいだけじゃない？それって/etc/bashrcや~/.bashrc、/.profile、/.bash_profile、/etc/systemd/…に設定されるより「予測」が難しいの？あと「スケジュール記法を暗記してるとクール」って話だけど、1994年からLinux使ってる俺でも暗記なんてしてないよ。幸いなことにcrontabのコメント欄にヒントが書いてあるしね。 # m h dom mon dow command っていうタイトルに合わせて数字を並べるだけでいいんだ。他の不満点はわかるけどね。今度cronjobが必要になったらsystemdタイマーも試してみるよ。

systemdタイマー最高だよ！ansibleでデプロイしてたcronジョブを全部タイマーに移行し終えたところ（今はansibleのcopyだけで済む！）。syslogがなくなったDebian 13みたいな新しいOSだとjournalctlとの統合がホントに便利。デバッグのために手動でサービスを起動できるのもありがたい。以前はcronジョブが失敗した時の切り分けや、わざわざシェルスクリプトを書き直すのが苦痛だったからね。cronジョブのstdoutがブラックホールに消える問題についても言及したくないくらいだよ。systemdなら失敗した時に即座に通知を受け取れるし、普段やってるのと同じやり方でサービスを監視できる。最近はオープンソースプロジェクトでもデプロイ方法としてタイマーを勧めるケースが増えてて嬉しいね。

systemdを手放しで称賛してきたわけじゃないけど、この意見には大体同意できるな。俺もcronの使用はほぼやめて、システムレベルの定期ジョブはsystemdタイマーに切り替えた。特定のアプリに閉じたスケジューリングならQuartzを埋め込むことはあるけどね。なぜかっていうと、言葉にするのは難しいけど「こうあるべき」っていう自分のメンタルモデルにsystemdのアプローチがしっくりくるからかな。昔cronのPATH問題で苦労した経験があるのも影響してるかもしれないし、それだけじゃないけど。systemdタイマーが客観的に見てcronより絶対的に優れてるとは言わないけど、今のところは完全に軍配を上げてるよ。

systemdタイマーの入門としてすごくいいね。完全に納得させられたから導入してみるよ。「list-timers」で一括表示できるのもいいよね。cronだと各ユーザーのcrontabや/etc/cron.d/、daily/hourly/monthlyディレクトリまで全部チェックしないと何が動いてるか把握しにくかったからさ。実際、システム起動から約5分後、それ以降は12時間おきに実行したいタスクがあるんだけど、systemdタイマーならそれもカバーできるみたいだし最高だよ。

やあ、執筆者です。Hacker Newsからの流入に気づくのが少し遅れちゃったけど、フィードバックやコメントをくれてありがとう。トップレベルのコメントにはできる限り答えていくよ。（余談だけど、この記事は先月初めに書いたものが最近になって急にバズったんだ。systemdみたいに賛否両論あるトピックを扱うのは、良い意味でも悪い意味でもポジティブ・ネガティブ含めて強い反応が集まる確実な方法みたいだね。）