[LINUX] systemd (service+timer)

 

특정 스크립트 파일을 실행시키는 스케쥴러를 만든다고 할 때,

 

systemd (service+timer)

1. service

하위 경로에 'backup' 이라는 이름의 service를 만들어 준다.
 /etc/systemd/system/backup.service 

(기본 구성)

[Unit]
Description=Daily backup script service

[Service]
Type=simple
ExecStart=/home/user/scripts/backup.sh

- Description 
 서비스에 대한 간략한 설명.

- Type 
 서비스가 어떻게 시작되고 동작할지에 대한 설정. (기본값 : simple )

• simple (기본값) :  명령을 포그라운드로 실행. systemd는 명령 실행 즉시 서비스 시작됨으로 간주.
• forking : 명령이 백그라운드로 fork() 하고 부모 프로세스는 종료.
• oneshot : 짧게 한 번만 실행되는 작업. 끝나면 종료.

 이외에도 notify, idle, exec 등..

- ExecStart
실제 실행할 명령어.

---

(추가구성) _ [Unit] 

Restart=on-failure	# 서비스 실패 시 재시작 여부
RestartSec=5		# 대기 시간

- Restart
 서비스 실패 시 재시작 여부

- RestartSec
 대기 시간

 

(추가구성) _ [Service] 

Restart=on-failure	# 서비스 실패 시 재시작 여부
RestartSec=5		# 대기 시간

- Restart
 서비스 실패 시 재시작 여부

- RestartSec
 대기 시간

 

실행로그 확인 
 journalctl -u backup.service 





2. timer

service와 같은 경로에 'backup' 이라는 이름의 timer를 만들어 준다.
 /etc/systemd/system/backup.timer 

(기본 구성)

[Unit]
Description=Run daily backup at 3AM

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

 

---

 

systemd vs crontab 

항목	systemd + timer	crontab
의존성 관리	다른 서비스/유닛들과 의존성 설정 가능 (After=, Requires= 등)	없음
로그 관리	journalctl로 표준화된 로그 확인 가능	표준 로그 분리 설정 필요 (기본은 로그 저장 안됨)
정확도	밀리초 단위도 가능	분 단위 스케줄만 가능
서비스 통합	다른 systemd 유닛들과 통합 관리	독립적으로 동작
작업 실패 시 재시도	설정 가능 (Restart=, StartLimitIntervalSec= 등)	직접 구현 필요
보안 및 권한 제어	sandboxing, User=, ProtectSystem= 등의 고급 보안 설정 가능	사용자 환경에 의존
설정 위치	/etc/systemd/system/*.service, *.timer	각 사용자 계정의 crontab 혹은 /etc/crontab