CentOS7でなぜかログローテーションが止まっていた場合の対処メモ

スポンサーリンク
Linux
スポンサーリンク
↑管理人が個人でUnity+Live2Dで作成しているスマホゲームです

先日久々にサーバの状態チェックで「df -h」を実行した所、妙に空き容量が減っている事に気付きました。「du -sh」で各ディレクトリの総サイズをチェックしていった所、どうやら/var/log/nginx/access.logが20G程までに肥大化している事が判明。しかも直近の圧縮済みログファイルのアーカイブが半年前。

スポンサーリンク

logrotatedの設定をチェック

/etc/logrotate.d/nginxの設定をチェックして、ローテーションの日数を変えたりしてみましたが変化なし。

crondをチェック

systemctl status crond
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since 月 2021-05-24 23:14:46 JST; 6 months 1 days ago
 Main PID: 578 (crond)
   CGroup: /system.slice/crond.service
           └─578 /usr/sbin/crond -n

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

crondのstatusチェックするとジャーナルに何やらwarningが。ログ周りにエラーが出ているぽいです。

systemd-journaldをチェック

systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since 月 2021-05-24 23:14:45 JST; 6 months 1 days ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 385 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─385 /usr/lib/systemd/systemd-journald

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

systemd-journaldを調べると同様のエラーが。

systemd-journaldを再起動して再チェック

systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since 水 2021-11-24 17:12:58 JST; 10s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 16537 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─16537 /usr/lib/systemd/systemd-journald

11月 24 17:12:58 www.*.* systemd-journal[16537]: Runtime journal is using 200.0M (max allowed 197.5M, trying to leave 296.3M free of 1.5G available → current limit 200.0M).
11月 24 17:12:58 www.*.* systemd-journal[16537]: Runtime journal is using 200.0M (max allowed 197.5M, trying to leave 296.3M free of 1.5G available → current limit 200.0M).
11月 24 17:12:58 www.*.* systemd-journal[16537]: Journal started
Hint: Some lines were ellipsized, use -l to show in full.

再起動してチェックすると、メッセージが変わり正常になったようです。
ジャーナルの使用領域サイズも出ています。ついでに一時領域(Runtime)から永続領域(Persistent)にジャーナルの保存領域を変更し、サイズも500Mにしようと思います。

/etc/systemd/journald.confを編集

SystemMaxUse=500M

journald.confに上記を追記します。再起動したのですが反映されません。ジャーナルログがtmpfsに保存されている(モードがautoかつ/var/log/journalが無い)からです。ジャーナルログ保存場所を不揮発領域に作る事で変更しておきます。

mkdir -p /var/log/journal
chmod 755 /var/log/journal

systemd-journaldを再起動(chmodしておかないとここでJob for systemd-journald.service failed because a fatal signal was delivered causing the control process to dump core. See “systemctl status systemd-journald.service” and “journalctl -xe” for details.というエラーが出る)したらステータスが変わりました。

systemctl status systemd-journald
● systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
   Active: active (running) since 水 2021-11-24 17:27:47 JST; 22s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 16900 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─16900 /usr/lib/systemd/systemd-journald

11月 24 17:27:47 www.*.* systemd-journal[16900]: Permanent journal is using 173.0M (max allowed 500.0M, trying to leave 4.0G free of 18.6G available → current limit 500.0M).
11月 24 17:27:47 www.*.* systemd-journal[16900]: Journal started

crondも再起動するとcrondのステータスも正常に変わりました。

systemctl status crond
● crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since 水 2021-11-24 17:31:21 JST; 5s ago
 Main PID: 16967 (crond)
   CGroup: /system.slice/crond.service
           └─16967 /usr/sbin/crond -n

11月 24 17:31:21 www.*.* systemd[1]: Started Command Scheduler.
11月 24 17:31:21 www.*.* systemd[1]: Starting Command Scheduler...
11月 24 17:31:21 www.*.* crond[16967]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 5% if used.)
11月 24 17:31:21 www.*.* crond[16967]: (CRON) INFO (running with inotify support)
11月 24 17:31:21 www.*.* crond[16967]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

logrotateを強制実行

logrotateを強制実行しログが切り替わるか確認します。

logrotate -f /etc/logrotate.conf
error: error creating output file /var/log/nginx/access.log-20210501.gz: ファイルが存在します
error: error creating output file /var/log/nginx/error.log-20210501.gz: ファイルが存在します

何かおかしいようです。よくよく/var/log/nginxを見てみると

-rw-r----- 1 nginx adm 17955058897 11月 23 18:46 access.log
-rw-r----- 1 nginx adm     8491649  3月 11  2021 access.log-20210311.gz
...
-rw-r----- 1 nginx adm     8708127  4月 30  2021 access.log-20210430.gz
-rw-r----- 1 nginx adm   105332820  5月  1  2021 access.log-20210501
-rw-r----- 1 nginx adm     3796992  5月  2  2021 access.log-20210501.gz
-rw-r----- 1 nginx adm    30652606 11月 24 17:15 error.log

と、access.log-20210501がアーカイブとそうでないものと2つ存在しています。
ログローテートのエラーはこれが原因かもしれません。

rm /var/log/nginx/access.log-20210501                                                                                                                                                                                                                      
rm: 通常ファイル `/var/log/nginx/access.log-20210501' を削除しますか? y
rm /var/log/nginx/error.log-20210501
rm: 通常ファイル `/var/log/nginx/error.log-20210501' を削除しますか? y
logrotate -f /etc/logrotate.conf

重複ログファイルを削除すると、正常にログローテートが行われました!
ついでに肥大化したログも削除。これで問題なさそうです。

1 Star2 Stars3 Stars4 Stars5 Stars (まだ投票されていません)
読み込み中...

コメント

広告ブロッカーを無効にしてください。

タイトルとURLをコピーしました