질문
logrotate
동일한 구성을 실행하고 사용자 정의 로그 파일을 순환하는 여러 개의 동일한 서버가 있습니다 . 하나 이상의 서버에서 내 로그가 올바르게 순환되지 않습니다.
나는 이 문제를 해결하기 위해 몇 주 동안 계속 노력했지만 성공하지 못했습니다. 여기에 제가 지금까지 취한 단계와 좀 더 자세한 정보가 나와 있습니다. 어떤 도움이라도 대단히 감사하겠습니다.
기본적으로 이 문제를 해결하기 위한 아이디어가 부족하며 여기서 무엇이 잘못되었는지 확인하기 위한 몇 가지 아이디어를 원합니다.
내가 시도한 것
(구성 파일은 다음과 같습니다)
logrotate
기본 파일의 구성과 권한을 확인하세요 . 나는 거기 모든 것이 괜찮다고 생각합니다.- logrotate에 필요한 권한으로 대상 디렉터리의 권한을 설정합니다
derp
(디렉토리는 누구나 쓸 수 없습니다).AFAIK). logrotate
다음 명령을 강제 로 실행합니다.logrotate --force /etc/logrotate.d/derp
이 명령은 로그를 올바르게 순환하지만 다음 날에는 실행되지 않습니다.
수동으로 날짜를 과거의 특정 시간으로 변경 하고 다음 부팅 시
/var/lib/logrotate/status
로그가 올바르게 실행되는지 확인 하거나 다음을 사용하세요.logrotate
logrotate -vv /etc.logrotate.d/derp
이렇게 하면 로그가 한 번 회전되지만 다음 번에 로그가 회전될 때는 회전되지 않습니다. 성공적인 수동 회전의 결과는 다음과 같습니다.
rotating pattern: /derp/*.log after 1 days (14 rotations) empty log files are not rotated, old logs are removed considering log /derp/access.log log needs rotating considering log /derp/php_errors.log log does not need rotating rotating log /derp/access.log, log->rotateCount is 14 dateext suffix '-20150814' ... files getting renamed and moved ... running prerotate script renaming /derp/access.log to /derp/access.log.1 creating new /derp/access.log mode = 0774 uid = 0 gid = 4 running postrotate script
인생은 아름답지 않나요? 유일한 문제는 다음 날 회전해야 할 때(즉, 항상 데이터가 있고 결코 비어 있지 않음) 아무 일도 일어나지 않는다는 것입니다.
저는 SEU 문제를 포함한 많은 문제에 대해 컨설팅을 해왔습니다.이 문제이는 과거에 다른 logrotate 문제를 처리할 때 도움이 되었습니다.
구성
시스템은 최신 Debian 7을 실행하고 있습니다. 로그 파일을 생성하는 프로세스는 루트로 실행됩니다. 로그 파일을 생성하는 프로세스는 php
애플리케이션이며 여러 하위 프로세스를 생성합니다.
관련 구성은 다음과 같습니다. derp
내 사용자 정의 로그 파일의 위치는 다음과 같습니다.
/etc/logrotate.d/derp
구성 파일 권한:
-rw-r--r-- 1 root root 265 Jul 9 2014 derp
/derp/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 774 root adm
sharedscripts
postrotate
nohup /derp/daemonrestart.sh > /dev/null 2>&1
endscript
prerotate
killall -9 php > /dev/null 2>&1
endscript
}
prerotate
스크립트는 postrotate
기본적으로 프로세스(소켓 서버)를 시작하거나 중지하고 다른 모든 서버에서 잘 작동합니다. 나는 거기에 아무런 문제가 없다고 확신합니다.
/var/lib/logrotate/status
(관련 정보를 표시하도록 편집됨)
logrotate state -- version 2
"/var/log/kern.log" 2015-7-20
...
"/derp/php_errors.log" 2015-8-11
...
"/derp/access.log" 2015-8-14
...
/derp/
대상 디렉터리의 권한:
drwxr-xr-x 2 root root 4096 Jun 18 10:05 derp
관련 로그는 다음 위치에 있습니다 \derp\
.
-rwxrwxr-- 1 root adm 3755558 Aug 14 07:57 access.log
답변1
당신은 다음과 같이 썼습니다:
다음 명령을 사용하여 logrotate를 강제 실행합니다.
logrotate --force /etc/logrotate.d/derp
. 이 명령은 로그를 올바르게 회전하지만 다음 날에는 실행되지 않습니다.
여기서 문제는 daily
속성이 실제로 "24시간"을 의미한다는 것입니다. 따라서 cron
로그 파일을 수동으로 교체한 후 항목이 24시간을 넘지 않는 한 해당 날짜 이후까지 로그 파일은 교체되지 않습니다 .logrotate
/etc/cron.d/daily
내 Debian 시스템에서는 항목이 /etc/cron.daily
매일 06:25에 실행되므로 정규 근무일 동안 수행된 수동 로그 회전으로 인해 이틀 후까지 로그 회전이 발생하지 않을 수 있습니다.
답변2
글쎄, 나는 이 문제를 고치려는 노력을 포기했습니다. 크로네가 구조하러 옵니다.
sudo crontab -e
그런 다음 슈퍼유저의 crontab에 다음 줄을 추가합니다.
# Logrotate they said...
3 6 * * * /usr/sbin/logrotate -f /etc/logrotate.d/derp &> /dev/null
이 -f
플래그는 logrotate가 로그를 회전하도록 강제합니다. 찾은 파일은 /etc/logrotate.d/derp
내 애플리케이션에 해당하는 logrotate 구성입니다.
보기 흉하지만 이것이 이 오류를 해결할 수 있는 유일한 방법입니다.