/var/lib/logrotate/status以下のように項目が無効であることがわかります。
saurabh@1236:~$ cat /var/lib/logrotate/status
logrotate state -- version 2
"/var/log/syslog" 2018-3-13
"/var/log/auth.log" 2018-3-13
"/var/log/debug" 2018-3-13
"/var/log/lpr.log" 2018-3-13
"/var/log/user.log" 2018-3-13
"/var/log/mail.info" 2018-3-13
"/var/log/cron.log" 2018-3-13
og/messages" 2018-3-13 <=== Corrupted entry
"/var/log/cron.log" 2018-3-13
"/var/log/messages" 2018-3-13
このようにしてどのように損傷したのかわかりません。 10/12日後にランダムに発生します。
私の考えでは、このファイルを編集しようとする複数の試みのためにこのファイルを編集する複数のクローンが原因でこの問題が発生する可能性がありますが、それが問題かどうかはわかりません。最近追加したクローンのいずれかにランダムな遅延を追加したかどうかをテストするには、次の手順を実行します。
*/10 * * * * root sleep $(expr $RANDOM \% 90); /usr/sbin/logrotate -f /etc/logrotate.d/myFile
特定のソリューションに対するより良い提案はありますか？
ベストアンサー1
コンピュータでlogrotate実行されているcronジョブの複数の同時インスタンスがあります。使用されているステータスファイルはロックされていないため、logrotate更新時にさまざまなタスクが「互いにつま先を踏みます」。
ディレクトリに構成を追加したので、myFile別のクローン操作で明示的に構成を循環させる必要はありません。通常のcronジョブの実行は自動的にこの設定を選択します。logrotate/etc/logrotate.dlogrotate
もしあなたなら必要システムのデフォルトのログ回転よりも頻繁に回転を実行するには、設定myFileを別の場所に配置することをお勧めします。
循環ジョブが同じ状態ファイルを使用しないようにするには（循環ジョブがシステムのログ循環ジョブと同時に実行できる場合）、別の状態ファイルを使用します。
/usr/sbin/logrotate -f -s /some/location/myFile.state /some/location/myFile
ログファイルをrootまたは自分以外のユーザーが所有していない限り、この操作はrootとして実行する必要はありません。つまり、ログファイルが自分の所有者である場合は、プライベートクローン操作でそのファイルを循環させることができます。