로그 파일이 회전 된 다음 원래 크기와 같은 크기로 돌아 가기 전에 logrotate에 문제가있는 사람이 있습니까? 내 결과는 다음과 같습니다.
로그 스크립트 :
/var/log/mylogfile.log {
회전 7
매일
압박 붕대
olddir / log_archives
missingok
공증인
카피
}
Logrotate의 상세 출력 :
/var/log/mylogfile.log를 /log_archives/mylogfile.log.1로 복사 /var/log/mylogfile.log 절단 / bin / gzip을 사용하여 로그 압축 이전 로그 /log_archives/mylogfile.log.8.gz 제거
자르기 후 로그 파일
[root @ server ~] # ls -lh /var/log/mylogfile.log -rw-rw-r-- 1 part1 part1 1 월 11 일 17:32 /var/log/mylogfile.log
말 그대로 초 :
[root @ server ~] # ls -lh /var/log/mylogfile.log -rw-rw-r-- 1 part1 part1 3.5G 1 월 11 일 17:32 /var/log/mylogfile.log
RHEL 버전 :
[root @ server ~] # cat / etc / redhat-release Red Hat Enterprise Linux ES 릴리스 4 (Nahant 업데이트 4)
로그 로테이트 버전 :
[root @ DAA21529WWW370 ~] # rpm -qa | grep logrotate logrotate-3.7.1-10.RHEL4
몇 가지 참고 사항 :
- 서비스를 즉시 다시 시작할 수 없으므로 copytruncate를 사용하는 이유입니다
- 매일 밤
olddir부터 로그 파일 이있는 디렉토리 에 따라 매일 밤 로그가 회전합니다 .
답변
파일을 자르더라도 파일에 쓰는 프로세스는 마지막에 오프셋을 기록 할 때마다 쓰기를 계속하기 때문일 수 있습니다. 그래서 일어나고있는 것은 logrotate가 파일을 자르고, 크기가 0이며, 프로세스가 파일에 다시 쓰는 것을 중단하고, 오프셋 된 위치에서 계속해서 파일을 자르는 지점까지 NULL 바이트 파일을 얻습니다. 로그에 기록 된 항목.
절단 + 갑작스런 성장 후 od -c는 다음 라인을 따라 출력을 생성합니다.
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
33255657600 \0 C K B - s e r v e r [ h t t
33255657620 <more log output>
이것이 말하는 것은 오프셋 0에서 33255657600까지입니다. 파일은 null 바이트와 읽을 수있는 데이터로 구성됩니다. 이 상태에 도달하는 데 실제로 해당 널 바이트를 모두 쓰는 데 걸리는 시간과 동일하지 않습니다. ext {2,3,4} 파일 시스템은 스파 스 파일 (sparse files)이라는 것을 지원하므로 아무것도 포함하지 않은 파일의 영역을 지나서 찾는 경우 해당 영역은 널 바이트를 포함하고 공간을 차지하지 않는 것으로 간주됩니다. 디스크에. 이 null 바이트는 실제로 작성되지 않으며 거기에 있다고 가정하므로 0에서 3.5GB로 이동하는 데 시간이 오래 걸리지 않습니다. (와 같은 작업을 수행하는 데 걸리는 시간을 테스트 할 수 있습니다. 이렇게 dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1하면 몇 밀리 초 안에 3GB가 넘는 파일이 생성됩니다).
ls -ls로그 파일이 잘린 후 다시 갑자기 증가한 후 로그 파일 을 실행 하는 경우 이제 줄의 시작 부분에 실제 크기 (디스크에 점유 된 블록 단위)를 나타내는 숫자를보고해야합니다. 에 의해보고 된 크기보다 작습니다 ls -l.
답변
나는 매우 Kjetil가 충돌했다고 확신. 드류, 당신은 아직 그의 설명에 확신을 갖지 못할 수도 있지만, 나는 당신이 그가 한 말을주의 깊게 읽을 것을 촉구합니다.
수락하면 로그를 회전 할 때 응용 프로그램을 중지했다가 다시 시작하거나 아파치의 “rotatelogs”와 같은 도구를 사용하여 로그 출력을 파이프를 통해 도구에 공급하면 도구가 처리합니다. 로그 파일을 너무 자주 회전시킵니다. 예를 들어, 내 아파치 인스턴스 중 하나가
ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"
이 같은 이름의 로그 파일을 많이 발생
-rw-r--r-- 1 root root 4078 Dec 21 01:04 error_log.1292457600
-rw-r--r-- 1 root root 4472 Dec 29 08:41 error_log.1293062400
-rw-r--r-- 1 root root 78630 Jan 4 12:57 error_log.1293667200
-rw-r--r-- 1 root root 15753 Jan 12 01:10 error_log.1294272000
아파치를 다시 시작하지 않고 나타납니다. 그런 다음 사실 후에 수동으로 압축 할 수 있습니다. 인수가 전달되는 매주 (604800 초마다) 로테이션이 수행되는 방식에 유의하십시오 rotatelogs.
앱을 중지했다가 다시 시작할 수없고 파이프를 통해 기록 할 수 없다면 실제로 문제가있는 것 같습니다. 아마도 다른 사람들은 제안을 할 것입니다.
답변
전체 logrotate를 보낼 수 있다면 정말 좋을 것입니다.
kill -HUP을 사용하는 이유는 무엇입니까? (클래식 리로드 가 다시 시작되지 않음 ) 메소드.
또한 … lsof 누가 파일에 액세스하고 있는지 확인 하십시오.
답변
이 파일에 쓰는 스크립트에서 작성하는 것을 의미하는 “>”대신 “>>”를 사용하십시오. 나는 똑같은 문제가 있었고 스크립트에서 append를 사용하여 문제를 해결했습니다.
SomeScript.sh >> output.txt
그것이 더 명확하기를 바랍니다.