15강 / 20강

systemd — 꺼지면 알아서 다시 켜지게

터미널을 닫아도 쇼핑몰이 계속 돌아야 합니다

14강에서 앱을 배포했습니다. 이제 실행하면 되겠죠?

cd ~/shop
.venv/bin/gunicorn -w 3 -b 127.0.0.1:8000 app:app

됩니다. 그런데 터미널을 닫는 순간 쇼핑몰이 죽습니다. SSH 연결이 끊겨도 죽고, 서버를 재부팅해도 안 켜지고, 앱이 오류로 죽어도 아무도 살려 주지 않습니다.

이 세 가지 문제를 한꺼번에 해결하는 것이 systemd 입니다.

①터미널과 분리내가 나가도 계속 돕니다

②부팅 시 자동 시작서버가 켜지면 알아서

③죽으면 자동 재시작3초 뒤 다시 살립니다

④로그 모으기journalctl 로 한곳에서 (17강)

고등학생터미널을 닫아도 계속 돌아야 합니다

8강에서 본 세 가지 문제를 기억하시죠?

문제	systemd 의 답
터미널을 닫으면 죽는다	독립적으로 실행
죽으면 사람이 켜야	자동 재시작 ✔
재부팅하면 안 뜬다	부팅 시 자동 ✔

세 문제를 설정 파일 하나로 해결한다

그리고 덤으로

기능	설명
로그 수집	journalctl 로 한 번에 (17강)
의존 순서	DB 가 뜬 뒤에 앱을
자원 제한	메모리 상한을 정한다
계정 지정	root 가 아닌 계정으로

직접 만들려면 수백 줄인 것을 설정 열 줄로 한다

비유 — 건물 관리인

일	관리인이
아침에 문 열기	부팅 시 시작
등이 나가면 갈기	죽으면 재시작
일지 쓰기	로그
순서대로 켜기	의존성

사람이 밤새 지킬 필요가 없다 — 그게 목적이다

고등학생systemd = PID 1

note 의 이 사실이 8강과 이어집니다.

모든 프로세스의 조상이 systemd 다

왜 PID 1 이 특별한가

특징	설명
가장 먼저 실행	커널이 직접 띄운다
부모가 없다	모든 것의 조상
죽으면 안 된다	죽으면 커널 패닉
고아를 입양	부모 잃은 프로세스를 맡는다

마지막이 중요하다 — 버려진 프로세스를 정리한다

고아 프로세스가 뭔가

부모가 먼저 죽으면 자식은 어떻게 될까요?

상황	결과
부모가 죽는다	자식은 계속 산다
자식이 끝나면	누가 정리하나?

정리 안 하면 좀비가 쌓인다 — PID 1 이 대신 맡는다

비유 — 마을 이장

마을에 주인 없는 집이 생기면 이장이 관리합니다.

아무도 안 맡으면 흉가가 쌓이죠.

누군가는 최종 책임을 져야 한다 — 그게 PID 1

확인해 보기

ps -p 1 -o comm=      # systemd
pstree -p | head      # 나무의 뿌리

내가 띄운 모든 것이 여기서 갈라져 나온다

서비스의 상태를 보는 법

쇼핑몰 서비스의 현재 상태

bash 내 가상 Ubuntu 서버에서 실행

systemctl status shop

읽는 법을 익혀 둡시다. 이 화면은 서버 관리자가 하루에 수십 번 봅니다.

● active (running)정상초록 점. 잘 돌고 있습니다

○ inactive (dead)꺼짐멈춰 있습니다

× failed고장켜려다 실패했습니다

enabled자동 시작 켜짐재부팅해도 켜집니다

disabled자동 시작 꺼짐지금은 돌아도 재부팅하면 안 켜짐

고등학생active 와 enabled 는 완전히 다릅니다

note 의 이 구분이 가장 헷갈리는 부분입니다.

말	뜻	확인
active	지금 돌고 있다	`systemctl status`
enabled	부팅 때 자동 시작	`systemctl is-enabled`

네 가지 조합이 전부 가능하다

active	enabled	상황
✔	✔	정상
✔	✗	지금은 도는데 재부팅하면 끝 ⚠
✗	✔	죽었지만 다음 부팅엔 뜬다
✗	✗	완전히 꺼짐

두 번째가 가장 흔한 사고다 — 몇 달 뒤 재부팅에서 터진다

그래서 명령이 둘입니다

systemctl start myapp     # 지금 켠다
systemctl enable myapp    # 부팅 시 켜지게
systemctl enable --now myapp   # 둘 다 ✔

--now 를 쓰면 둘을 한 번에 — 빠뜨릴 일이 없다

비유 — 알람과 지금 일어나기

동작	비유
start	지금 일어난다
enable	알람을 맞춘다

지금 일어났다고 내일도 일어나는 건 아니죠. 알람을 맞춰야 합니다.

"지금" 과 "다음부터" 는 따로 설정한다

배포 후 반드시 확인

systemctl is-active myapp     # active?
systemctl is-enabled myapp    # enabled?

둘 다 확인하는 것이 배포 체크리스트에 들어가야 한다

🎮 서비스 실험실

start · stop · enable · disable 을 조합해 보고, 재부팅 버튼을 눌러 무엇이 살아남는지 확인해 보세요.

다섯 가지 명령이면 충분합니다

① stop — 지금 끕니다

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl stop shop
systemctl status shop

정말 죽었는지 확인 — 연결이 거부됩니다

bash 내 가상 Ubuntu 서버에서 실행

curl http://127.0.0.1:8000/healthz

② start — 다시 켭니다

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl start shop
curl http://127.0.0.1:8000/healthz

③ restart(껐다 켜기) · ④ enable(재부팅해도 켜지게)

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl restart shop
sudo systemctl enable shop
systemctl status shop

서비스 파일 — 어떻게 실행할지 적어 둔 설명서

systemd 는 이 파일을 보고 서비스를 실행합니다. 우리 쇼핑몰의 것을 열어 봅시다.

쇼핑몰이 어떻게 실행되는지 여기 다 적혀 있습니다

bash 내 가상 Ubuntu 서버에서 실행

cat /etc/systemd/system/shop.service

After=network.target순서네트워크가 준비된 뒤에 시작

User=jit누구로 실행할까14강에서 배운 최소 권한

WorkingDirectory=어디서 실행할까cd 를 대신해 줍니다

ExecStart=무엇을 실행할까반드시 전체 경로로

Restart=always죽으면?3초 뒤 다시 살립니다

WantedBy=multi-user언제 켤까enable 하면 부팅 때 켜짐

고등학생ExecStart 는 반드시 전체 경로

note 의 이 경고가 초보자가 반드시 겪는 문제입니다.

systemd 는 PATH 가 거의 없다 — 짧은 이름을 못 찾는다

왜 그런가

실행 주체	PATH
내 셸	풍부하다 — 로그인 시 설정됨
systemd	최소한 — /usr/bin:/bin 정도

터미널에서 되던 것이 systemd 에서 안 된다

특히 가상환경

# 안 된다
ExecStart=python app.py

# 된다
ExecStart=/home/app/.venv/bin/python /home/app/app.py

14강의 ".venv 는 그냥 폴더" 가 여기서 쓰인다

activate 를 못 하니 그 안의 python 을 직접 지정합니다. 그러면 그 환경의 라이브러리를 씁니다.

같은 이유로 조심할 것들

항목	주의
WorkingDirectory	지정 안 하면 / 에서 실행
User	지정 안 하면 root ⚠
Environment	환경 변수를 직접 줘야

4강의 상대 경로 함정이 그대로 나타난다

비유 — 낯선 사람에게 심부름

지시	결과
"늘 가던 가게에서"	어딘지 모른다
"○○로 15번지 가게"	찾아간다 ✔

내 맥락을 공유하지 않는 상대에게는 전부 말해 줘야 한다

19강의 cron 에서 똑같은 함정이 나옵니다.

서비스 파일을 고쳤다면 — daemon-reload

서비스 파일을 고친 뒤 그냥 restart 하면 옛날 내용으로 실행됩니다. systemd 에게 "설명서가 바뀌었어"라고 알려 줘야 해요.

sudo nano /etc/systemd/system/shop.service
sudo systemctl daemon-reload     ← 이걸 잊지 마세요
sudo systemctl restart shop

직접 망가뜨려 보기

서비스 파일의 ExecStart 를 없는 경로로 바꾸면 어떻게 되는지 보세요. 아래 터미널에서 직접 해 보고, 다시 고쳐 살려 보세요.

🤔 확인 문제

서비스를 start 만 하고 enable 을 하지 않으면 어떻게 되는가?

🤔 확인 문제

서비스 파일의 ExecStart 에 전체 경로를 써야 하는 이유는?

해설 $PATH 는 로그인할 때 .bashrc 등에서 설정됩니다. systemd 는 그 과정을 거치지 않으므로 gunicorn 만으로는 찾지 못해요. 서비스 시작 실패의 가장 흔한 원인입니다.

🤔 확인 문제

서비스 파일(.service)을 수정한 뒤 반드시 해야 할 명령은?

해설 systemd 는 서비스 파일을 메모리에 읽어 둡니다. daemon-reload 로 새로 읽게 한 뒤 restart 해야 바뀐 설정이 적용됩니다.