未だにcrontab -eしちゃう老兵だけど、ログ周りの貧弱さを考えると移行は必然か
いろんな要素がsystemdに吸い込まれているけれども、非Linuxでinitライクな仕組みがあったOS、ディストリビューション向けに挙げている課題を解消するcron代替ってあるのかな
logger にパイプで渡せばいいだけでは？＞cronのログ
“しかし近年では、 新規サーバ構築では cron を使わない systemd timer が推奨される cron は「保守対象」になりつつある ”
でも、systemd timerはcronと違ってメール通知してくれないので悪だと思いました。メール通知ユニットを自前実装すれば可能だしそこまで手間も要らないけど、だからこそパッケージに標準で含めておいて欲しい。
そうなんだ。移行した方がメリット多そう
“cronは現代のサーバ運用でなにが問題か。実行履歴がない。ログが自動で残らない。サーバ停止中に実行時刻を過ぎると実行しない。依存関係を書けないので起動順が曖昧”
anacron への言及がないのは不公平感がある。そういえば、fstab は systemd-fstab-generator になったのに cron はそのままなのって何か理由があるのかな。
cronの最大の問題はcrontab -eのタイプミスcrontab -rが設定全消しという落とし穴を含んでいるところ。crontab -rを無効にする設定を入れるという面倒くささ。メール送信失敗しまくってHDDが埋まってさようならとかもある
本題じゃないのは分かってるのですが、systemdの全体像がすごく分かりやすくて助かりました…。ソケットとかなんなん？とか思ってました…
cronで依存関係書けないからJP1入れたりしてたもんな。systemd timerが直観的に分かりづらいので移行する時に事故りそう。
「○○すれば今のまま運用できるのでは」が属人化しちゃうから、お作法ごと変える流れ
数百キロバイトのメモリで動くなんて、凄いよな。PC-9801の世界だぜ
6年前に手順書を書いたけど、cronに戻された記憶。時代が追いついた感がある
組込みだとスポット的な使い方ではcron使いがちな印象
でもsystemdって何でもかんでもできて哲学に反するよね。NWマネージャ部分だけ採用しないみたいなのもちょいちょいあるし何だかなって感じで。nspawnは重宝してる。
設定ファイルのフォーマットが分かりにくいしファイル自体も分散して分かりにくいというのが最大の問題だったと思う（systemdの設定ファイルも分かりにくいけども……）
全然知らなんだ
systemdは高級すぎるかなって感じ。
とは言えこんなクドクドとしたファイルを手作業で作るってのも…systemd全般に云えることだけど
systemdで起動しなきゃならなかったら最初からserviceとして書くよ。ログもlogrotateで回してるし。
certbotのはすでにsystemd timerへ移行している
でも、だいたいの言語にはcronを管理するライブラリはあるけど、systemdを管理するパッケージは無いんだよなぁ。
systemdが出てきた当初はでかすぎてもにょってたんだけど、これだけ流行ったってことは結局UNIX哲学なんてみんないらなかったんだろうなぁ
systemd timer はちょっとしたことでも２つも３つもファイルが必要になるのが面倒くさすぎて嫌になる
ちょうどこの土日でcronを全部systemd timerに移行した。AIにお願いすれば移行は秒で完了だし設定用のmakefileまで作ってくれた。コレどういう意味？と聞くと細かく教えてくれるし、なかなか楽しく週末を過ごせた
AI-assistedだとは思うが、今まさに「いまさらcronかぁ…」って仕事に向かうとこだったんで助かった
文章構造がものすごいAIぽい
わからなくもないんだがちょっとした掃除するスクリプトを設定したいだけとかだとsystemdの設定はめんどくさ…冗長に思えてしまってはいるな。cron並に簡易的に書くことできればなあ
cronさん、昔はすごかったけど、今はsystemd timerさんが人気にゃ～、ボクも新しいおもちゃが好きにゃ！
コストが下がらない限り移行しない。ログや再起動は逃げる方法ある。自分はいいけど、他の人の学習コストがあるからやりたくない。
ログにしても依存関係にしても呼び出された方の責務では？サーバ停止で実行されないって、それこそ定時外に動かれた方が怖いわ。次回に回すか手動でやれよ
cronの問題点を歴史的に整理し、systemd timerの利点と設定（2ファイル1セット、Persistent=true）を解説する記事です。
systemd良いとは思えないのだが、これも時代か
script.sh >> /var/log/script.log 確かにやってたわ
知らなんだ。 とはいえ、cronを使わなくなった理由もよくわかった。
なぜcronからsystemd timerへ移行しているのか？歴史と設計思想から理解する
ちょっと前までsystemdの方にもバグがまあまああって色々問題だったんですけどね
cronそのものはチープで単純なので、チープさが求められる環境では、まだまだ生き残りそう
そもそも最早cronを手動で設定することもないのでどっちでもいい。詳細を知らなくても勝手に設定されて使える機能の一つになってる。
めんどくさがりの私は生まれて最初に見たcronを親と思い込んでずっとあとをついて行くのだ……
ログとかは当たり前に自分でやってたからそこが弱点とは気がつかなかったけど自動でやってくれたら楽だな
systemd timer は、 スケジューリング プロセス管理 ログ 依存関係 再実行制御 を統合した仕組みです
AI臭い文は嫌ね。『cron は悪ではない』『ただし運用要件が変わった』 『systemd timer は「現代の正解」』『一言でまとめると』
時間設定見直すタイミングで、（分は何番目だっけかな…）って確実に調べ直すことになるツール
cronがいろいろと使いにくくて時代に合ってないのはそうだと思うが、代替がsystemd timer一択と言われるとなぁという気持ち。手軽にcronの欠点を多少なりとも改善するという意味では、dcronとかfcronとかもあるので、、、
私の既存個人開発系はまだまだcronで行きます
移行してること自体知らんかったわ…cronでできない範囲のことは呼ばれる側でやるべきだと思ってたけど、最近はそうでもないの？
anacronって何だったんだ
これは知らなかった。わかりやすい記事をありがとう。systemdをちゃんとわかってなかった。とてもためになった。
いや、メールで結果を受け取れるところがいいんだよ。私はこのためにわざわざメール送信を有効にした。https://blog.kobalab.net/entry/2024/11/06/195956
へー。cronは良くも悪くも単純だけどそうか、いきなりsystemdになっちゃうのか
AIが全部教えてくれる時代に学習コストがどうこう言ってるのは謎すぎる。systemdもansibleもterraformも人類よりAIの方が詳しい。人類は正解を選ぶだけでいい。
見返したらどっちも使ってた。失敗したらメールが欲しいときはcronで、systemdのタイマーはまた別方向から監視ツールでチェックしてた。そして結局メールが送られてくる。
「ここに挙げられてるcronの問題は*BSDでは（）あまり問題ではなく」「あとbatch（）でLoad avg.によって起動したりバッチキューの制御とか最重要jobの話が無い」という話があった＞https://x.com/daemon1995/status/2018343105574191301
UNIXの良さとは単純さ。cronの良さとはスケジュール実行という単機能だけであること。Linuxはなぜ、それら単純なものに連携させる何かを作らず、ipやssやchronydなど、車輪の再発明をするのか。
systemd
利点は理解できるし自分でも使ってるんだけど、systemdの守備範囲が広すぎてどんどん肥大化していることに一抹の不安を感じざるを得ない。もっと分担できないものだろうかね。
もう何年もまともにLinuxを触ってないからたまにちょっといじる時にsystemdが出てくると意味不明で困ってた。なんとなく全体像がわかったのでsystemdを嫌いにならずに済みそう
自分が触ってるサーバタスク詰め込みすぎて魔のcron城になってる
まとめの書きっぷりがちゃっぴーっぽいけどそれはさておき、cronがこれでいいのはジョブ管理をちゃんとやりたかったら外部ツール（TWS（名前変わったっけ？）とかJP1とか…）を使うべきだからなんだよ。
systemdは実質ジョブスケジューラーだからな、デフォルトで多重起動制御が入ってるし標準出力に出力するだけでjournalや独自ログファイルに出力してくれたりファイル監視で起動できたりと一通り欲しい機能が揃ってる
なぜcronからsystemd timerへ移行しているのか？歴史と設計思想から理解する
未だにcrontab -eしちゃう老兵だけど、ログ周りの貧弱さを考えると移行は必然か
いろんな要素がsystemdに吸い込まれているけれども、非Linuxでinitライクな仕組みがあったOS、ディストリビューション向けに挙げている課題を解消するcron代替ってあるのかな
logger にパイプで渡せばいいだけでは？＞cronのログ
“しかし近年では、 新規サーバ構築では cron を使わない systemd timer が推奨される cron は「保守対象」になりつつある ”
でも、systemd timerはcronと違ってメール通知してくれないので悪だと思いました。メール通知ユニットを自前実装すれば可能だしそこまで手間も要らないけど、だからこそパッケージに標準で含めておいて欲しい。
そうなんだ。移行した方がメリット多そう
“cronは現代のサーバ運用でなにが問題か。実行履歴がない。ログが自動で残らない。サーバ停止中に実行時刻を過ぎると実行しない。依存関係を書けないので起動順が曖昧”
anacron への言及がないのは不公平感がある。そういえば、fstab は systemd-fstab-generator になったのに cron はそのままなのって何か理由があるのかな。
cronの最大の問題はcrontab -eのタイプミスcrontab -rが設定全消しという落とし穴を含んでいるところ。crontab -rを無効にする設定を入れるという面倒くささ。メール送信失敗しまくってHDDが埋まってさようならとかもある
本題じゃないのは分かってるのですが、systemdの全体像がすごく分かりやすくて助かりました…。ソケットとかなんなん？とか思ってました…
cronで依存関係書けないからJP1入れたりしてたもんな。systemd timerが直観的に分かりづらいので移行する時に事故りそう。
「○○すれば今のまま運用できるのでは」が属人化しちゃうから、お作法ごと変える流れ
数百キロバイトのメモリで動くなんて、凄いよな。PC-9801の世界だぜ
6年前に手順書を書いたけど、cronに戻された記憶。時代が追いついた感がある
組込みだとスポット的な使い方ではcron使いがちな印象
でもsystemdって何でもかんでもできて哲学に反するよね。NWマネージャ部分だけ採用しないみたいなのもちょいちょいあるし何だかなって感じで。nspawnは重宝してる。
設定ファイルのフォーマットが分かりにくいしファイル自体も分散して分かりにくいというのが最大の問題だったと思う（systemdの設定ファイルも分かりにくいけども……）
全然知らなんだ
systemdは高級すぎるかなって感じ。
とは言えこんなクドクドとしたファイルを手作業で作るってのも…systemd全般に云えることだけど
systemdで起動しなきゃならなかったら最初からserviceとして書くよ。ログもlogrotateで回してるし。
certbotのはすでにsystemd timerへ移行している
でも、だいたいの言語にはcronを管理するライブラリはあるけど、systemdを管理するパッケージは無いんだよなぁ。
systemdが出てきた当初はでかすぎてもにょってたんだけど、これだけ流行ったってことは結局UNIX哲学なんてみんないらなかったんだろうなぁ
systemd timer はちょっとしたことでも２つも３つもファイルが必要になるのが面倒くさすぎて嫌になる
ちょうどこの土日でcronを全部systemd timerに移行した。AIにお願いすれば移行は秒で完了だし設定用のmakefileまで作ってくれた。コレどういう意味？と聞くと細かく教えてくれるし、なかなか楽しく週末を過ごせた
AI-assistedだとは思うが、今まさに「いまさらcronかぁ…」って仕事に向かうとこだったんで助かった
文章構造がものすごいAIぽい
わからなくもないんだがちょっとした掃除するスクリプトを設定したいだけとかだとsystemdの設定はめんどくさ…冗長に思えてしまってはいるな。cron並に簡易的に書くことできればなあ
cronさん、昔はすごかったけど、今はsystemd timerさんが人気にゃ～、ボクも新しいおもちゃが好きにゃ！
コストが下がらない限り移行しない。ログや再起動は逃げる方法ある。自分はいいけど、他の人の学習コストがあるからやりたくない。
ログにしても依存関係にしても呼び出された方の責務では？サーバ停止で実行されないって、それこそ定時外に動かれた方が怖いわ。次回に回すか手動でやれよ
cronの問題点を歴史的に整理し、systemd timerの利点と設定（2ファイル1セット、Persistent=true）を解説する記事です。
systemd良いとは思えないのだが、これも時代か
script.sh >> /var/log/script.log 確かにやってたわ
知らなんだ。 とはいえ、cronを使わなくなった理由もよくわかった。
なぜcronからsystemd timerへ移行しているのか？歴史と設計思想から理解する
ちょっと前までsystemdの方にもバグがまあまああって色々問題だったんですけどね
cronそのものはチープで単純なので、チープさが求められる環境では、まだまだ生き残りそう
そもそも最早cronを手動で設定することもないのでどっちでもいい。詳細を知らなくても勝手に設定されて使える機能の一つになってる。
めんどくさがりの私は生まれて最初に見たcronを親と思い込んでずっとあとをついて行くのだ……
ログとかは当たり前に自分でやってたからそこが弱点とは気がつかなかったけど自動でやってくれたら楽だな
systemd timer は、 スケジューリング プロセス管理 ログ 依存関係 再実行制御 を統合した仕組みです
AI臭い文は嫌ね。『cron は悪ではない』『ただし運用要件が変わった』 『systemd timer は「現代の正解」』『一言でまとめると』
時間設定見直すタイミングで、（分は何番目だっけかな…）って確実に調べ直すことになるツール
cronがいろいろと使いにくくて時代に合ってないのはそうだと思うが、代替がsystemd timer一択と言われるとなぁという気持ち。手軽にcronの欠点を多少なりとも改善するという意味では、dcronとかfcronとかもあるので、、、
私の既存個人開発系はまだまだcronで行きます
移行してること自体知らんかったわ…cronでできない範囲のことは呼ばれる側でやるべきだと思ってたけど、最近はそうでもないの？
anacronって何だったんだ
これは知らなかった。わかりやすい記事をありがとう。systemdをちゃんとわかってなかった。とてもためになった。
いや、メールで結果を受け取れるところがいいんだよ。私はこのためにわざわざメール送信を有効にした。https://blog.kobalab.net/entry/2024/11/06/195956
へー。cronは良くも悪くも単純だけどそうか、いきなりsystemdになっちゃうのか
AIが全部教えてくれる時代に学習コストがどうこう言ってるのは謎すぎる。systemdもansibleもterraformも人類よりAIの方が詳しい。人類は正解を選ぶだけでいい。
見返したらどっちも使ってた。失敗したらメールが欲しいときはcronで、systemdのタイマーはまた別方向から監視ツールでチェックしてた。そして結局メールが送られてくる。
「ここに挙げられてるcronの問題は*BSDでは（）あまり問題ではなく」「あとbatch（）でLoad avg.によって起動したりバッチキューの制御とか最重要jobの話が無い」という話があった＞https://x.com/daemon1995/status/2018343105574191301
UNIXの良さとは単純さ。cronの良さとはスケジュール実行という単機能だけであること。Linuxはなぜ、それら単純なものに連携させる何かを作らず、ipやssやchronydなど、車輪の再発明をするのか。
systemd
利点は理解できるし自分でも使ってるんだけど、systemdの守備範囲が広すぎてどんどん肥大化していることに一抹の不安を感じざるを得ない。もっと分担できないものだろうかね。
もう何年もまともにLinuxを触ってないからたまにちょっといじる時にsystemdが出てくると意味不明で困ってた。なんとなく全体像がわかったのでsystemdを嫌いにならずに済みそう
自分が触ってるサーバタスク詰め込みすぎて魔のcron城になってる
まとめの書きっぷりがちゃっぴーっぽいけどそれはさておき、cronがこれでいいのはジョブ管理をちゃんとやりたかったら外部ツール（TWS（名前変わったっけ？）とかJP1とか…）を使うべきだからなんだよ。
systemdは実質ジョブスケジューラーだからな、デフォルトで多重起動制御が入ってるし標準出力に出力するだけでjournalや独自ログファイルに出力してくれたりファイル監視で起動できたりと一通り欲しい機能が揃ってる