리눅스 부팅 자동 명령 실행: cron과 systemd

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

cron을 이용한 작업은 사용자별 crontab을 사용하거나 시스템 전역 설정에 등록할 수 있다. crontab은 개인 사용자의 작업을 관리할 때는 적합하지만 본 글에서는 시스템 전체의 부팅 작업을 관리하는 것이 목적이므로, /etc/cron.d/ 디렉토리에 설정 파일을 직접 생성하는 방법을 설명한다.

다음과 같이 /etc/cron.d/ 디렉토리에 자동 실행 작업을 저장할 파일을 생성한다. 파일 이름에는 확장자를 붙이지 않고 영문자, 숫자, 밑줄 및 하이픈만 사용하는 것이 안전하다.

파일을 열었으면 다음과 같이 @reboot, 명령을 실행할 사용자, 실행할 스크립트의 절대 경로를 차례로 입력한다.

# 시스템이 부팅되어 cron 데몬이 시작될 때 eqmaker 권한으로 실행하는 스크립트의 예
@reboot eqmaker /path/to/script.sh

/etc/cron.d/의 설정은 사용자 crontab과 달리 명령을 실행할 사용자 이름을 반드시 지정해야 한다. 위의 예에서는 eqmaker 사용자의 권한으로 /path/to/script.sh를 실행한다. 루트 권한이 필요한 작업이라면 사용자 이름을 root로 지정하면 된다.

설정 파일을 저장한 다음 설정 파일의 소유자와 권한을 확인한다. 보통 root가 소유하고 다른 사용자가 수정할 수 없도록 설정한다.

실행할 스크립트에도 실행 계정이 실행 권한을 가지고 있어야 한다.

이제 시스템이 부팅되어 cron 데몬이 시작되면 지정된 사용자의 권한으로 /path/to/script.sh가 실행된다.

cron의 한계

/etc/cron.d/의 설정 자체는 매우 간단하다. 문제는 이 단순함이 운영 환경에서는 치명적인 약점이 될 수 있다는 것이다. 특히 @reboot를 이용한 부팅 자동 실행에는 다음과 같은 한계가 있다.

• 다른 서비스와의 실행 순서 및 의존 관계를 직접 제어하기 어렵다.
• 실행한 프로세스가 종료되더라도 자동으로 다시 시작하지 않는다.
• 프로세스의 실행 상태를 지속적으로 추적하지 않는다.

@reboot 작업은 시스템의 모든 부팅 과정이 완료된 시점이 아니라 cron 데몬이 시작될 때 실행된다. 따라서 네트워크나 다른 서비스가 아직 올라오지 않은 상태에서 명령이 실행될 수 있다.

예를 들어 라우터 역할을 하는 시스템이라면 최소한 네트워크 설정이 끝난 다음에 라우터 프로그램을 기동해야 한다. 하지만 cron은 부팅 도중 실행 명령을 만나면 냅다 라우터 프로그램을 실행해 버린다. 이런 상황이 발생하면 라우터 프로그램이 정상적으로 작동할 리가 없다.

또 다른 예로, 와우자 스트리밍 엔진에서 라이브 스트림을 생성하도록 요청하는 스크립트가 있다고 가정해 보자. 와우자가 완전히 초기화되기 전에 스크립트가 먼저 실행되면 요청이 정상적으로 처리되지 않게 된다.

결국 /etc/cron.d/ 방식은 부팅할 때 단순한 명령을 한 번 실행하는 용도에는 적합하지만, 실행 순서와 의존 관계, 상태 감시가 필요한 서비스를 운용하기에는 부족함이 있다. 이러한 작업에는 이어서 소개할 systemd가 더 적합하다.

systemd 서비스 유닛

systemd에서 프로그램을 서비스로 관리하려면 실행 대상과 관리 방법을 서비스 유닛(Service Unit)으로 정의해야 한다. 실행할 명령 한 줄을 등록하는 cron과 달리, 서비스 유닛에는 프로그램의 실행 방법과 의존 관계 및 장애 대응 방법을 설정할 수 있다.

서비스 유닛의 정의를 기록한 파일을 서비스 유닛 파일(Service Unit File)이라고 하며, 서비스 파일이나 유닛 파일이라고도 부른다. 이 파일들은 /etc/systemd/system/ 디렉토리에 위치하며, 안을 열어 보면 아래와 같이 세 섹션으로 이루어져 있다.

[Unit] 섹션

이 서비스가 언제, 어떤 조건에서 시작되어야 하는지를 정의한다.

[Service] 섹션

실제로 무엇을 어떻게 실행하고, 실행 중 상태를 어떻게 관리할지를 정의한다.

[Install] 섹션

systemctl enable을 실행할 때 이 서비스를 어떤 대상 유닛에 연결할지 정의한다.

systemd 서비스 파일의 작성과 적용 예시

아래의 예제는 본 필자가 진행한 프로젝트의 일부로, VPN 연결을 위해 OpenVPN 클라이언트를 기동하는 서비스다.

먼저 /etc/systemd/system/ 디렉토리에 vpn213.service라는 서비스 유닛 파일을 생성한다.

서비스 파일에는 다음과 같이 입력한다.

[Unit]
Description=OpenVPN client for VPN213
Wants=network-online.target
After=network-online.target

[Service]
Type=exec
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/client/vpn213.ovpn
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

이 예제는 OpenVPN을 별도의 백그라운드 프로세스로 전환하지 않고 포그라운드 상태로 실행하여 systemd가 프로세스를 직접 추적하도록 구성한 것이다. 따라서 vpn213.ovpn 설정 파일에 daemon이나 writepid 지시어가 있다면 제거해야 한다.

Description

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

Wants

network-online.target도 함께 시작하도록 약한 의존 관계를 설정한다.

After

이 프로세스가 실행되는 순서를 지정한다. network-online.target은 네트워크가 준비된 상태를 의미한다. 즉, 네트워크 준비가 끝난 다음에 실행하게 한다.

Type

이 프로세스가 동작하는 모드를 지정한다. exec는 프로그램이 메모리에 적재되어 정상적으로 실행되는 것까지 확인한 다음 성공으로 판단한다.

ExecStart

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

ExecReload

서비스를 reload해야 할 때 동작. 메인 프로세스에 SIGHUP 신호를 보내 설정을 다시 읽는다.

Restart

서비스 프로세스가 종료되었을 때, systemd가 이를 다시 실행할지 여부와 조건. on-failure는 서비스가 실패한 경우이다.

RestartSec

서비스가 실패한 후 다시 시작하기까지 기다릴 시간을 지정한다. 이 예제에서는 5초 후 재시작한다.

WantedBy=multi-user.target

systemctl enable을 실행할 때 서비스를 multi-user.target에 연결한다. 이를 통해 부팅 과정에서 이 서비스가 함께 시작되도록 설정한다.

결과적으로 이 서비스는 다음과 같이 동작한다.

1. 서비스를 활성화하면 부팅 과정에서 multi-user.target에 연결되어 시작 대상에 포함된다.
2. network-online.target의 시작 작업 이후에 서비스 시작을 시도한다.
3. /usr/sbin/openvpn --config /etc/openvpn/client/vpn213.ovpn을 실행하고 해당 프로세스를 메인 프로세스로 추적한다.
4. systemctl reload vpn213.service를 실행하면 메인 프로세스에 SIGHUP 신호를 보내 설정을 다시 읽도록 요청한다.
5. 프로세스가 비정상적으로 종료되면 5초 후 자동으로 다시 시작한다.

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

파일을 저장한 뒤 다음 명령으로 서비스 유닛의 문법과 설정을 확인한다.

오류가 없다면 systemd 관리자가 새로 작성한 유닛 파일을 다시 읽도록 한다.

마지막으로 서비스를 부팅 시 자동으로 시작하도록 활성화한다.

서비스의 실행 상태와 로그는 다음 명령으로 확인할 수 있다.

systemd의 단점

여러 장점만 있어 보이는 systemd도 몇 가지 단점이 존재하는데, 한마디로 사용하기가 좀 까다롭다.

• 엄격한 문법과 경로 규칙 : cron보다 훨씬 까다롭다. 설정 파일의 오타 하나에도 서비스 로드 자체가 거부되며, 실행 파일과 설정 파일의 경로는 셸의 작업 환경에 의존하지 않도록 절대 경로로 명확하게 지정하는 것이 안전하다.
• 무한 루프(Crash Loop) : 만약 소스에 치명적인 오류가 있는데 Restart=always를 걸어두면, 혼자 무한 루프를 돌며 재시작을 시도한다. 일정 횟수 이상 빠르게 실패하면 systemd의 시작 속도 제한에 걸려 start-limit-hit 상태로 중단될 수도 있다.
• 환경 변수 선언 : 필요한 환경 변수는 서비스 파일의 Environment=에 지정하거나 EnvironmentFile=을 이용해 별도 파일에서 불러와야 한다.
• 디버깅 : 에러 메시지를 확인하기 위해서는 터미널에서 바로 보는 게 아니라 journalctl 같은 별도의 명령어를 통해 로그를 확인해야 한다.