서버에서만 로그 로테이션이 실패할 때

매일 밤 자동으로 실행되어야 하는 logrotate가 서버에서만 계속 실패한다. 로컬에서는 잘 되는데, 왜 서버에서만 문제가 나는가.

logrotate 설정 파일 확인

logrotate 설정은 보통 /etc/logrotate.d/ 디렉토리에 있다. 자신의 애플리케이션 설정을 먼저 확인한다.

cat /etc/logrotate.d/myapp

일반적인 설정은 이렇다:

/var/log/myapp/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 myapp myapp
    sharedscripts
}

각 항목이 무엇인지 아는 게 중요하다:

• create: 새 로그 파일의 권한과 소유자 (사용자:그룹)
• missingok: 로그 파일이 없어도 에러 나지 않음
• rotate: 보관할 이전 로그 파일 개수
• compress: 오래된 로그 압축

로그 로테이션 수동 테스트

매일 자동 실행되는 cron job이 정말 실행되는지 확인한다.

logrotate -v /etc/logrotate.d/myapp

-v (verbose) 플래그로 상세히 본다. 에러가 있다면 여기서 나타난다.

만약 에러가 안 난다면 sudo를 붙여본다:

sudo logrotate -v /etc/logrotate.d/myapp

권한 문제가 있을 수 있기 때문이다.

디스크 용량 확인

logrotate가 파일을 이동하려면 디스크에 충분한 여유 공간이 있어야 한다.

df -h /var/log

특히 /var/log 파티션이 거의 가득 차 있으면 로테이션이 실패할 수 있다.

권한 확인

logrotate는 기본적으로 root로 실행되지만, create 옵션에서 지정한 사용자와 그룹이 정말 존재하는지 확인한다.

id myapp

사용자가 없으면 logrotate가 새 파일을 만들 수 없다.

또한 로그 파일의 현재 소유자도 확인한다:

ls -la /var/log/myapp/

myapp 사용자가 소유하지 않은 파일이 있다면, logrotate가 권한 문제로 실패할 수 있다.

cron 로그 확인

logrotate는 보통 cron으로 매일 실행된다. cron 로그를 보면 정말 실행되었는지, 또는 실패했는지 알 수 있다.

sudo grep logrotate /var/log/syslog

또는 systemd journal을 확인:

sudo journalctl -u logrotate

만약 cron이 실행되지 않았다면 cron 서비스가 죽어있거나 권한 문제가 있다는 뜻이다.

로컬과 서버의 환경 차이

로컬과 서버의 차이점:

• logrotate 버전 차이
• 사용자/그룹 정의 차이
• 디스크 여유 공간
• cron 실행 권한

이들을 하나씩 확인하면 대부분의 logrotate 문제를 해결할 수 있다.

확인 순서

1. 설정 파일 문법 확인: logrotate -d /etc/logrotate.d/myapp (dry run)
2. 권한 확인: id myapp 및 로그 파일 소유자
3. 디스크 여유 공간: df -h /var/log
4. 수동 테스트: sudo logrotate -v /etc/logrotate.d/myapp
5. cron 실행 로그 확인: sudo journalctl -u logrotate 또는 syslog

logrotate가 제대로 작동하면 디스크 사용량이 자동으로 관리되고, 서버 안정성이 올라간다.