Systemd 타이머 유닛 생성 및 관리 방법

Systemd 타이머 유닛 마스터링: 종합 가이드

리눅스의 보편적인 시스템 및 서비스 관리자인 Systemd는 전통적인 cron 작업에 대한 강력하고 유연한 대안을 제공하여 작업을 예약합니다. systemd 생태계에 직접 내장된 기능인 systemd 타이머 유닛은 향상된 제어, 시스템 서비스와의 더 나은 통합, 보다 세분화된 로깅 기능을 제공합니다. 이 가이드는 systemd 타이머 유닛을 생성, 관리 및 모니터링하는 과정을 안내하여 자신감 있고 효율적으로 작업을 자동화할 수 있도록 지원합니다.

수십 년 동안 작업 스케줄링의 주축이었던 cron과 달리 systemd 타이머는 몇 가지 장점을 제공합니다. 타이머는 서비스 유닛에 직접 연결될 수 있으며, 이는 타이머가 시스템이 준비되었을 때만 서비스를 활성화하거나 타이머 만료 전에 서비스가 완료되면 서비스를 중지할 수 있음을 의미합니다. 이러한 긴밀한 통합은 복잡한 종속성 관리를 단순화합니다. 또한 systemd의 로깅 인프라(journald)는 모든 타이머 활동에 대한 중앙 집중식 및 검색 가능한 로그를 제공하여, 흩어져 있는 cron 로그를 뒤지는 것보다 디버깅을 훨씬 쉽게 만듭니다.

Systemd 타이머 유닛 구조 이해하기

A systemd 타이머 유닛은 활성화하려는 해당 서비스 유닛(또는 다른 유닛 유형)과 항상 쌍을 이룹니다. 타이머 유닛 자체는 연결된 유닛을 언제 활성화할지 정의하고, 서비스 유닛은 무슨 작업을 수행할지 정의합니다. 두 유닛 모두 일반적으로 동일한 디렉터리(사용자 정의 유닛의 경우 종종 /etc/systemd/system/)에 위치합니다.

A 일반적인 타이머 유닛 파일은 .timer 확장자를 가지며, 연결된 서비스 유닛 파일은 .service 확장자를 가집니다. 예를 들어, mytask.service에 정의된 작업을 예약하려면 mytask.timer 파일을 생성해야 합니다.

예시: `mytask.timer` 구조

[Unit]
Description=매일 내 사용자 정의 작업 실행

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

주요 섹션을 분석해 보겠습니다:

[Unit] 섹션:
- Description: 타이머에 대한 사람이 읽을 수 있는 설명입니다. 상태 출력에서 식별하는 데 유용합니다.
[Timer] 섹션: 이는 타이머 유닛의 핵심이며 스케줄링을 정의합니다.
- OnCalendar=daily: 이 지시문은 타이머가 활성화될 시점을 지정합니다. daily는 *-*-* 00:00:00의 약어입니다. Systemd는 cron과 유사하지만 더 많은 유연성을 갖춘 광범위한 달력 이벤트 사양을 지원합니다. 다른 예시는 다음과 같습니다.
  - hourly: 매시간.
  - weekly: 매주 (Mon *-*-* 00:00:00과 동일).
  - Sun *-*-* 10:00: 매주 일요일 오전 10시.
  - *-*-15 14:30: 매월 15일 오후 2시 30분.
  - Mon..Fri *-*-* 09:00: 평일 오전 9시.
- Persistent=true: 이 값을 true로 설정하면, 시스템이 꺼져 있는 동안 이벤트가 발생했다면 타이머가 가능한 한 빨리 활성화됩니다. OnCalendar 타이머의 경우, 예약된 시간 동안 시스템이 꺼져 있었다면 시스템이 부팅되고 타이머가 활성화되는 즉시 타이머가 트리거된다는 의미입니다.
- OnBootSec=: 시스템 부팅 후 지정된 시간 후에 타이머를 활성화합니다. 예를 들어, OnBootSec=15min은 부팅 후 15분 후에 트리거됩니다.
- OnUnitActiveSec=: 타이머가 활성화하는 유닛(예: 서비스)이 마지막으로 활성화된 후 지정된 시간 후에 타이머를 활성화합니다. 예를 들어, OnUnitActiveSec=1h는 연결된 서비스가 마지막으로 완료된 후 한 시간 후에 트리거됩니다.
- OnUnitInactiveSec=: 타이머가 활성화하는 유닛이 마지막으로 비활성화된 후 지정된 시간 후에 타이머를 활성화합니다.
- AccuracySec=: 타이머의 정확도를 지정합니다. Systemd는 이벤트가 이 시간 범위 내에 있을 때만 타이머를 위해 시스템을 깨우려고 시도하여 전력 절약에 도움이 됩니다. 기본값은 1min입니다.
- RandomizedDelaySec=: 타이머 트리거에 지정된 기간까지의 임의의 지연 시간을 추가합니다. 부하 분산에 유용합니다.
[Install] 섹션: 이 섹션은 타이머 유닛이 어떻게 활성화될 수 있는지를 정의합니다.
- WantedBy=timers.target: 이 지시문은 타이머를 활성화할 때, 활성 타이머를 모두 포함하는 표준 대상인 timers.target의 일부가 되도록 보장합니다. 이는 활성화되면 타이머가 부팅 시 자동으로 시작됨을 의미합니다.

예시: `mytask.service` 구조

[Unit]
Description=내 사용자 정의 작업 서비스

[Service]
Type=oneshot
ExecStart=/usr/local/bin/my_custom_script.sh
User=myuser
Group=mygroup

[Install]
WantedBy=multi-user.target

[Unit] 섹션:
- Description: 서비스에 대한 설명입니다.
[Service] 섹션: 이는 서비스 자체를 정의합니다.
- Type=oneshot: 한 번 실행되고 종료되는 작업에 적합합니다. 장기 실행 데몬을 위한 다른 유형도 있습니다.
- ExecStart: 실행할 명령입니다. 스크립트에 실행 권한이 있는지 확인하세요.
- User/Group: 명령이 실행될 사용자 및 그룹을 지정합니다. 루트 권한으로 작업을 실행하는 것은 절대적으로 필요하지 않은 한 권장되지 않는 모범 사례입니다.
[Install] 섹션: 이 섹션은 일반적으로 부팅 시 시작되어야 하는 서비스에 포함되지만, 타이머에 의해서만 트리거되도록 의도된 서비스의 경우 엄격하게 필요하지 않을 수 있습니다.

타이머 유닛 생성 및 활성화

시스템d 타이머 유닛을 생성하고 관리하려면 다음 단계를 따르십시오.

서비스 유닛 파일 생성: .service 파일에 작업을 정의합니다. /etc/systemd/system/ (또는 사용자별 타이머의 경우 ~/.config/systemd/user/)에 배치합니다.
bash sudo nano /etc/systemd/system/mytask.service
위의 서비스 예시 내용을 붙여넣고 저장합니다.
타이머 유닛 파일 생성: 해당 .timer 파일에 일정을 정의합니다. 서비스 파일과 동일한 디렉터리에 배치합니다.
bash sudo nano /etc/systemd/system/mytask.timer
위의 타이머 예시 내용을 붙여넣고 저장합니다.
Systemd 데몬 재로드: 유닛 파일을 생성하거나 수정한 후에는 systemd에 설정을 다시 로드하도록 알려야 합니다.
bash sudo systemctl daemon-reload
타이머 활성화: 타이머가 부팅 시 자동으로 시작되도록 하려면 활성화합니다.
bash sudo systemctl enable mytask.timer
참고: 타이머에 의해서만 트리거되도록 의도된 서비스 파일은 활성화하지 않습니다.* *
타이머 시작: 타이머를 즉시 시작합니다. 그러면 스케줄에 따라 실행됩니다.
bash sudo systemctl start mytask.timer

타이머 유닛 관리 및 모니터링

Systemd는 타이머를 관리하고 모니터링하기 위해 여러 systemctl 명령을 제공합니다.

모든 타이머 나열: 활성 및 비활성 타이머를 모두 확인합니다.
bash systemctl list-timers
이 명령은 다음과 유사한 출력을 제공합니다.
NEXT LEFT LAST PASSED UNIT ACTIVATES Tue 2023-10-27 08:00:00 UTC 10h left Wed 2023-10-26 08:00:00 UTC 14h ago mytask.timer mytask.service
이는 타이머가 다음 실행 예정 시간, 실행까지 남은 시간, 마지막 실행 시간, 활성화하는 서비스를 보여줍니다.
특정 유닛에 대한 타이머 나열: 특정 서비스와 관련된 타이머를 보려면 다음을 사용합니다.
bash systemctl list-timers --all | grep mytask.service
타이머 상태 확인: 특정 타이머에 대한 자세한 정보를 얻습니다.
bash systemctl status mytask.timer
이를 통해 타이머가 활성 상태인지, 다음 실행 예정 시간, 최근 로그 항목을 확인할 수 있습니다.
서비스 로그 보기: 타이머에 의해 실행된 작업의 출력 및 상태를 보려면 연결된 서비스의 로그를 확인합니다.
bash journalctl -u mytask.service
로그를 실시간으로 팔로우할 수도 있습니다.
bash journalctl -f -u mytask.service
타이머 중지: 타이머를 일시적으로 비활성화해야 하는 경우.
bash sudo systemctl stop mytask.timer
타이머 비활성화: 타이머가 부팅 시 시작되는 것을 방지하고 실행 중인 경우 중지합니다.
bash sudo systemctl disable mytask.timer

고급 타이머 구성

특정 간격 설정

daily 또는 hourly 대신 보다 정확한 간격을 정의할 수 있습니다.

N분마다: OnUnitActiveSec=15min (서비스가 마지막으로 종료된 후 15분마다 실행됨).
특정 시간: OnCalendar=*-*-* 02:30:00 (매일 오전 2시 30분에 실행됨).
조건 결합: OnCalendar=Mon..Fri *-*-* 08:00:00 (평일 오전 8시에 실행됨).

전력 절약을 위한 `AccuracySec` 사용

작업이 정확한 순간에 실행될 필요가 없다면 AccuracySec 사용을 고려해 보십시오. 예를 들어, AccuracySec=5min은 systemd에게 예약된 시간으로부터 5분 이내에 시스템을 깨워도 괜찮다고 알려줍니다. 이를 통해 systemd는 타이머 이벤트를 묶고 시스템을 더 오랫동안 저전력 상태로 유지할 수 있습니다.

[Timer]
OnCalendar=hourly
AccuracySec=5min

`Persistent` 대 `WakeUpOn`

Persistent=true는 시스템이 꺼져 있어서 OnCalendar 이벤트가 누락된 경우, 다음 부팅 시 한 번 실행되도록 보장합니다. 이는 건너뛰어서는 안 되는 작업에 매우 중요합니다.
WakeUpOn= (예: WakeUpOn=battery, WakeUpOn=ac)은 타이머를 위해 시스템이 깨어나야 하는 조건을 지정하는 데 사용할 수 있습니다. 이는 더 고급이며 종종 systemd-suspend.service와 함께 사용됩니다.

타이머 대 Cron

기능	Systemd 타이머	Cron
통합	systemd 서비스, 대상과의 깊은 통합	독립형 유틸리티
스케줄링	유연함 (달력, 상대적, 부팅 기반)	주로 시간 기반 표현식
로깅	`journalctl`을 통한 중앙 집중식	분산됨 (`/var/log/syslog`, `/var/log/cron.log`)
오류 처리	서비스 실패에 작업 연결 가능	기본 메일 알림
종속성	다른 서비스가 활성 상태인지에 따라 달라질 수 있음	제한적
실행	특정 사용자, 그룹으로 실행 가능	crontab을 통해 특정 사용자로 실행 가능
전원 관리	전력 절약을 위해 최적화 가능 (`AccuracySec`)	덜 직접적인 제어

Systemd 타이머를 선택해야 하는 경우:

다른 systemd 서비스와 더 긴밀한 통합이 필요할 때.
중앙 집중식 로깅 및 쉬운 디버깅이 우선 순위일 때.
더 고급 스케줄링 옵션(예: 마지막 실행 이후 시간)이 필요할 때.
시스템 상태 또는 전원 관리와 관련된 작업의 경우.

Cron이 여전히 선호될 수 있는 경우:

systemd를 완전히 채택하지 않은 시스템에서 매우 간단하고 독립적인 작업의 경우.
다양한 리눅스 배포판 및 이전 시스템 전반에 걸친 최대 호환성의 경우.

일반적인 문제 해결

작업이 실행되지 않음:
- 타이머 상태 확인: systemctl status mytask.timer. Active: active 및 Triggered... 메시지를 찾습니다.
- 서비스 로그 확인: journalctl -u mytask.service. 스크립트가 실행 가능한지, 오류가 없는지 확인합니다.
- OnCalendar 구문 확인: 테스트하려면 systemd-analyze calendar 'your-calendar-string'을 사용합니다.
- 타이머가 활성화되고 시작되었는지 확인: systemctl list-timers --all.
작업이 너무 빠르거나 늦게 실행됨:
- AccuracySec 및 RandomizedDelaySec 확인.
- 시스템 시계가 정확한지 확인(timedatectl status).
권한 오류:
- .service 파일에 지정된 User 및 Group이 스크립트 및 액세스하는 모든 파일에 필요한 권한이 있는지 확인합니다.
- 사용자가 지정되지 않은 경우 기본값은 루트입니다. 루트 권한 사용 시 주의하십시오.

결론

Systemd 타이머 유닛은 리눅스 시스템에서 작업을 스케줄링하는 강력하고 현대적인 접근 방식을 제공합니다. 구조, 생성 및 관리를 이해함으로써 일상적인 작업을 효과적으로 자동화하고 시스템 안정성을 개선하며 systemd 생태계의 모든 잠재력을 활용할 수 있습니다. 변경 후에는 항상 데몬을 다시 로드하고, 영속성을 위해 타이머를 활성화하고, 효율적인 모니터링 및 문제 해결을 위해 journalctl을 활용하십시오.