systemd 서비스 파일 생성기

Node.js, Python, Go 프로그램을 Linux 서버에서 계속 실행하고, 부팅 시 시작하고, 죽으면 다시 시작하게 하려면 systemd 옵션을 일일이 외워야 할까요? 명령과 사용자를 입력하고 재시작 정책과 환경 변수를 고르면, .service 파일과 설치·시작 명령을 함께 복사할 수 있습니다. “일정에 따라 실행”을 체크하면 cron을 대체하는 최신 방식인 .timer도 만들어 줍니다.

브라우저에서 실행 — 입력한 내용은 업로드되지 않아요

서비스 이름

파일 이름이 됩니다. 예: myapp → myapp.service

설명

명령 (ExecStart)

프로그램의 전체 경로를 쓰세요. 예: /usr/bin/python3 app.py

작업 디렉터리

실행 사용자

그룹

Type

명령이 포그라운드에서 계속 실행됩니다 (대부분의 웹 앱과 스크립트).

Restart

재시작 전 대기 시간 (초)

환경 변수

한 줄에 KEY=value 하나씩 쓰세요. 공백이 있는 값은 자동으로 따옴표 처리됩니다.

환경 파일

최대 열린 파일 수 (LimitNOFILE)

0이면 시스템 기본값을 유지합니다.

네트워크가 온라인이 된 뒤에 시작기본 보안 강화 (새 권한 금지, 개별 /tmp, 읽기 전용 시스템)일정에 따라 실행 (.timer 만들기)

myapp.service

[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

설치 및 시작

sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF'
[Unit]
Description=My application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/srv/myapp
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service
journalctl -u myapp.service -f

명령은 서버에서 root로 그대로 붙여 넣으세요. 유닛 파일을 수정한 뒤에는 systemctl daemon-reload를 다시 실행하세요. 로그: journalctl -u <name>.

사용 방법

서비스 이름, 전체 경로를 쓴 명령, 작업 디렉터리를 입력하세요.
실행 사용자, 재시작 정책, 필요한 환경 변수를 설정하세요.
필요하면 기본 보안 강화나 일정(OnCalendar)을 추가해 타이머를 만드세요.
생성된 파일을 복사하거나, 설치 명령을 서버의 root 셸에 붙여 넣으세요.

옵션 설명

Type: simple은 포그라운드에서 계속 실행되는 프로그램에, oneshot은 예약 작업처럼 한 번만 실행되는 스크립트에 알맞습니다.
Restart: “실패 시”는 오류로 종료되거나 죽었을 때 서비스를 다시 시작하고, “항상”은 정상 종료한 뒤에도 다시 시작합니다.
OnCalendar: 타이머가 동작하는 시각입니다. 예: daily, 매일 새벽 3시는 *-*-* 03:00:00. 표현식은 systemd-analyze calendar로 확인하세요.

예시: 타이머로 실행하는 야간 작업

매일 밤 오전 3시에 스크립트를 실행하려면 명령(ExecStart)을 /usr/local/bin/backup.sh로, 서비스 이름을 backup으로, Type을 oneshot으로, Restart를 재시작 안 함으로 설정한 뒤 “일정에 따라 실행 (.timer 만들기)“와 “기본 보안 강화”를 체크하세요. 기본 사용자와 작업 디렉터리에서 생성기는 파일 두 개를 만들어요. backup.service는 다음과 같아요.

[Unit]
Description=Nightly backup
[Service]
Type=oneshot
User=www-data
WorkingDirectory=/srv/myapp
ExecStart=/usr/local/bin/backup.sh
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only

backup.timer는 다음과 같아요.

[Unit]
Description=Run backup on a schedule
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
Unit=backup.service
[Install]
WantedBy=timers.target

타이머를 켜면 두 가지가 바뀌어요. 서비스 파일에서 [Install] 섹션이 사라지는데, 타이머가 대신 서비스를 시작하기 때문이에요. 설치 명령도 서비스가 아니라 타이머를 활성화해요.

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
journalctl -u backup.service -f

타이머 옵션을 체크해도 Type은 자동으로 바뀌지 않으므로, 끝나는 작업에는 직접 oneshot을 고르세요. oneshot 서비스에 Restart Always를 조합하면 유효하지 않으므로, 생성기는 Restart를 빼고 경고를 표시해요.

자주 묻는 질문

파일은 어디에 두나요?

/etc/systemd/system/에 두고 systemctl daemon-reload와 systemctl enable --now <name>.service를 실행하세요. 생성된 명령이 이 과정을 모두 처리합니다.

“Executable path is not absolute” 오류로 서비스가 실패하는 이유는 무엇인가요?

오래된 systemd는 ExecStart에 프로그램의 전체 경로가 필요합니다. which로 찾을 수 있습니다. 예: which node.

타이머와 cron 중 무엇이 좋을까요?

타이머는 저널에 로그를 남기고, 서버가 꺼져 있는 동안 놓친 실행을 만회할 수 있으며, 동시에 두 번 실행되지 않습니다. cron은 한 줄짜리 작업에는 더 간단하고 지금도 잘 동작합니다.

개인정보 보호

이 도구는 전적으로 브라우저에서 실행돼요. 파일과 텍스트는 기기에서 처리되며 서버로 업로드되지 않아요.