久しぶりのサーバネタです。せめて仕事になるネタでも書かないとだめなのに…と思いながら書いています。
Fedora30のlogrotateがなぜか動作していない?
今現在Fedoraを入れているサーバはプログラムやWebサイトなどの動作テストを行うためのサーバなのですが、それだけではもったいないのでffmpegを入れてとあるバッチスクリプトを書いておくことで動画エンコードサーバとしています。これはまあいいのですが、今日気がついてみるとサーバが応答しなくなっているという事態に。テスト用のサーバなので、電源を強制OFFにした後付け直してログによっていつ、何が起こったのか把握しようと思っていたのですが…。/var/log以下を見てびっくり。
なんとFedora30を入れてから今日までのログが一つのファイルに固まったまま巨大なログファイルとなっていました…。
まあ、外部からのアクセスもほとんどないサーバですし、セキュリティ的な問題でもないでしょうからまだましなのですが、何かあったときの追跡が非常にやりづらいこと。気がついてよかったです。で、そうなると今までログファイルを分割していたlogrotateは一体何をやっていたのか?ということで少し追跡してみました。
systemctlに管理された場合のlogrotateはcronで動作させた場合と少し違う
いつ切り替わったのかよく分からないのですが…。今現在使っているCentOS7ではlogrotateはcronが一定期間ごとに動かすように設定されているのですが、Fedora30ではsystemctlがlogrotateを起動するように設定されているようです。で、これの設定が今までと違うやり方になっていてびっくり。どうなっているかというと
- systemctlに登録されているlogrotate.serviceは「systemctlのタイマで一定期間ごとに呼び出されるログ処理を一度だけ行うスクリプト」という扱い。
- 「一定期間」を設定しているのはsystemctlが持っているタイマの機能で、これは/usr/lib/systemd/system/logrotate.timerで定義されている
というわけで、logrotateを動作させるスクリプトとlogrotateを「一定期間ごとに」動作させるスクリプトは別になっているという理屈です。このsystemctlがタイマを持ち、一定期間ごとに動作させる、というのがこれを考える肝になるようで、systemctlからlogrotate.serviceの動作を見ても状態が「inactive (dead)」となっていますが、これは「そのタイミングでは動いていない」だけで、常駐している(定期的に動作するように設定されている)かどうかは別の方法で確認しなければいけない、ということになります。
デフォルトでlogrotate.timerは登録されていないのか・・・?
確認するためには
$ sudo systemctl list-timers --all
を使います。これでlogrotate.timerに関する行が存在する場合(コマンド実行中は左右キーが効くので右も確認する)はlogrotateが一定期間で動くのですが、関する行がない場合はlogrotateは動かない、ということになるようです。きちんと動作させるには
$ sudo systemctl enable logrotate.timer $ sudo systemctl start logrotate.timer
により動作を追加する必要があります。タイマが登録されればlogrotateはlogrotate.timerに記述されている一定期間で動くようになる、ということになります。
ほかにsystemctlのtimerで抜けているものがあるのでは…?
ちょっと気になったのがこのこと。システムのログ処理で重要な部分であるlogroateがこれなので、ほかの「一定期間ごとに動作するサービス」の部類で同じようなものがある可能性があるな~と考えたからです。見つけた段階で一つ一つ登録していく必要があるのでしょうかね。
cronとsystemctlのタイマ処理との棲み分けとなるのか?
ちょっと気になるところです、cronの機能をsystemctlがある程度持つのであればcronを吸収することになるのか、システムの中心と簡単なバッチ処理のように棲み分けるのか、これからの発展が少し気になるな~と思っています。