여기서는 멈추세요
- 결제·정산·메일처럼 중복 실행이 위험한 작업은 멱등성과 실행 이력을 확인하기 전 수동 시작하지 않습니다.
- 시간대와 놓친 실행 처리 요구가 확정되지 않으면 OnCalendar·Persistent를 변경하지 않습니다.
SCHEDULED JOBS
Cron·systemd timer 작업이 실행되지 않을 때
스케줄러 종류, 다음 실행 시각과 실제 service 결과를 구분하고 시간대·환경변수·권한·놓친 실행 처리 방식을 확인합니다.cron not runningsystemd timer failedOnCalendarPersistent truescheduled job missing
환경Ubuntu 22.04·24.04 LTS · cron · systemd timer
분류서비스
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
새로 enable한 timer는 승인 후 disable하고, 변경한 unit·drop-in을 원본으로 복원한 뒤 daemon-reload로 이전 스케줄을 확인합니다.
담당자에게 전달할 자료
- timer·service의 cat, status와 list-timers 출력
- 예상·실제 시간대와 LAST·NEXT 실행 시각
- 작업 실행 사용자, 종료 코드와 관련 journal 구간
BEFORE YOU START
이런 증상에서 시작합니다
- 예약 시각에 작업 결과가 없음
- timer는 active인데 service가 실패
- 재부팅·절전 중 놓친 작업이 실행되지 않음
- 터미널에서는 되지만 예약 실행만 실패
CHECK THE BRANCH
놓치기 쉬운 원인 분기
timer는 대기 중이고 service만 실패
스케줄 계산보다 연결된 service의 User, WorkingDirectory, Environment와 애플리케이션 오류를 확인합니다.
재부팅 중 실행 시각을 놓침
OnCalendar timer의 Persistent=true는 비활성 동안 놓친 실행을 기동 시 보충하지만, 중복 실행에 안전한 작업인지 먼저 확인해야 합니다.
Cron에서만 실패
Cron의 제한된 PATH, 셸, 실행 사용자와 작업 디렉터리를 고려해 절대 경로와 로그 출력을 확인합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
Cron과 systemd timer 중 실행 주체 확인
두 스케줄러를 동시에 수정하지 않고 실제로 등록된 위치부터 식별합니다.
전체 timer
systemctl list-timers --all --no-pager시스템 Cron 상태
systemctl status cron.service --no-pager -l사용자 crontab
crontab -l시스템 cron 디렉터리
sudo ls -la /etc/cron.d /etc/cron.daily결과 읽기
목록에 없으면 등록·enable 문제이고, 목록에는 있지만 LAST가 비어 있거나 service가 실패하면 실행 문제입니다.
다음 판단
실제 스케줄러와 작업 이름을 하나로 좁힙니다.
조회시스템을 변경하지 않는 확인 단계
timer와 연결 service 상태 확인
TIMER_NAME을 실제 기본 이름으로 바꾸고 timer·service를 함께 확인합니다.
timer와 service 상태
systemctl status TIMER_NAME.timer TIMER_NAME.service --no-pager -l원본과 drop-in
systemctl cat TIMER_NAME.timer TIMER_NAME.service다음 실행 시각
systemctl list-timers TIMER_NAME.timer --all --no-pager결과 읽기
timer의 active(waiting)와 service의 마지막 종료 코드는 별개입니다. Trigger와 Unit 연결도 확인합니다.
다음 판단
service 실패라면 스케줄을 바꾸기 전에 서비스 로그를 읽습니다.
조회시스템을 변경하지 않는 확인 단계
달력 표현식·시간대·놓친 실행 정책 확인
CALENDAR_EXPRESSION을 unit의 OnCalendar 값으로 바꾸고 다음 실행 시각을 계산합니다.
달력 표현식 검증
systemd-analyze calendar 'CALENDAR_EXPRESSION'시스템 시간대
timedatectl statustimer 주요 속성
systemctl show TIMER_NAME.timer -p NextElapseUSecRealtime -p LastTriggerUSec -p Triggers결과 읽기
예상 시간대와 Next elapse가 다르면 OnCalendar·Timezone 설정을 수정해야 합니다. Persistent는 OnCalendar timer에만 놓친 실행 보충 효과가 있습니다.
다음 판단
정확한 다음 실행 시각과 중복 실행 허용 여부를 기록합니다.
주의서버 부하나 권한을 고려할 단계
실행 로그와 사용자 환경 확인
민감한 환경변수 값을 공유하지 말고 실행 사용자·경로·권한 차이를 확인합니다.
timer·service 최근 로그
journalctl -u TIMER_NAME.timer -u TIMER_NAME.service --since '-24 hours' --no-pagerservice 실행 환경
systemctl show TIMER_NAME.service -p User -p Group -p WorkingDirectory -p EnvironmentFilesdaily cron 대상 시험
sudo run-parts --test /etc/cron.daily결과 읽기
명령 경로, 작업 디렉터리, 실행 권한, 파일명 규칙 또는 환경 파일 누락을 확인합니다.
다음 판단
수동 실행이 외부 시스템에 중복 작업을 만들지 확인하고 변경 단계로 이동합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
승인된 스케줄을 활성화하고 한 번 검증
작업이 멱등하고 수동 실행의 부작용이 없을 때만 service를 한 번 실행합니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
unit 설정 다시 읽기
sudo systemctl daemon-reloadtimer 활성화
sudo systemctl enable --now TIMER_NAME.timerservice 단일 실행
sudo systemctl start TIMER_NAME.service결과 확인
systemctl status TIMER_NAME.service --no-pager -l다음 실행 재확인
systemctl list-timers TIMER_NAME.timer --all --no-pager결과 읽기
service가 성공하고 LAST·NEXT가 기대값이며 결과물이 한 번만 생성되어야 합니다.
다음 판단
중복·지연 실행 가능성을 포함해 모니터링 기준을 운영 기록에 남깁니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.