뚝딱뚝딱 블로그
리눅스 스터디 #2 프로세스 관리 본문
프로세스 생성
새로운 프로세스를 생성하는 목적은 무엇일까?
- 목적 1. 동일한 프로그램 처리를 여러 프로세스에 나눠서 처리하기 ex) 웹서버에서 다수의 요청 받기
- 목적 2. 다른 프로그램을 생성하기 ex) bash에서 각종 프로그램을 새로 생성
프로세스 생성을 실제로 실행하는 방법으로 리눅스는 fork(), execve() 함수를 사용한다. 내부적으로는 각각 clone(), execve() 시스템 콜을 호출한다.
목적 1이라면 fork()만 사용, 목적 2라면 fork(), execve() 둘 다 사용한다.
같은 프로세스를 두 개를 분열시키는 fork() 함수
- 부모 프로세스가 fork() 함수 호출
- 커널이 부모 프로세스 메모리를 자식 프로세스 쪽에 복사
- 1) 부모 프로세스가 fork()에서 복귀
2) 자식 프로세스가 fork()에서 복귀
예제 코드
import os, sys
ret = os.fork()
if ret == 0:
print("자식 프로세스 : pid={}, 부모 프로세스 pid={}".format(os.getpid(), os.getppid()))
exit()
elif ret > 0:
print("부모 프로세스 : pid={}, 자식 프로세스 pid={}".format(os.getpid(), ret))
exit()
sys.exit(1)
- 예제코드를 실행한다면
- fork()를 호출해서, 프로세스 동작 흐름을 분기한다.
- 이후, 부모 프로세스는 자신의 프로세스 ID와, 자식 프로세스 ID를 출력하고 종료. 자식 프로세스는 자신의 pid를 출력하고 종료.
- fork() 함수에서 복귀할 때, 부모 프로세스라면 만들어진 자식 프로세스의 ID를 반환하고, 자식 프로세스(만들어진 프로세스)라면 0을 반환한다.
다른 프로그램을 기동하는 execve() 함수
fork()함수로 프로세스 메모리 복사본을 만들었으면, 자식 프로세스에서 execve() 함수를 호출하여 새로운 프로그램으로 바뀌게 된다.
- execve() 함수를 호출한다.
- execve() 함수 인수로 지정한 실행파일에서 프로그램을 읽어서, 메모리에 배치(메모리 맵에 배치)하는 데 필요한 정보를 가져옴
- 현재 프로세스의 메모리를 새로운 프로세스 데이터로 덮어 씀.
- 프로세스를 새로운 프로세스의 최초에 실행할 명령(entry point)부터 실행함.
디테일
- fork() 함수를 호출하여 copy된 메모리(현재 프로세스)에서 execve() 함수 호출
- 커널이 실행파일 읽어옴(ssd나 hdd 같은 저장장치)
- 커널이 프로세스 메모리를 치환(읽어온 실행파일, 현재프로세스 메모리에 치환)
- 새로운 프로세스 entry point부터 시작
import os, sys
ret = os.fork()
if ret == 0:
print("자식 프로세스 : pid={}, 부모 프로세스 pid={}".format(os.getpid(), os.getppid()))
os.execve("/bin/echo", ["echo", "pid={}에서 안녕".format(os.getpid())], {})
exit()
elif ret > 0:
print("부모 프로세스 : pid={}, 자식 프로세스 pid={}".format(os.getpid(), ret))
exit()
sys.exit(1)
- 실행결과는 다음과 같다.
- 부모 프로세스 ~ 출력
- 자식 프로세스 ~ 출력
- pid=xxx에서 안녕
execve() 함수가 동작하려면 실행 파일은 프로그램 코드와 데이터 이외에도 다음과 같은 데이터가 필요함.
- 코드 영역의 file offset, 크기 및 메모리 맵 시작 주소
- 데이터 영역의 file offset, 크기 및 메모리 맵 시작 주소
- 최초로 실행할 명령의 메모리 주소(entry point)
리눅스 실행 파일은 해당 정보를, Executable and Linking Format(ELF) 포맷으로부터 알 수 있음.
아래와 같은 pause.c 파일을 -no-pie 옵션으로 빌드해보자(옵션 의미는 메모리 보호기법 해제)
#include <unistd.h>
int main(void) {
pause();
return 0;
}
$ cc -o pause -no-pie pause.c
$ readelf -h pause
Entry point address: 0x400400 // 해당 값이 프로그램의 entry point가 된다.
...
$ readelf -S pause
There are 29 section headers, starting at offset 0x18e8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
...
[13] .text PROGBITS 0000000000400400 00000400
0000000000000172 00000000000 AX 0 0 16
// 즉 코드 크기 0x172, 코드 메모리 맵 시작 주소 0x400400, 코드 파일 오프셋 0x400
...
[23] .data PROGBITS 0000000000601020 00001020
0000000000000010 00000000000 WA 0 0 8
// data 크기 0x10, 데이터 메모리 맵 시작 주소 0x601020, 데이터 파일 오프셋 0x1020
entry point -> 0x400400
- 실행 파일은 여러 영역으로 나눠져 있고 각각을 section이라고 부른다.
- 섹션 정보는 두 줄이 한 묶음으로 표시 됨
- 숫자는 모두 16진수
- 섹션의 주요 정보는 다음과 같다.
- 섹션명: 첫 줄의 두번째 필드(Name)
- 메모리 맵 시작 주소: 첫 줄의 네 번째 필드(Address)
- 파일 오프셋: 첫 줄의 다섯 번째 필드(Offset)
- 크기: 두 번째 줄 첫 번째 필드(Size)
해당 프로세스를 실행시켜두고, cat /proc/<pid>/maps를 통해, 실제 프로그램의 메모리 맵을 볼 수 있다.
위에서 설명한 메모리 맵 범위안에 있는 것을 알 수 있을 것이다.
ASLR로 보안 강화
- Address Space LayOut Randomization이란, 프로그램을 실행할 때마다 각 섹션을 다른 주소에 매핑하는 것. 공격자가 주소를 추정하기 어렵게한다.
- 해당 기능을 이용하려면 다음 조건을 충족해야한다.
- 커널의 ASLR 기능이 유효해야 함.
- 프로그램이 ASLR에 대응해야한다. 대응하는 프로그램을 Position Independent Executable(PIE)라고 함.
- 우분투 20.04의 gcc 기준, 모든 프로그램을 PIE로 빌드하는데, 해당 옵션을 끈 것이 위의 예제에서 사용한 -no-pie인 것이다.
- PIE 지원여부는 file <프로그램> 명령어를 통해 알 수 있다.
$ file pause
pause: ELF 64-bit LSB shared object, ... // PIE 대응
pause: ELF 64-bit LSB executable, ... // PIE 아님
프로세스의 부모 자식 관계
부모의 프로세스, 프로세스...를 따라가다 보면 최종적으로 어떤 초기 프로세스에 도달하는 것일까?
우선 컴퓨터 전원을 켜먼 다음과 같은 순서로 시스템이 초기화가 되는 것을 염두해두자.
- 컴퓨터 전원, power를 켠다.
- BIOS나 UEFI 같은 펌웨어를 시작하고, 하드웨어를 초기화한다.
- 펌웨어가 GRUB 같은 부트 로더를 시작시켜준다.
- 부트로더가 OS 커널을 시작시킨다.(리눅스 커널)
- 리눅스 커널이 init 프로세스를 시작시킨다.
- init 프로세스가 자식 프로세스를 만들고, 그 자식 프로세스에서 또 자식 프로세스... 이어져서 프로세스 트리 구조를 만든다.
pstree 명령어를 사용하면 프로세스의 부모 자식 관계가 트리 구조로 표시된다. pstree -p를 사용하면 pid도 함께뜨게 된다. 모든 프로세스의 조상은 pid=1인 init 프로세스 즉, systemd 라는 것을 알 수 있다. bash에서 pstree를 실행한것도 알 수 있다.
참고) 어떤 프로세스에서 fork() execve() 함수를 순서대로 호출해서 사용할때, 유닉스 계통의 OS의 C 언어 인터페이스 규격인, POSIX에 정의된 posix_spawn() 함수를 사용하여 한꺼번에 간단히 처리할 수 있음
프로세스 상태 process state
시스템에서 동작하는 process를 시작한 시간 및 사용한 CPU 시간 합계는 START 필드와 TIME 필드에서 확인 가능하다.
보면 zsh은 CPU시간을 거의 사용하지 않았는데, 각 프로세스는 실행된 후 어떤 이벤트가 발생할때까지 CPU를 사용하지 않고, 가만히 있는 sleep 상태로 기다리고 있다. 특히 bash의 경우, 사용자의 입력이 있을때까지 할 일이 없기 때문에 사용자 입력을 기다리고 있을 것이다.
프로세스 상태는 ps 출력 결과에서 STAT 필드를 보면 알 수 있고, STAT 필드의 첫번째 글자가 S인 프로세스는 슬립 상태를 뜻한다.
한편, CPU를 사용하고 싶어하는 프로세스는 실행 가능(runnable) 상태라고 부른다. 이때 STAT의 첫 번째 글자는 R이 된다.
실제로 CPU를 사용하는 상태는 실행(running) 상태이다.
프로세스를 종료하면 좀비(zombie) 상태(STAT 필드가 Z)가 되고 조금 있다가 소멸한다.
프로세스는 위와 같이 종료될 때까지 다양한 state를 왔다갔다 한다. 시스템의 모든 프로세스가 sleep 상태이면 논리 CPU에서는 무슨일이 일어날까? 아이들 idle 프로세스라고 하는 '아무 일도 하지 않는' 특수한 프로세스를 동작시킨다. 해당 프로세스는 ps 명령어에서 보이지 않는다. 해당 동작은 논리 CPU를 휴식 상태로 전환하고, 하나 이상의 프로세스가 실행 가능 상태가 될때까지 소비 전력을 억제하면서 대기한다. 컴퓨터의 sleep 모드(절전모드)를 생각하면 된다.
프로세스 종료
프로세스를 종료하려면 exit_group() 시스템 콜을 호출한다. exit() 함수를 부르는 것이 내부적으로 해당 exit_group()을 호출한다. exit_group() 함수 내부에서 커널이 메모리 같은 프로세스가 사용한 자원을 회수한다.(아래 표 참고)
커널메모리 | 커널메모리 |
다른 프로세스용 메모리 | 다른 프로세스용 메모리 |
프로세스 메모리 | X(새롭게 비워진 메모리) |
비어 있는 메모리 | 비어 있는 메모리 |
프로세스가 종료하면 부모 프로세스는 wait()이나 waitpid() 같은 시스템 콜을 호출해서 다음과 같은 정보를 얻을 수 있다.
- 프로세스 반환 값. exit() 함수의 인수를 256으로 나눈 나머지와 같음. exit()인수에 0-255를 지정하면 인수가 값이 그대로 반환값이 된다.
- 시그널에 따라 종료했는지 여부
- 종료할 때까지 얼마나 CPU 시간을 사용했는지 정보
예를 들어 프로세스 반환값에 따라 프로세스 정상/비정상 종료 여부를 판정하여 에러 로그를 출력할 수 있다.
좀비 프로세스와 고아 프로세스
자식 프로세스가 종료되어도, 부모 프로세스가 wait() 계열 시스템 콜을 호출할때까지, 종료된 자식 프로세스는 시스템 내에 어떠한 형태로든 존재하게 될텐데, 이렇게 종료했지만 부모가 종료상태를 확인하지 않은 상태의 프로세스를 가리켜 좀비 프로세스(zombie process) 라고 부른다.
부모프로세스는 제때 자식 프로세스 종료 상태를 회수해서 남아 있는 자원을 커널로 돌려줘야 한다.
wait() 계열 시스템 콜 실행전에 부모 종료시, 자식 프로세스는 고아 프로세스(orphan process)가 된다.
그렇게 되면, 커널은 init을 고아 프로세스의 새로운 부모로 지정한다. 참고로 좀비 프로세스의 부모가 종료되면 init에 좀비 프로세스가 달려든다.
init은 정기적으로 wait() 계열 시스템 콜 실행을 호출해서 시스템 자원을 회수한다.
시그널 Signal
시그널이란? 어떤 프로세스가 다른 프로세스에 어떤 신호를 보내어 외부에서 실행 순서를 강제로 바꾸는 방법
주로 SIGINT를 자주 사용한다고 함. SIGINT는 bash같은 곳에서 Ctrl+C를 눌렀을 때 발생한다. SIGINT를 받은 프로세스는 곧바로 종료한는 것이 기본 값임.
해당 방법 이외에도 kill -INT <pid> 를 실행한다.
- SIGCHLD: 자식 프로세스 종료 시 부모 프로세스에 보내는 시그널. 보통은 signal handler 내부에서 wait() 계열 시스템 콜 실행을 호출함.
- SIGSTOP: 프로세스 실행을 일시정지함. 배쉬에서 Ctrl+Z를 누르면 실행중인 프로그램 동작을 정지시킬 수 있다.
- SIGCONT: SIGSTOP 등으로 정지한 프로세스 다시 재개
프로세스는 각 시그널에 Signal handler를 미리 등록해서, 프로세스가 실행되다가 해당하는 시그널을 수신하면 실행 중인 처리를 중단하고, 시그널 핸들러에 등록한 처리를 동작시킨 다음에, 원래 동작 분기로 돌아가서 이전에 하던 동작을 재개한다.
평소처리 | 동작(시그널 수신) | 동작(시그널 처리 후 복귀) | |
시그널 핸들러 | 시그널 처리 |
참고 * SIGKILL은 시그널 핸들러를 이용한 동작 변경이 불가능하고, 무조건 프로세스가 반드시 종료된다. 하지만 SIGKILL로도 죽지 않는다면 -> 네트워크나 디스크 자원 요청 대기 처럼, 오랫동안 시그널을 못받는 Uninterruptible sleep 상태에 들어가면 그럴 수도 있다. 이런 프로세스는 보통 STAT 필드 첫 글자가 D라고 한다. 아니면 커널에 문제가 생겨도 종료가 안 될 수 있다.
셸 작업 관리 구현
셸 작업 관리에 사용하는 세션(session)과 프로세스 그룹(process group) 개념을 설명하고자 한다.
작업(job)이라는 것은, bash같은 셸이 백그라운드로 실행한 프로세스를 제어하는 동작 구조이다.
세션
gterm 혹은 ssh 등을 사용해서 시스템에 로그인했을때의 로그인 세션에 대응하는 개념. 모든 세션에는 해당 세션을 제어하는 단말이 존재한다.
예를들어 아래와 같이 shell에서 프로그램을 동작시킨다고 가정하자. 아래의 예제처럼 가상 단말이 각각의 세션에 할당된다. 단말은 세션 내부 프로세스를 조작하거나, 프로세스에게 지시, 출력을 받는 등의 일을 할 수 있다.
세션 | 단말 | ||
A의 세션 | pty/0 | ||
bash | vim | go build | |
B의 세션 | pty/1 | ||
zsh | ps aux | less | |
B의 세션 2 | pty/2 | ||
zsh | calc(만든 프로그램) |
세션에는 세션 ID 또는 SID라고 부르는 값이 할당됨. 세션 리더라고 하는 프로세스가 존재한다.(보통은 bash같은 셸)
세션리더 pid는 세션 id와 같다.
$ ps ajx
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
...
19261 19262 19262 19262 pts/0 19647 Ss 1000 0:00 -bash
...
19262 19647 19647 19262 pts/0 19647 R+ 1000 0:00 ps ajx
보면, bash가 세션 리더인 세션 19262가 존재하고, ps ajx가 소속된 것을 알 수 있다. tty에도 가상 단말이 pts/0 라는 이름으로 할당되어있다.
세션에 할당된 단말이 hangup 하거나 연결이 끊어지면, 세션 리더에 SIGHUP 시그널이 날아간다. 이때 bash는 자신이 관리하던 작업을 종료하고 본인도 종료. 만약 실행이 오래걸리는 프로세스를 실행하다, bash가 종료되는것을 원치 않는 경우 아래와 같이 다루면 된다.
- nohup 명령어: SIGHUP을 무시하도록 설정하고 프로세스를 동작시킴.
- bash의 disdown 내장 명령어: 실행중인 작업을 bash 관리 대상에서 제외함. SIGHUP을 보내지 않게 됨.
프로세스 그룹
프로세스 그룹은 여러 프로세스를 하나로 묶어서 한꺼번에 관리한다. 세션 내부에는 여러개의 프로세스 그룹이 존재하는데, 기본적으로 셸이 만든 작업이 프로세스 그룹에 해당한다.
ex) bash 셸로 로그인하여, go build <소스코드> & 실행하고 ps aux | less 를 실행하는 경우.
이때 go build <소스코드> & 실행하고 ps aux | less 에 대응하는 2개의 프로세스 그룹이 작성된다.
세션 | 단말(포그라운드에서만 접근 가능) | |||
bash에서 오른쪽 프로세스들 생성 | 백그라운드 프로세스 그룹 | |||
go build | ||||
포그라운드 프로세스 그룹 | ||||
ps aux | -> | less |
프로세스 그룹을 사용하면 해당하는 프로세스 그룹에 소속된 모든 프로세스에 시그널을 보낼 수 있다.
프로세스 그룹은 두 종류로 나뉘는데,
- foreground 프로세스 그룹: 세션당 하나만 존재, 세션 단말에 직접 접근 가능(ps ajx 출력에서 STAT필드에 +가 붙으면 포그라운드 프로세스 그룹에 속한다)
- background 프로세스 그룹: 셸의 백그라운드 작업에 대응. 만약 백그라운드 프로세스가 단말을 조작하려고 하면, SIGSTOP을 받았을 때처럼 실행이 일시 중단되고, 프로세스가 foreground 작업이 될때까지 이 상태가 유지된다.(단말 직접 접근은 foreground가 되고난 이후에 가능)
데몬
상주하는 프로세스이며, 시스템 시작부터 종료할 때까지 계속해서 존재하며 실행된다.
- 단말의 입출력이 필요 없어서, 단말이 할당되지 않는다.
- 로그인 세션 종료해도 영향받지 않도록 독자적인 세션을 가진다.
- 데몬 종료 여부를 신경쓸 필요 없이, init이 부모가 된다.
세션 | 단말 | ||
데몬용 세션 | X(없음) | ||
데몬 프로세스 |
어떤 프로세스가 데몬인가?
PPID가 1이 될 것이고(init 프로세스), TTY값이 ?(단말과 연결되지 않았다는 뜻) 이거나.
SIGHUP을 단말의 hangup으로 쓰는데, 데몬은 단말과 연결되지 않았으니, 데몬이 설정파일을 다시읽는 시그널로 보통 사용한다고 함.
'Linux' 카테고리의 다른 글
리눅스 스터디 #4 메모리 관리 시스템 (0) | 2024.12.15 |
---|---|
리눅스 스터디 #3 프로세스 스케줄러 (2) | 2024.12.11 |
리눅스 스터디 #1 개요 (1) | 2024.12.01 |
Linux - Cache(ARM based) (0) | 2022.07.03 |
Linux - ARM AArch64 Exception Handling (0) | 2022.07.03 |