/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.d
logrotate
만약 너라면필요시스템 기본 로그 회전보다 더 자주 회전을 실행하려면 myFile
구성을 다른 곳에 배치하는 것이 좋습니다.
순환 작업이 동일한 상태 파일을 사용하지 않도록 하려면(순환 작업이 시스템의 로그 순환 작업과 동시에 실행될 수 있는 경우) 다른 상태 파일을 사용하십시오.
/usr/sbin/logrotate -f -s /some/location/myFile.state /some/location/myFile
로그 파일을 루트나 자신이 아닌 사용자가 소유하지 않는 한 이 작업은 루트로 실행할 필요가 없습니다. 즉, 로그 파일이 본인 소유인 경우 개인 크론 작업에서 해당 파일을 순환할 수 있습니다.