예약 실행과 시간: cron·systemd timer·NTP·chrony

01예약 시각·실행 시작·성공은 다른 상태다

• 예약예약 시스템은 정해진 조건이 충족되면 명령이나 서비스를 시작한다. 예약이 등록되었다는 사실, 데몬이 동작한다는 사실, 작업이 시작했다는 기록, 작업이 성공한 결과는 각각 별개다.
• cron·로그cron 로그에 명령이 찍혀 있어도 내부 명령이 권한 오류로 실패했거나 출력 파일을 만들지 못했을 수 있다.
• 로그주기 작업을 하나의 프로그램처럼 설계하면 입력, 작업 계정, 환경, 종료 상태, 결과물과 소요 시간을 구분할 수 있다.
• 주기 작업의 운영 상태정상 종료뿐 아니라 실행 누락, 중복, 지나친 지연도 운영 상태다.

  • 예를 들어 백업 프로세스가 종료 상태 0을 반환해도 복원 가능한 백업인지 확인하는 시험은 별도의 결과로 남긴다.

02벽시계·시간대·경과 시간을 구분하기

• 벽시계의 용도벽시계는 날짜와 시각을 나타내며 인증서 유효 기간, 로그 시각, 매일 특정 시각의 일정에 사용한다.
• 시간대의 표현 규칙시간대는 같은 순간을 지역 시각으로 표현하는 규칙이다.

  • 장비 모두가 같은 시간대를 표시해야만 동기화된 것은 아니다.
• 다른 지역 시각 비교같은 실제 시각을 유지하고 UTC 또는 시간대 정보를 함께 기록하면 서로 다른 표시를 비교할 수 있다.
• 경과 시간경과 시간은 시작부터 얼마가 지났는지 측정하는 값이다.
• 단조 시계와 경과 시간벽시계를 조정하면 단순히 두 벽시각을 뺀 시간은 잘못될 수 있으므로 프로그램의 기간 측정은 적절한 단조 시계를 사용한다.
• 예약예약 작업의 달력 조건과 부팅 후 몇 분 같은 상대 조건을 나누는 이유도 이 차이 때문이다.
• 로그로그를 합칠 때는 발생 시각, 수신 시각, 표시 시각을 섞지 않는다.

03NTP의 네 시각으로 지연과 오차 계산하기

• NTP·t1NTP는 클라이언트 송신 t1, 서버 수신 t2, 서버 송신 t3, 클라이언트 수신 t4를 사용해 서버가 클라이언트보다 얼마나 앞서 있는지와 왕복 지연을 추정한다.
• 오차·지연 공식오차 θ=((t2−t1)+(t3−t4))/2, 지연 δ=(t4−t1)−(t3−t2)다.
• 서버 처리 시간 제외서버 안의 처리 시간을 왕복 시간에서 빼고 양방향 지연이 비슷하다는 가정으로 오차를 추정한다.
• 밀리초 계산 예제같은 기준의 밀리초 값으로 t1=1000, t2=1015, t3=1017, t4=1012라면 θ=10ms, δ=10ms다.
• 측정값의 의미클라이언트에서 12ms가 흘렀고 서버 처리에 2ms가 쓰였으며 서버 시계가 10ms 앞선 예다.

  • 경로의 비대칭 지연은 오차 추정에 영향을 준다.
  • 따라서 단일 응답만으로 완벽한 시각을 얻는 것이 아니라 여러 측정과 소스 선택을 이용한다.

1. 클라이언트 요청 송신클라이언트가 요청을 보내며 자신의 시계로 t1을 기록한다. 예시에서는 같은 단위인 밀리초 값 t1=1000을 사용한다.
2. 서버의 수신·응답서버가 자신의 시계로 수신 t2=1015와 응답 송신 t3=1017을 기록한다. 서버에서 응답을 준비하는 데 2ms가 걸린 예다.
3. 클라이언트 응답 수신클라이언트가 자신의 시계로 수신 t4=1012를 기록한다. 클라이언트 기준 왕복 경과 시간은 t4−t1=12ms다.
4. 지연·시계 오차 추정서버 처리 시간을 제외한 δ는 10ms이고 θ는 10ms다. 왕복 경로 지연이 비슷하다는 가정에서 서버 시계가 클라이언트보다 10ms 앞선 것으로 추정한다.
5. 여러 측정으로 동기화 판단단일 응답에는 네트워크 지연과 비대칭의 영향이 남는다. 여러 측정과 소스 선택을 통해 시계를 조정할 근거를 얻는다.

07chronyd와 chronyc의 역할

• chronydchronyd는 시간 소스의 측정값을 이용하여 시계를 관리하는 데몬이고, chronyc는 상태를 조회하거나 관리하는 클라이언트다.
• NTPNTP 서버 통신에는 일반적으로 UDP 123을 사용하며 chronyc의 관리 통로와 구분한다.
• slew시계를 조금씩 빠르게 또는 느리게 보정하는 slew는 시간을 갑자기 뛰게 하는 step과 다르다.
• step·로그큰 step은 로그 순서나 시간에 민감한 프로그램에 영향을 줄 수 있다.
• trackingtracking에서는 기준 소스와 최근 기준 시각, 시스템 시각 차이, 동기화 상태를 읽고 sources -v에서는 선택된 소스와 도달성을 읽는다.
• 소스 상태 기호^는 서버, *는 현재 선택된 소스, ?는 아직 선택할 수 없는 상태를 나타낼 수 있다.
• StratumStratum은 기준 시계와의 계층 관계이지 정확도를 보장하는 점수는 아니다.
• 데몬데몬이 실행 중인 것과 외부 소스에 실제 동기화된 것은 구분한다.

chronyc tracking
chronyc sources -v
timedatectl status

시간 상태를 바꾸지 않는 조회 예시. 실제 시간 서비스에 따라 출력과 동기화 상태를 함께 해석한다.

08cron 표현과 사용자별·시스템별 형식

• cron일반적인 cron의 시간 필드는 분, 시, 일, 월, 요일 순서다.
• 매일 02:15 예제15 2 * * *는 해당 일정의 시간대 기준 매일 02:15를 뜻한다.
• crontab사용자 crontab은 그 뒤에 명령이 오고, /etc/crontab이나 /etc/cron.d 파일 형식에는 실행 사용자 필드가 추가된다. 사용자 crontab에 사용자 이름을 한 칸 더 넣으면 그 이름을 명령의 일부로 해석하는 문제가 생긴다.
• 쉼표쉼표는 값 목록, 하이픈은 범위, 슬래시 간격은 해당 필드의 범위 안에서 적용한다.
• 분 필드의 간격*/15 분은 00·15·30·45분이며 직전 실행 종료 후 15분이라는 뜻은 아니다.
• CronieCronie 계열에서는 일과 요일을 모두 제한하면 둘 중 하나가 맞는 날에 실행되는 규칙이 있어 “AND 조건”으로 오해하기 쉽다.
• 구현·일광절약시간구현별 문법과 시간대·일광절약시간 처리는 사용하는 cron 문서로 확인한다.

# 사용자 crontab의 작업 줄
15 2 * * * /usr/local/libexec/study-check

# /etc/cron.d/study-check의 작업 줄
15 2 * * * study /usr/local/libexec/study-check

두 줄은 서로 다른 파일 형식의 비교다. 같은 작업을 중복 등록하는 예시가 아니다.

09수동 실행과 예약 실행의 환경 차이

• cron터미널에서 되던 스크립트가 cron에서 실패하면 작업 디렉터리, PATH, 셸, 사용자 권한과 필요한 환경이 같은지 비교한다.

  • cron은 사용자의 현재 터미널 세션을 복제하지 않는다.
• 경로·작업 계정 권한실행 파일 경로와 입력·출력 경로를 명확히 하고, 프로그램이 요구하는 작업 디렉터리도 정한다. 로그 파일과 잠금 파일에 대한 쓰기 권한 역시 해당 작업 계정에 있어야 한다.
• SHELL·PATHSHELL과 PATH를 명시할 수 있지만 비밀번호나 토큰을 crontab에 직접 쓰지 않는다.
• 기본 출력 메일기본 출력 메일은 메일 전송 환경에 의존하므로 성공 기록을 대신하지 못한다.
• 로그 보관·회전주기 로그를 파일로 남기면 보관·회전과 디스크 용량도 함께 설계한다.
• 예약설정 변경 후에는 수동으로 같은 계정·환경을 재현한 시험과 실제 예약 실행 결과를 구분해서 기록한다.

10종료 상태를 보존하는 작업 wrapper

• wrapperwrapper는 시작, 성공 또는 실패, 종료 상태를 일정한 형식으로 남기는 바깥 프로그램이다.
• wrapper 예제의 범위아래 예시는 읽기 전용 조회 명령을 감싸는 구조다.
• 실패 상태 보존실패 분기에서 $?를 즉시 저장해야 이후 logger 등의 성공 상태로 원래 오류를 덮어쓰지 않는다.
• 내부 작업의 실패실제 작업에서는 처리 대상 수와 결과 파일, 소요 시간 같은 업무 지표도 함께 기록할 수 있다.
• Wrapper 성공 판정의 한계프로그램이 일부만 처리하고도 성공을 반환한다면 wrapper만으로 완전한 성공을 판단할 수 없다.

  • 내부 명령의 실패 전달과 완료 기준을 먼저 정의한다.
• 반복 실행의 전제반복 실행되는 작업은 이미 처리한 항목의 중복 효과를 줄이고, 중간 실패 후 어느 지점부터 다시 시작할지 정해야 한다.
• 성공 기록과 결과물로그의 성공 문자열과 결과물의 실제 상태를 연결하는 것이 목적이다.

#!/bin/bash
JOB_NAME=study-check
logger -t "$JOB_NAME" -- "start"
if /usr/bin/stat /etc/os-release; then
    logger -t "$JOB_NAME" -- "success"
else
    rc=$?
    logger -p user.err -t "$JOB_NAME" -- "failed rc=$rc"
    exit "$rc"
fi

stat 조회를 감싼 Bash 예시. 실제 작업의 성공 판정은 해당 명령과 결과물의 의미에 맞게 정한다.

11중복 실행과 누락 실행을 별도로 설계하기

• 실행 주기의 겹침10분마다 시작하는 작업이 15분 걸리면 다음 실행과 겹칠 수 있다.
• flockflock 같은 잠금은 같은 잠금 파일을 사용하는 작업들이 동시에 실행되는 것을 제한한다.

  • -n처럼 기다리지 않는 방식이면 이미 실행 중일 때 새 실행이 건너뛰어질 수 있으므로 그 상태를 성공과 구분해 기록한다.
• 잠금잠금은 하나의 서버·공유 잠금 조건에서 의미가 있으며 여러 서버의 분산 작업을 자동으로 조정하지 않는다.
• cron일반 cron은 시스템이 꺼져 있던 동안의 모든 일정을 저장해 재생하는 작업 큐가 아니다.
• anacron·timer누락 보완이 필요하면 anacron이나 timer의 보완 기능과 업무 자체의 처리 기준을 검토한다.
• 중복 방지와 누락 보완중복 방지와 누락 보완은 서로 다른 문제이며 둘 다 결과 데이터의 일관성을 자동으로 보장하지 않는다.

12systemd service는 작업, timer는 시작 조건

• 작업과 시작 조건service에는 실행 계정·명령·환경·제한을 두고 timer에는 언제 해당 unit을 활성화할지를 둔다.
• 기본 이름의 Unit 연결같은 기본 이름의 timer는 기본적으로 해당 service를 시작한다.
• Type=oneshotType=oneshot은 시작 작업의 완료를 기다리는 형태이며, 반복 실행할 작업에 RemainAfterExit=yes를 무심코 넣으면 완료 후에도 active로 남아 다음 timer가 새 작업을 시작하지 않을 수 있다.
• OnCalendarOnCalendar는 달력 시각을, OnBootSec나 OnUnitInactiveSec는 기준 이벤트 이후의 상대 시간을 표현한다.
• 이미 Active인 작업timer가 만료될 때 대상 service가 이미 active이면 별도 인스턴스를 자동 생성하여 겹쳐 실행하지 않는다.
• 작업 결과·예정 시각작업의 결과와 오류는 service를 조회하고, 다음·이전 예정 시각은 timer를 조회하는 식으로 역할을 나눠 읽는다.

1. timer 활성화timer가 달력 시각이나 기준 이벤트를 바탕으로 다음 활성화 시점을 계산한다. 예시의 OnCalendar는 매일 02:15 조건이며 실제 시각에는 지연 설정도 관여한다.
2. 작업 시작 요청조건이 도달하면 연결된 service의 시작을 요청한다. service가 이미 active라면 같은 unit의 별도 인스턴스를 겹쳐 시작하지 않는다.
3. oneshot 명령 실행비활성 service가 시작되면 지정한 User·환경·제한으로 ExecStart 명령을 실행한다. Type=oneshot은 명령의 완료를 기다린다.
4. 완료 상태 기록명령의 종료 결과가 service 상태에 반영된다. RemainAfterExit를 사용하지 않는 성공한 oneshot은 완료 후 inactive로 돌아가 다음 실행 대상이 될 수 있다.
5. 다음 예정 시각과 결과 분리timer의 다음 시점 계산과 service의 실제 성공·실패는 별개로 기록된다. Persistent의 놓친 시각 보완도 매 누락 횟수를 모두 재생하는 방식은 아니다.

# study-check.service
[Unit]
Description=Study read-only scheduled check
[Service]
Type=oneshot
User=study
ExecStart=/usr/local/libexec/study-check
NoNewPrivileges=true
PrivateTmp=true

# study-check.timer
[Unit]
Description=Schedule study check
[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true
RandomizedDelaySec=60
[Install]
WantedBy=timers.target

서로 다른 두 unit 파일의 내용이다. study 계정과 wrapper가 준비되고 접근권한이 맞는 시스템 timer 예시.

13Persistent·지연·로그로 실행 생애를 추적하기

• OnCalendar·timerOnCalendar timer의 Persistent=true는 비활성 기간에 실행 시점을 놓쳤을 때 다시 활성화하면서 보완 실행할 수 있게 한다.

  • 놓친 모든 횟수를 개별적으로 전부 재생하는 의미는 아니다.
• RandomizedDelaySecRandomizedDelaySec는 여러 장비의 같은 작업이 한꺼번에 시작되는 것을 줄이는 지연이며, 실제 시작 시각에는 timer 정확도 설정과 시스템 부하도 영향을 준다.
• timer·service달력 표현을 해석한 다음 timer의 상태와 연결된 service의 실제 종료 상태를 대조한다.
• cron·로그cron 로그는 RHEL의 /var/log/cron, Debian 계열의 /var/log/syslog 또는 journal 등에 나타날 수 있으며 실제 위치는 로깅 구성에 따라 달라진다.
• 실행 결과와 누락시작 기록만 보지 않고 성공·실패·duration·예상 heartbeat 누락을 연결해야 주기 작업의 상태를 설명할 수 있다.

systemd-analyze calendar "*-*-* 02:15:00"
systemctl list-timers --all
systemctl show study-check.service -p Result -p ExecMainStatus
journalctl -u study-check.service -u study-check.timer

예약 표현과 실제 service 결과를 구분하여 조회한다. 로그에는 계정·경로 등이 포함될 수 있어 공개 시 필요한 부분만 사용한다.