데몬과 systemd

데몬이란

데몬(daemon)은 제어 터미널 없이 백그라운드에서 계속 실행되며 요청이나 일정에 따라 일하는 프로세스다. 웹 서버(nginx), SSH 서버(sshd), 예약 작업(cron), 메일 서버(sendmail·postfix) 같은 것들이다. 이름 끝에 d가 붙는 관례가 있다. Linux에서 "서비스"는 서비스 매니저가 관리하는 데몬을 가리킨다.

데몬이 터미널에서 분리되어야 하는 이유:

• 터미널을 닫으면 그 세션의 프로세스에 SIGHUP이 간다. 데몬은 로그아웃과 무관하게 살아야 한다.
• 사용자가 실수로 누른 Ctrl+C가 데몬에 가면 안 된다.
• 표준 입출력으로 사람과 대화하지 않는다. 소켓·파일로 다른 프로세스와 소통하고, 서비스 매니저의 시그널(SIGTERM으로 정지, 관례상 SIGHUP으로 설정 다시 읽기)로 제어된다.

프로세스 그룹, 세션, 제어 터미널

flowchart TB
    s["세션<br/>(setsid로 생성, 제어 터미널 최대 하나)"] --> pg1["프로세스 그룹<br/>(셸의 작업 하나 = 파이프라인 하나)"]
    s --> pg2["프로세스 그룹"]
    pg1 --> p1["프로세스"]
    pg1 --> p2["프로세스"]

터미널은 세션 단위로 붙는다. Ctrl+C의 SIGINT는 그 터미널의 포그라운드 프로세스 그룹 전체에 간다. 그래서 터미널에서 벗어나려면 새 세션을 만들어야 한다.

전통 방식: SysV 데몬 만들기

예전의 init 스크립트(/etc/init.d)는 프로그램을 실행만 해 줬다. 나머지는 데몬이 스스로 해야 했다. man 7 daemon이 정리한 핵심 절차는 이렇다.

이중 fork 때문에 init 스크립트는 실제 데몬의 PID를 알 수 없었고, PID 파일에 의존해야 했다. PID 파일이 남아 있거나 다른 프로세스가 그 번호를 재사용하면 관리가 꼬였다.

systemd: 매니저가 다 해 준다

현재 주요 배포판(Debian·Ubuntu·RHEL 계열·Fedora·Arch)은 PID 1로 systemd를 쓴다. macOS의 PID 1은 launchd다.

systemd 아래의 데몬(new-style daemon)은 포그라운드로 그냥 실행하면 된다. fork·setsid·PID 파일·/dev/null 연결은 systemd가 한다. 출력은 stdout·stderr로 쓰면 저널이 모은다.

유닛 파일

systemd가 관리하는 대상은 모두 유닛(unit)이다. 종류는 확장자로 구분한다: .service, .timer, .socket, .target(유닛 묶음, 옛 runlevel 역할), .mount, .path 등.

# /etc/systemd/system/myapp.service
[Unit]
Description=My app
Wants=network-online.target
After=network-online.target
 
[Service]
Type=simple
User=myapp
WorkingDirectory=/srv/myapp
ExecStart=/usr/bin/myapp
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

• [Unit]의 Wants·Requires는 함께 켤 유닛, After·Before는 순서다. 둘은 별개라 보통 같이 쓴다. Conflicts는 동시에 켜지지 않게 한다.
• [Install]의 WantedBy=multi-user.target은 "일반 다중 사용자 부팅에 포함"이라는 뜻이다. enable할 때 이 정보로 링크를 만든다.
• 기존 유닛 일부만 바꾸려면 systemctl edit 이름으로 드롭인(.d/override.conf)을 만든다.

컨테이너를 유닛으로 띄우기

오케스트레이터 없이 서버 몇 대에서 컨테이너를 상시 돌릴 때는 systemd가 감독자가 된다. 데몬화나 PID 파일이 필요 없고 로그는 저널에 모인다.

# /etc/systemd/system/app.service
[Unit]
Requires=docker.service
After=docker.service
 
[Service]
ExecStartPre=-/usr/bin/docker rm -f app
ExecStart=/usr/bin/docker run --rm --name app -p 8080:8080 myorg/app:1.4.2
ExecStop=/usr/bin/docker stop app
Restart=always
 
[Install]
WantedBy=multi-user.target

Podman은 이를 정식 기능으로 만들었다. Quadlet은 /etc/containers/systemd/app.container에 [Container] 절(Image=, PublishPort=)만 쓰면 systemd 서비스 유닛을 생성해 준다. 과거 CoreOS의 fleet은 이 유닛 파일을 etcd 위에서 여러 머신에 나눠 배치하던 「클러스터 init 시스템」이었다. 유닛에 [X-Fleet] 절을 두고 Conflicts=app.*.service(같은 서비스는 머신당 하나), MachineOf=(같은 머신에), MachineMetadata=(조건에 맞는 머신에)로 배치를 정했다. fleet은 개발이 멈췄고 그 일은 쿠버네티스가 맡는다.

cron 대신 systemd 타이머

cron은 /etc/crontab이나 crontab -e에 분 시 일 월 요일 명령을 적는다. systemd 타이머는 같은 일을 하는 .timer 유닛이다. 기본으로 같은 이름의 .service를 실행한다.

# /etc/systemd/system/myapp.timer
[Unit]
Description=Run myapp hourly
 
[Timer]
OnCalendar=hourly          # *-*-* *:00:00 과 같음
OnBootSec=30s              # 부팅 30초 뒤에도 한 번
Persistent=true            # 꺼져 있어 놓친 실행은 켜진 뒤 바로
RandomizedDelaySec=1min    # 여러 서버가 동시에 몰리지 않게
 
[Install]
WantedBy=timers.target

systemctl list-timers로 마지막·다음 실행 시각을 보고, systemd-analyze calendar "Mon *-*-* 09:00"으로 표현식을 검증한다. 한 줄짜리 간단한 작업에는 cron도 여전히 충분하다.

데몬 예: 메일 서버

메일 서버는 데몬의 전형적인 예다. 25번 포트에서 SMTP 연결을 기다리고, 받은 메일은 다른 서버로 넘기거나 /var/mail/사용자에 넣는다. 로그는 저널이나 /var/log/mail.log에 남는다. 다만 아무 서버나 Gmail 같은 곳으로 메일을 보내면 거부된다. 수신 측은 보낸 도메인이 SPF·DKIM·DMARC 레코드(DNS)로 인증되는지 확인하고, 가정용·클라우드 IP의 25번 포트 발신은 막혀 있는 경우가 많다. 실서비스는 메일 발송 서비스를 쓴다.

부팅 과정: 전원에서 로그인까지

systemd가 PID 1로 뜨기까지와 그 이후의 흐름은 다음과 같다.

systemd-analyze blame으로 부팅 중 어떤 유닛이 오래 걸렸는지 볼 수 있다. 1~4단계에서 펌웨어가 디스크의 부트 블록(MBR·VBR 또는 EFI 시스템 파티션)을 찾아 부트 로더를 올리는 세부 과정은 디스크 관리와 스케줄링의 「부팅 과정」에 있다.

정리

• 데몬 = 터미널과 분리되어 백그라운드에서 도는 서비스 프로세스다.
• SysV 시절에는 데몬이 이중 fork·setsid·PID 파일을 직접 처리했다.
• systemd 아래에서는 포그라운드로 실행하고, 나머지는 유닛 파일에 선언한다.
• 관리자 유닛은 /etc/systemd/system에 두고 daemon-reload → enable --now.
• 주기 작업은 타이머 + 서비스로 만들면 로그·재시도·놓친 실행 보충을 공짜로 얻는다.

관련 노트: UNIX 시그널, 프로세스와 스레드, 리눅스 배포판과 패키지 관리, 리눅스 접근 제어