프로세스·서비스와 systemd

01fork·exec·wait로 읽는 프로세스 생성과 종료

• 프로세스의 구성프로세스는 실행 중인 프로그램의 주소 공간, 자격 정보, 열린 파일, 실행 상태 등을 묶은 커널 관리 단위다.
• fork전형적인 셸 실행에서는 fork 계열로 자식을 만들고 자식이 exec 계열로 새 프로그램 이미지를 적재한다.
• exec·PIDexec는 성공하면 같은 PID에서 프로그램을 교체하므로 새 PID를 하나 더 만드는 호출과 다르다.
• wait부모는 wait 계열로 자식의 종료 상태를 회수할 수 있다.
• 종료 코드종료 코드는 성공·실패 의미를 프로그램이 정하는 통신 수단이다.
• PID·프로세스ps의 PID는 프로세스 식별자, PPID는 현재 부모, SID는 세션, PGID는 프로세스 그룹을 뜻한다.
• 좀비R은 실행 가능, S는 인터럽트 가능한 대기, D는 보통 I/O 관련 비인터럽트 대기, Z는 실행을 끝냈지만 종료 상태가 회수되지 않은 좀비다.

  • 좀비가 CPU를 계속 계산하는 상태라는 해석은 틀리다.
• SIGTERMSIGTERM은 정상 정리 기회를 주는 종료 요청이고 SIGKILL은 프로그램의 정리 핸들러로 처리할 수 없는 강제 종료다.

ps -eo pid,ppid,sid,pgid,tty,stat,cmd
ps -p 1234 -o pid,ppid,stat,etime,%cpu,%mem,args
# STAT의 문자와 실제 활동을 구분해서 읽는다.

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

02전통적인 데몬화와 systemd 서비스의 차이

• 데몬·fork전통적인 데몬은 fork 뒤 부모를 끝내고 setsid로 새 세션을 만들어 제어 터미널에서 분리한다.
• fork다시 fork하여 최종 자식을 세션 리더가 아니게 만드는 형태는 제어 터미널을 다시 획득하는 일을 방지하려는 목적이 있다.

  • 작업 디렉터리와 umask, 열린 파일 디스크립터도 서비스 요구에 맞게 조정한다.
• PID부모가 끝난 자식은 PID 1 또는 설정된 subreaper에 입양될 수 있으므로 PPID가 1이라는 사실만이 데몬의 정의는 아니다.
• systemdsystemd 아래에서는 프로그램이 불필요하게 이중 fork를 하지 않고 전경에서 계속 실행되도록 두는 방식이 자연스럽다.
• 프로세스·cgroup서비스 관리자가 주 프로세스와 cgroup 안의 자식들을 추적하고 표준 출력·오류를 journal로 수집할 수 있기 때문이다.
• 재시작명령 뒤에 &를 붙이면 셸의 백그라운드 작업이 되지만 재시작 정책, 부팅 의존성, 상태 보고까지 갖춘 관리 서비스가 자동으로 만들어지는 것은 아니다.

03Type 값은 시작 명령의 완료 기준을 정한다

• Type=simple·프로세스Type=simple은 서비스 프로세스를 생성한 이른 시점에 시작이 진행된 것으로 취급하며 exec 자체가 실패하는 경우를 뒤늦게 볼 수 있다.
• Type=execType=exec는 프로그램 이미지 실행이 성공했는지를 시작 성공 판정에 반영한다.

  • 하지만 두 값 모두 데이터베이스 초기화나 HTTP 리스너 준비가 끝났다는 애플리케이션 수준의 신호를 보장하지 않는다.
• Type=notifyType=notify는 애플리케이션이 준비 완료 알림을 보내도록 협력하는 방식이다.
• Type=oneshotType=oneshot은 초기화·일회 작업의 명령 종료를 기다리며 RemainAfterExit=yes는 프로세스가 종료된 뒤에도 unit을 활성 상태로 유지하도록 할 수 있다.
• Type=forkingType=forking은 전통적 백그라운드 분기 프로그램에 맞추며 PIDFile 등의 주 프로세스 식별이 필요할 수 있다.
• failedrunning, exited, failed는 각 Type의 의미와 함께 읽어야 한다.

04unit 파일의 각 절을 요청 처리와 연결하기

• systemdsystemd는 service뿐 아니라 socket, timer, mount, target 등 여러 unit을 관리한다.
• unitunit 유형은 관리하는 대상과 활성화 방식을 구분한다.
• Unit·Service·Install[Unit]은 설명과 의존 관계를, [Service]는 실행 방법과 프로세스 속성을, [Install]은 enable할 때 만들 연결을 선언한다.
• 순서와 의존 관계After=는 상대적인 시작 순서를 정하고 Wants=나 Requires=는 다른 unit을 함께 끌어오는 관계를 표현한다.
• network-online의 범위After=network-online.target만 적었다고 그 target을 반드시 시작하는 것도 아니고, network-online이 외부 인터넷 연결을 영구 보장하는 것도 아니다.

  • 실제로 네트워크 준비가 필요한 서비스에만 해당 의존성을 둔다.
• User=·Group=User=와 Group=은 실행 자격 정보, WorkingDirectory=는 상대 경로 기준, UMask=는 새 파일 생성 권한 상한에 영향을 준다.
• ExecStartExecStart는 일반 셸 명령줄 전체와 같지 않으므로 파이프나 리다이렉션을 셸처럼 무조건 해석한다고 가정하지 않는다.
• 서비스 예제의 전제아래 예시는 /opt/demo/app.py를 미리 설치한 별도 서비스 계정으로 실행한다는 가정이다.
• Restart=Restart=on-failure는 실패 때 다시 시작하게 하지만 프로그램의 버그를 고치거나 매번 상태를 초기화하지 않는다.

[Unit]
Description=Study demo application

[Service]
Type=exec
User=demo
Group=demo
WorkingDirectory=/srv/demo
ExecStart=/usr/bin/python3 /opt/demo/app.py
Restart=on-failure
RestartSec=3s
UMask=0027

[Install]
WantedBy=multi-user.target

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

05설정 반영과 서비스 생애를 시간 순서로 추적하기

• unit·daemon-reloadunit 파일을 수정한 뒤 daemon-reload를 수행하면 systemd가 unit 정의와 의존 관계를 다시 읽는다.
• 프로세스·재시작이 작업만으로 애플리케이션 프로세스를 재시작하거나 그 프로그램의 설정 파일을 다시 읽게 하지는 않는다.
• start·unitstart는 현재 unit을 시작하고, enable은 지정 target에서 활성화할 연결을 만든다.

  • enable --now는 등록과 현재 시작을 함께 요청한다.
• reload 지원 조건애플리케이션의 reload 지원 여부는 ExecReload나 프로그램의 동작에 달려 있다.
• 정상 활성화 흐름정상 동작은 inactive에서 activating, Type에 맞는 준비 조건 뒤 active로 이어진다.
• 프로세스·failed주 프로세스가 비정상 종료하면 failed가 되거나 재시작 정책에 따라 다시 activating으로 갈 수 있다.

  • start 제한에 도달하면 반복 재시작이 중단될 수 있다.
• 상태 전환의 근거상태 변화의 이유는 MainPID, ExecMainStatus, journal의 같은 시각 기록을 함께 읽어야 한다.
• Active와 응답 성공active는 관리자가 보는 생애 상태이며 실제 요청 처리 성공은 리스너와 정상 응답으로 별도 설명할 수 있다.
• 재시작reload는 서비스가 지원하는 설정 재읽기이며 restart는 중지와 재시작을 포함한다.

systemctl cat demo.service
systemctl show demo.service -p Type -p MainPID -p SubState -p ExecMainStatus
journalctl -u demo.service -b --no-pager
# 명령은 unit 정의·현재 상태·이번 부팅 기록을 각각 보여 준다.

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

09장애를 시간 순서로 확인하기

• unit·프로세스unit 상태, 실제 프로세스, 리스닝 소켓, 로그, 요청 응답을 연결한다.
• 재시작실패 시각과 재시작 횟수, 종료 코드, 권한 오류를 먼저 확인하면 원인을 좁힐 수 있다.
• 로그의 공개 범위로그에는 운영 정보가 포함될 수 있으므로 공유할 때 필요한 부분만 남긴다.

ps -eo pid,ppid,user,stat,comm
systemctl --failed
journalctl -b -p warning --no-pager -n 20

프로세스와 실패한 unit, 현재 부팅의 최근 경고 로그를 조회한다. 로그 접근에는 추가 권한이 필요할 수 있다.

10서비스가 시작되고 실패하는 과정

• systemd·unit관리자가 서비스 시작을 요청하면 systemd는 unit 정의와 관계를 바탕으로 작업을 구성한다.
• unit필요한 의존 unit과 순서 조건이 처리되고 ExecStart 등의 설정에 따라 프로세스를 시작한다.
• 시작 완료의 기준어느 시점에 시작 완료로 판단하는지는 Type 등 서비스 정의에 달려 있다.

  • 예를 들어 Type=simple은 프로세스를 시작한 뒤 서비스가 시작됐다고 간주하는 방식이고, Type=notify는 준비 알림을 기다리는 방식이다.
  • 두 방식은 애플리케이션 준비 상태에 대한 기대가 다르다.
• 시작 후 비정상 종료서비스가 시작된 다음에도 주 프로세스가 비정상 종료할 수 있다.
• 재시작·failed종료 상태와 Restart 정책, 시작 제한 등 조건에 따라 재시작하거나 failed로 남는다.
• 재시작반복 재시작은 원인 해결을 뜻하지 않으며 짧게 살아나는 프로세스만 보면 정상처럼 오해하기 쉽다.
• 업무 준비와 의존성네트워크 연결이나 데이터베이스 초기화가 필요한 프로그램은 자신의 준비 상태를 어떻게 알릴지 설계해야 한다.

  • 단순한 After 관계만으로 의존 애플리케이션의 업무 준비 완료가 보장되지는 않는다.

1. 시작 요청현재 로드된 unit 정의를 사용해 작업을 만든다.
2. 프로세스 실행실행 사용자와 환경, 명령이 적용된다.
3. 시작 완료 판정Type에 맞는 기준으로 unit 상태가 바뀐다.
4. 비정상 종료종료 코드와 시그널, 해당 시각의 로그를 남긴다.
5. 정책 적용조건이 맞으면 재시작하고 제한 등에 걸리면 실패 상태를 확인한다.

11상태·로그·소켓으로 실패 지점 찾기

• unitunit 자체를 찾지 못하면 설치 경로와 이름, 로드된 정의부터 확인한다.
• 프로세스 시작 실패프로세스가 시작되지 않으면 실행 파일, 계정, 작업 디렉터리, 환경과 권한 오류를 살펴본다.
• 프로세스·소켓프로세스가 있는데 리스닝 소켓이 없다면 초기화 실패나 다른 주소에 바인딩했는지를 조사한다.
• 소켓소켓이 있어도 대표 요청이 실패하면 애플리케이션과 외부 의존성 단계로 범위를 옮긴다.
• 재시작이 순서는 관찰 범위를 넓히는 진단 절차이지 재시작을 반복하는 절차가 아니다. journal의 시간과 부팅 식별 범위를 맞추고 같은 시각의 종료 코드·재시작 횟수를 연결한다.
• unit·daemon-reloadunit 파일 변경을 읽히는 daemon-reload와 서비스 내부 설정을 다시 읽는 reload는 관찰 결과도 다르다.
• enable부팅 자동 시작을 enable해도 이미 실행 중인 프로세스의 내용이 바뀌지 않는다.
• 새 설정의 실제 사용설정 반영 뒤에는 새 프로세스 또는 새 설정이 실제 요청에 사용되는지 검증해야 한다.
• 로그 보존로그 보존이 제한된 환경에서는 과거 기록이 없다는 사실을 오류가 없었다는 증거로 삼지 않는다.

  • 프로세스가 존재한다고 요청을 정상 처리하는 것은 아니다.
• CPU 사용률CPU 사용률이 낮아도 잠금, 디스크 대기, 연결 고갈 때문에 응답하지 못할 수 있다.