cron 시간이 KST와 어긋났을 때 NTP부터 확인한 서버 설정 노트

작업 로그의 시간이 먼저 이상했다

백업 스크립트는 정상 종료됐는데 알림이 예상보다 늦게 왔다. cron 표현식은 0 3 * * *였고, 처음에는 서버 timezone이 UTC일 거라고 단정했다. timedatectl을 보니 KST로 표시됐지만 NTP 동기화가 꺼져 있었고, 시스템 시계도 조금씩 밀리고 있었다.

표시 timezone과 실제 시계 정확도는 별개의 문제다. timezone만 바꾸면 실행 시각의 해석은 바뀌지만, 서버 시간이 틀어진 문제는 남는다.

현재 시간과 동기화 상태를 함께 본다

date
timedatectl status
systemctl status systemd-timesyncd

시간대와 동기화는 다음처럼 각각 설정한다.

timedatectl set-timezone Asia/Seoul
timedatectl set-ntp true
timedatectl status

System clock synchronized: yes와 올바른 Time zone을 모두 확인했다. 환경에 따라 chrony를 쓰는 서버도 있으므로, 이미 운용 중인 시간 동기화 데몬을 모르고 하나 더 설치하지 않았다.

cron은 어떤 timezone으로 해석되는가

cronie는 보통 시스템 timezone을 따르지만, 컨테이너 안의 cron은 호스트와 다를 수 있다. 그래서 작업 파일 상단에 의도를 남겼다.

CRON_TZ=Asia/Seoul
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

CRON_TZ 지원 여부는 사용하는 cron 구현에 따라 확인해야 한다. 지원하지 않는 환경에서는 서버 timezone을 일관되게 맞추고, 로그에는 ISO 8601 시간과 offset을 남기는 쪽이 안전했다.

다음 배포 전에 할 점검

• date -Iseconds 결과에 +09:00이 붙는지 확인한다.
• 작업 시작과 종료 시각을 로그에 남긴다.
• 수동 실행 한 번과 다음 예약 실행 한 번을 모두 확인한다.
• 컨테이너라면 이미지 내부 timezone 데이터도 확인한다.

시간 문제는 대개 스케줄 문법보다 관측 정보 부족에서 오래 걸렸다. 이제는 cron 행을 고치기 전에 서버 시간, 동기화, 로그 offset 세 가지를 같은 화면에서 확인한다.