데비안 리눅스 부팅 시 자동 실행 설정 등록 방법: cron.d와 systemd 비교

cron.d를 이용한 자동 실행 등록 방법

cron.d를 편집하는 방법은 여러 가지가 있지만, 현대 리눅스 시스템에서 가장 안전하게 수정하는 방법은 크론탭을 이용하는 것이다.

eqmaker@debian:~$ crontab -e
no crontab for eqmaker - using an empty one
Select an editor.  To change later, run select-editor again.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.tiny

Choose 1-2 [1]: 1

crontab -e명령을 실행하면 사용할 에디터를 선택하라는 메시지가 나오는데, nano와 vim중 익숙한 것을 사용하면 된다.

에디터를 선택한 후 cron 설정 파일을 수정할 수 있게 되는데, 다음과 같이 @reboot 키워드 뒤에 실행할 스크립트나 명령어를 입력해 준다.

# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
...(중략)...
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
@reboot /path/to/script.sh

마지막으로 변경 내용을 저장하고 에디터에서 빠져나오면 설정이 완료된다. 이제부터 이 시스템은 부팅될 때 마다 /path/to/script.sh를 실행한다.

cron.d의 한계

cron.d의 설정 자체는 매우 간단하며, 별도의 서비스 파일을 작성할 필요도 없다. 문제는 이 단순함이 운영 환경에서는 치명적인 약점이 된다는 점이다. cron 방식의 부팅 자동 실행에는 다음과 같은 한계가 있다.

• 실행 순서 제어 불가
• 재시작 정책 없음
• 실패 여부 확인 불가

예를 들어, 라우터 역할을 하는 시스템이라면, 최소한 랜카드는 올라온 다음 라우터 프로그램을 기동시켜야 한다. 하지만 cron은 부팅 시퀀스 도중 명령을 만나면 즉시 라우터 프로그램을 실행해버린다. 이때 네트워크가 준비되지 않았다면 라우터 프로그램이 정상적으로 초기화될 수 없을 것이다.

또 다른 예로, 와우자 미디어 서버에서 재생목록을 이용해 라이브 스트림을 생성하도록 요청하는 스크립트가 있을 경우, 미디어 서버 엔진이 완전히 초기화되기 전에 스크립트가 먼저 실행된다면 명령은 무시되고 자동화는 실패하게 된다.

결국 cron.d 방식은 단순한 자동 실행에는 적합하지만, 서비스를 운용하는 데에는 부족함이 있다. 때문에 이어서 소개할 systemd가 표준으로 자리 잡게 되었다.

systemd 서비스 유닛

systemd에 대해 가장 먼저 알아야 할 것은, 단순히 실행할 명령어만 한 줄 등록했던 cron.d와 달리, 모든 실행 프로그램을 서비스 유닛(Service Unit)이라는 개념으로 정의한다는 것이다. 그리고 이 정의를 담고 있는 파일을 보통 서비스 파일(Service File) 이라 부른다. (현장에서는 이 둘을 혼용해서 부르기도 한다.)

이 서비스 파일에는 실행 시점, 실행하기 전의 조건, 실행할 사용자 권한, 에러 발생 시 재시작 정책까지 설정할 수 있다. 서비스 파일은 보통 /etc/systemd/system/에 위치하며, 다음의 큰 3가지 부분으로 나뉜다.

• [Unit]섹션 : 이 서비스가 언제, 어떤 조건에서 시작되어야 하는지를 정의한다.
• [Service]섹션 : 실제로 무엇을 어떻게 실행하고, 실행 중 상태를 어떻게 관리할지를 정의한다.
• [Install]섹션 : 이 서비스를 부팅 시 어떤 실행 단계(target)에 연결할지를 정의한다.

systemd 서비스 파일의 작성 예시

실제로 systemd를 이용해 부팅시 프로그램을 실행하는 예를 살펴보겠다. 아래의 예제는 본 필자가 진행한 프로젝트의 일부분으로, openvpn 을 기동시키는 서비스이다.

/etc/systemd/system/ 디렉토리로 이동해서 vpn213.service라는 파일을 생성하고 아래와 같이 내용을 적어 주었다.

[Unit]
Description=VPN213
After=network-online.target

[Service]
Type=forking
PIDFile=/var/run/openvpn-client/vpn213.pid
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/client/vpn213.ovpn
ExecReload=/bin/kill -HUP $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

Description

이 서비스 파일을 구분하기 위한 메모이다. 실제 서비스에 영향을 주지는 않는다.

After

이 프로세스가 실행되는 순서를 지정한다. network-online.target는 네트워크가 준비된 상태를 의미한다.

Type

이 프로세스가 동작하는 모드를 지정한다. forking는 데몬 모드로 동작시키는 것을 의미한다.

PIDFile

이 데몬을 추적할 PID 파일을 지정한다. openvpn처럼 systemd에게 PID를 직접 제공하지 않는 경우 사용한다.

ExecStart

실행할 명령어 또는 절대 경로를 포함한 스크립트

ExecReload

서비스를 reload해야할 때 동작

Restart

서비스 프로세스가 종료되었을 때, systemd가 이를 다시 실행할지 여부와 조건

WantedBy=multi-user.target

이 서비스가 시작되는 시점을 지정한다. multi-user.target는 콘솔과 네트워크가 사용 가능해진 시점을 의미한다.

결론적으로 이 서비스 파일은, 다음과 같이 동작하게 된다.

1. 부팅이 되어 콘솔과 네트워크의 사용이 가능해 진 시점에 서비스를 활성화 시키고
2. 네트워크의 연결이 완료되어 통신이 가능한 상태인 것을 확인한 다음
3. /usr/sbin/openvpn --config /etc/openvpn/client/%i.ovpn를 백그라운드 (데몬모드)로 실행시킨다.
4. systemctl reload명령으로 설정을 다시 읽을 경우 메인 프로세스에 SIGHUP 신호를 보내, 프로세스를 종료하지 않고 설정을 다시 읽도록 요청한다.
5. 혹시 서비스가 죽으면 자동으로 재시작한다.

단순히 cron.d를 사용할 때 보다도 더 서비스 환경에 적합한 구성인 것을 알 수 있다.

설정이 끝났다면 다음 명령어를 입력하여 시스템 데몬으로 등록해 준다.sudo systemctl daemon-reload

마지막으로 시스템 서비스로 활성화 해 주면 동작을 시작한다. sudo systemctl enable --now vpn213.service

systemd의 단점

물론 운영 환경의 표준인 systemd도 초보 엔지니어에게는 몇 가지 까다로운 점이 존재한다.

• 엄격한 문법과 경로 규칙 : cron보다 훨씬 까다롭다. 모든 경로는 반드시 절대 경로여야 하며, 설정 파일의 오타 하나에도 서비스 로드 자체가 거부된다.
• 무한 루프(Crash Loop) : 만약 소스에 치명적인 오류가 있는데 Restart=always를 걸어두면, 혼자 무한루프를 돌며 재시작을 시도한다.
• 환경 변수 선언 : 사용자의 환경 변수를 자동으로 가져오지 않는다. 필요한 환경 변수는 서비스 파일 내에 Environment= 옵션으로 직접 적어주어야 한다.
• 디버깅 : 에러 메시지를 확인하기 위해서는 journalctl 같은 별도의 명령어를 통해 로그를 확인해야 한다.