DigiLoog

表題そのまんまなのだが、自分は躓いたので備忘録 (´・ω・｀)

“ns-lab BB”では、数台の自宅サーバがopenSUSEで稼働しているのだが、
Leap42.3にアップデートした所、logrotateが指定時間通りに処理出来なくなり、
『なんでcronで設定しても、指定通りに動かないんだろう…』と頭を悩ませていた。

色々と試行錯誤していた所「logrotate の daily 指定」のみ指定通りに動いて居ない事が判明。
デバッグをさらに進めた所、logrotatedのdaily設定のみ「systemd.timer」に移行している事がわかった。

なぜか「timers.target.wants」の中にlogrotateがdaily指定で設定されていた。
weaklyなどdaily以外については、今まで通りrun-cronsで処理されていた。
ちなみに、別途裏で走らせているスクリプトの兼ね合いで、logrotateは32分開始にずらしてある。
時間指定方法などはコチラを見ると、例文含めて載っているのでわかりやすい。

最初は、systemd.timerの設定を削除して今まで通りのcronにしようかと思いもしたのだが、
今後のロードマップ見ると、cron自体がsystemd.timerに移行していくのが目に見えていたので、
logrotateについてもsystemd.timerで制御する事にしてみた。

最初は設定に戸惑いもあったのだが、慣れてみるとsystemd.serviceとの連携が楽だったり、
スクリプトの実行タイミングを秒単位で設定出来るので、
ミッションクリティカルなシステムでは、使い方次第で強力なスケジューリングシステムになるかも。

systemd.timerの場合、スケジューラの表示が「systemctl list-timers」というコマンドになっているので、
cronで慣れていた(自分の様な)人は非常に抵抗がある。
ただし、前述の通り細かい時間指定が出来るのは魅力なので、今後は積極的に使ってみようと思う。