리눅스에서 지금 당장 아래 명령어를 입력해보자!
$ ps aux
$ pstree
아마도 리눅스를 조금 다루어 보았다면 'ps'는 상당히 익숙한 명령어일 것입니다. 잘 아시겠지만, 리눅스에서 명령어 'ps'는 현재 프로세스의 상태를 출력해주죠. 이번 포스팅에서는 리눅스 프로세스에 대해서 한번 다뤄보려고 합니다. 특히 그 중에도 부모 - 자식 프로세스간의 관계와 좀비 프로세스에 관해서 말이죠.
Linux의 PID 1 - init, 그리고 systemd
리눅스의 첫 번째 user space(사용자 공간) 프로세스인 init은 커널 부팅 후 첫 번째로 실행되는 프로세스입니다. 일반적으로 리눅스의 모든 프로세스들은 하나의 부모 프로세스를 가지게 되는데, 특이하게도 이 init은 부모 프로세스가 없습니다. 그 이유는 init이 최초의 프로세스이기 때문이죠. 게다가 init은 직, 간접적으로 다른 프로세스들의 부모 프로세스가 됩니다. 따라서 이 최초의 프로세스 init은 PID(Process ID) 1번을 부여받게 됩니다.
PID 1은 절대로 종료되어서는 안 되며, 시스템이 실행되는 동안 항상 존재해야 합니다. 또한 시스템 재시작 없이는 이 PID 1을 교체할 수도 없죠. PID 1이 종료된다면 커널은 시스템을 종료할 것입니다.
그런데, 사실 현대의 리눅스는 PID 1로 init이 아닌 systemd를 사용합니다. 자 한번 아래 명령어들을 따라서 입력하고 그 출력을 살펴보시죠.
$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 166424 11776 ? Ss 00:45 0:01 /sbin/init
root 2 0.0 0.0 0 0 ? S 00:45 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? I< 00:45 0:00 [rcu_gp]
root 4 0.0 0.0 0 0 ? I< 00:45 0:00 [rcu_par_gp]
root 5 0.0 0.0 0 0 ? I< 00:45 0:00 [slub_flushwq]
root 6 0.0 0.0 0 0 ? I< 00:45 0:00 [netns]
참고로 이번 포스팅에 사용되는 리눅스는 Ubuntu 22.04입니다. 어? 그런데 이상하죠? 방금 전에 제가 분명 PID 1은 init이 아닌 systemd를 사용한다고 했는데, 'ps aux' 명령어의 출력을 살펴보면 PID 1의 COMMAND가 init인 것을 알 수 있습니다. 이상하군요? 자 그럼... 다음 명령어를 한번 입력해 봅시다.
$ top
top - 16:22:33 up 15:37, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 212 total, 1 running, 211 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3911.9 total, 2196.0 free, 286.8 used, 1429.1 buff/cache
MiB Swap: 3911.0 total, 3911.0 free, 0.0 used. 3368.2 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 166424 11776 8404 S 0.0 0.3 0:01.79 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
'top' 명령어는 전반적은 시스템의 상태를 확인할 수 있는 명령어입니다. 오! 그런데 이번에는 PID 1번의 COMMAND가 systemd라고 표시되어 있습니다. 도대체 무엇이 진실일까요? 이를 알아보기 위해 다음 명령어를 입력해 봅시다.
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Nov 21 2023 /sbin/init -> /lib/systemd/systemd
네 맞습니다. 보시는 바와 같이 init은 심볼릭 링크이며 systemd를 가리키고 있음을 확인할 수 있습니다. 앞서 말씀드린 대로 현대 리눅스의 PID 1은 systemd가 차지하고 있습니다. systemd는 기존 init 시스템의 한계를 극복하기 위해 2010년에 개발된 새로운 init 시스템입니다. 다만, 기존 init 기반 스크립트와의 호환성 유지와 같은 측면에서 심볼릭 링크를 사용하는 형태를 하고 있었던 것입니다. 언젠가는 init과 systemd의 차이점을 다뤄보도록 하겠습니다.
마지막으로 명령어 'pstree -p'를 입력해서 출력되는 내용을 살펴보죠. 이 명령어는 프로세스 간의 계층 구조를 시각적으로 나타내줍니다.
$ pstree -p
systemd(1)─┬─ModemManager(830)─┬─{ModemManager}(832)
│ └─{ModemManager}(843)
├─VGAuthService(742)
├─agetty(1027)
├─containerd(796)─┬─{containerd}(833)
│ ├─{containerd}(834)
│ ├─{containerd}(835)
│ ├─{containerd}(836)
│ ├─{containerd}(840)
│ ├─{containerd}(860)
│ └─{containerd}(2478)
위와 같이 PID 1인 systemd를 시작으로 여러 프로세스가 계층적 구조를 이루고 있는 것을 알 수 있습니다. 여기서 systemd와 직접적으로 연결된 프로세스들은 모두 systemd의 자식 프로세스들이고, 당연히 systemd는 이들의 부모 프로세스가 됩니다.
containerd(796)을 봅시다. contianerd는 systemd의 자식 프로세스이기도 하면서, 그 아래 여러 {containerd}들의 부모 프로세스이기도 합니다. systemd(1)의 입장에서 {containerd} (833)와 같은 프로세스를 손자 프로세스라고 부르기도 합니다. 리눅스에서는 이렇게 프로세스들이 서로 계층적인 구조를 지니면서 작동하고 있습니다.
프로세스 생명 주기와 회수 책임
이제부터 본격적인 이야기를 하려고 합니다. 바로 프로세스 생명 주기와 회수 책임입니다. 아래 다이어그램을 한번 보도록 하겠습니다.
이는, 프로세스의 생명주기를 나타낸 것입니다. 프로세스의 생성, 실행, 그리고 종료 단계에서 일어나는 일들을 순차적으로 도식화한 것입니다. 한 가지 주목할 부분은 의외로 종료 단계에 많은 과정을 거친다는 점이죠. 특히 부모 프로세스는 자식 프로세스로부터 SIGCHLD 시그널을 전송받으면 wait() 시스템 콜을 통해 자식 프로세스의 종료에 대한 마지막 단계를 수행한다는 것입니다.
즉, 이 wait() 시스템 콜을 통해 자식 프로세스에 대한 회수 책임을 다 하고 있는 것이죠. 이는 단순히, 프로세스 생명 주기에서 수행되는 단계의 수준이 아니라 부모 - 자식 프로세스라는 계층적인 구조를 가진 리눅스 운영체제의 설계 원칙이라 할 수 있습니다.
그렇다면, 여기서 한 가지 질문을 해볼까요?
만약, 자식 프로세스가 종료되기 전 부모 프로세스가 먼저 종료된다면?
자식 프로세스에 대한 회수 책임을 가지고 있는 부모 프로세스가 사라졌습니다. 과연 이럴 때는 어떻게 될까요?
이에 대한 구체적인 이야기는 다음 시간에 마저 진행해 보겠습니다. 또한, 이러한 상황이 특히 컨테이너 환경에서는 어떤 영향을 미치는지에 대해서도 한번 알아보죠.
▼ Linux 프로세스 관리 - 좀비 프로세스에 관하여 [2편]
Linux 프로세스 관리 - 좀비 프로세스에 관하여 [2편]
이번 포스팅에서는 본격적으로 리눅스 좀비 프로세스에 대해서 이야기해보고자 합니다. 앞으로 논의할 내용을 이해하기 위해서는 리눅스 프로세스에 대한 기본적인 개념을 알아야 합니다. 이
tech-recipe.tistory.com
'System > OS' 카테고리의 다른 글
Linux 프로세스 관리 - 좀비 프로세스에 관하여 [3편] (1) | 2025.01.28 |
---|---|
Linux 프로세스 관리 - 좀비 프로세스에 관하여 [2편] (0) | 2025.01.28 |