logrotate 실행 뒤 새 로그 파일은 생겼는데 크기가 늘지 않는다면, 파일 생성만으로 순환이 끝났다고 판단하기 어렵습니다. 애플리케이션이 이전 파일에 계속 기록하는지, 새 파일을 열지 못했는지부터 확인하고, 그 다음 log rotate 설정을 점검합니다. 이 점검을 소홀히 한다면 기존 로그파일에 적재되어 초반의 로그는 사라질 수도 있습니다.
이 글은 Linux에서 일반 파일에 직접 기록하는 애플리케이션을 대상으로 파일 교체와 로그 재열기 사이의 점검 순서를 설명합니다.
파일 이름이 바뀌어도 열린 파일은 유지
가정해 보겠습니다. app.log를 app.log.1로 이름 변경하고 같은 경로에 새 app.log를 만들었지만, 서비스는 기존 파일을 계속 열고 있습니다. 프로세스가 사용하는 파일 디스크립터는 열린 파일을 가리키는 번호이므로, 같은 이름의 파일이 다시 생겼다고 기록 대상이 자동으로 바뀌지는 않습니다. Linux의 rename 문서도 이름 변경이 기존 열린 파일 디스크립터에 영향을 주지 않는다고 설명합니다. (Linux man-pages — rename(2))
따라서 새 파일이 비어 있다는 사실만으로 로그 유실을 확정할 수 없습니다. 이전 파일이 계속 커지는지 함께 살펴야 합니다. 반대로 두 파일 모두 변하지 않는다면 로그를 발생시킬 요청이 없었거나, 버퍼링·기록 오류 등 다른 조건일 수 있습니다. 이때는 어플리케이션을 확인해봐야 합니다.
경로와 열린 파일의 장치·inode를 대조
먼저 logrotate 실행 기록에서 대상 경로가 실제로 순환됐는지 확인합니다. 설정 검토에는 아래 debug 모드를 쓸 수 있습니다. 로그와 상태 파일을 변경하지 않지만, 실제 순환이나 재열기 성공을 시험하는 기능은 아닙니다. (logrotate 프로젝트 — 매뉴얼 원문)
sudo logrotate -d /etc/logrotate.conf이어서 서비스의 실제 기록 프로세스 PID를 확인하고 열린 파일 목록을 봅니다. 아래 PID와 FD는 예시이므로 확인한 값으로 바꿉니다. /proc/PID/fd는 열린 파일을 가리키는 링크를 제공하며, 조회에는 해당 프로세스를 볼 권한이 필요합니다. (Linux man-pages — proc_pid_fd(5))
sudo ls -l /proc/1234/fd
sudo stat -Lc 'device=%d inode=%i size=%s' /var/log/myapp/app.log
sudo stat -Lc 'device=%d inode=%i size=%s' /proc/1234/fd/5목록에서 로그를 가리키는 FD를 찾은 뒤 새 경로와 장치 번호·inode 번호를 비교합니다. inode는 파일시스템 안에서 파일을 구별하는 번호이므로 장치 번호도 함께 봅니다. 여러 워커가 쓰는 서비스라면 각 기록 프로세스를 확인합니다. 조회 도중 재열기가 일어날 수 있어 한 번의 결과만으로 단정하지 않습니다.
| 확인 결과 | 판단과 다음 확인 |
|---|---|
| FD가 이전 파일과 같고 이전 파일만 증가 | 재열기 누락·실패를 우선 확인 |
| FD가 새 파일과 같지만 기록이 없음 | 로그 발생 조건·버퍼링·애플리케이션 오류 확인 |
| 새 파일을 열 때 권한 오류 발생 | 소유자·모드·상위 디렉터리 접근 및 보안 정책 확인 |
재열기 방식과 새 파일 권한을 함께 맞춥니다
재열기를 지원하는 애플리케이션이라면 해당 제품의 명령이나 신호를 확인해 postrotate에 연결합니다. 이 구간은 순환 뒤 압축 전에 실행되며, create로 새 파일을 만들 때는 소유자·그룹·모드도 지정할 수 있습니다. 파일을 만들 수 있는 권한과 서비스가 다시 열어 쓸 수 있는 권한을 구분해야 합니다. (logrotate 프로젝트 — 매뉴얼 원문)
신호는 제품마다 다릅니다. NGINX 공식 문서는 로그 이름을 바꾼 다음 마스터 프로세스에 USR1을 보내 재열도록 설명합니다. 이를 다른 애플리케이션에 그대로 적용하거나, reload라는 이름만 보고 로그 재열기를 보장한다고 생각해서는 안 됩니다. 설치 패키지의 기존 순환 설정과 제품 문서를 먼저 대조합니다. (NGINX — Rotating Log-files)
재열기가 어렵다면 copytruncate를 검토할 수 있습니다. 기존 파일을 복사한 뒤 원본 크기를 줄이는 방식이지만, 복사와 축소 사이에 기록된 데이터가 유실될 수 있습니다. 로그 누락 허용 여부를 따져 선택해야 합니다. delaycompress는 압축을 다음 순환으로 미룰 뿐, 기록 대상을 새 파일로 바꾸는 기능은 아닙니다. (logrotate 프로젝트 — 매뉴얼 원문)
완료 기준은 다음 로그 보관파일에 로그가 연속적으로 쌓일때
수정 후에는 통제된 시험 환경이나 합의된 작업 시간에 순환을 검증합니다. 정상적으로 로그를 남기는 요청을 발생시키고, 버퍼 반영 시간을 고려해 새 파일에 해당 기록이 생기는지 확인합니다. 이전 파일의 증가가 멈췄는지, 기록 프로세스들의 FD가 새 파일을 가리키는지도 함께 봅니다.
재열기 명령의 종료 상태, 서비스 오류, 새 파일 권한을 확인한 결과를 남깁니다. 강제 순환을 반복하면 진단 전에 파일 상태가 바뀔 수 있으므로 실제 실행 조건을 먼저 정합니다. 최종 기록에는 순환 시각·PID·FD·장치와 inode·확인한 요청을 묶어 두면 다음 정기 순환과 비교하기 쉽습니다.
결론
새 로그 파일이 비어 있을 때는 먼저 프로세스가 어느 파일에 쓰는지 확인합니다. 이전 파일을 계속 잡고 있다면 제품이 지원하는 재열기 절차와 새 파일 권한을 맞추고, 새 파일을 잡고 있다면 기록 조건과 오류를 조사합니다. 조치 완료는 설정 저장이나 파일 생성이 아니라, 다음 순환 뒤에도 새 로그가 이어지는지로 판단합니다.