systemd timer

01무엇이고, 어떤 일을 하나

• OnCalendar 등 시간 조건으로 작업을 활성화한다.
• service의 실행 계정·자원·로그 관리와 예약을 결합한다.
• Persistent·지연 분산 같은 정책으로 정지 중 누락과 동시 실행 집중을 조정한다.

02어떤 순서로 동작하나

1. timer 활성화

   시간 조건과 연결할 unit을 읽고 다음 활성화 시점을 계산한다.

2. 시간 조건 도달

   달력 또는 단조 시계 조건이 충족되면 연결된 service의 시작 작업을 요청한다.

3. service 실행

   서비스의 Type·실행 계정·명령 조건에 따라 작업을 실행한다. 이미 활성인 동일 service는 다시 시작되지 않는 상황을 구분한다.

4. 결과·다음 일정

   service의 종료 결과와 timer의 다음 예정 시각을 각각 기록하고 Persistent 등의 적용 범위를 확인한다.

03먼저 알아둘 용어와 구성요소

timer와 service

service에는 실행 계정·명령·환경·제한을 두고 timer에는 언제 해당 unit을 활성화할지를 둔다.

Unit 연결

같은 기본 이름의 timer는 기본적으로 해당 service를 시작한다.

Type=oneshot

Type=oneshot은 시작 작업의 완료를 기다리는 형태이며, 반복 실행할 작업에 RemainAfterExit=yes를 무심코 넣으면 완료 후에도 active로 남아 다음 timer가 새 작업을 시작하지 않을 수 있다.

OnCalendar

OnCalendar는 달력 시각을, OnBootSec나 OnUnitInactiveSec는 기준 이벤트 이후의 상대 시간을 표현한다.

Persistent

OnCalendar timer의 Persistent=true는 비활성 기간에 실행 시점을 놓쳤을 때 다시 활성화하면서 보완 실행할 수 있게 한다. 놓친 모든 횟수를 개별적으로 전부 재생하는 의미는 아니다.

RandomizedDelaySec

RandomizedDelaySec는 여러 장비의 같은 작업이 한꺼번에 시작되는 것을 줄이는 지연이며, 실제 시작 시각에는 timer 정확도 설정과 시스템 부하도 영향을 준다.

04예제로 따라가기

• report.timer와 report.service를 연결하면 timer 활성 상태와 보고서 생성 작업의 성공 상태가 서로 다를 수 있다.
• OnCalendar 기반 Persistent 설정은 정지 중 놓친 조건을 보완하는 데 관여하지만 모든 누락 횟수만큼 업무를 반복 재생하는 것으로 해석하지 않는다.
• 여러 서버의 작업 시각을 RandomizedDelaySec로 흩어 놓으면 동시에 백업 서버에 부하가 몰리는 상황을 줄일 수 있다.

05혼동하기 쉬운 점과 확인 기준

• timer가 만료될 때 대상 service가 이미 active이면 별도 인스턴스를 자동 생성하여 겹쳐 실행하지 않는다.
• 달력 표현을 해석한 다음 timer의 상태와 연결된 service의 실제 종료 상태를 대조한다.
• 시작 기록만 보지 않고 성공·실패·duration·예상 heartbeat 누락을 연결해야 주기 작업의 상태를 설명할 수 있다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.