Chapter 7. init

Table of Contents
init가 먼저 나타난다
getty를 실행하기 위한 init 설정: /etc/inittab 파일
실행 레벨
/etc/inittab에서의 특수 설정
단일 사용자 모드에서의 부팅

"Uuno on numero yksi" (Slogan for a series of Finnish movies.)

"뭐든지 첫번째에 달려 있다" (핀란드의 한 영화 시리즈 슬로건)

여기서는 커널에 의해 실행되는 첫번째 프로세스인 init에 대해 다룬다. init는 여러가지로 중요한 역할을 하는데, getty를 띄운다거나(사용자들이 로그인 할 수 있게 해준다), 실행 레벨을 구현하고, 고아가 된 프로세스들을 돌봐주는 등의 일이 모두 init 몫이다. 이제 init가 어떻게 설정되며, 다른 실행 레벨로는 어떻게 전환시킬 수 있는지 알아보자.

init가 먼저 나타난다

init는 리눅스 시스템의 작동에 있어서 절대적으로 필수적인 프로그램이지만, 그럼에도 흔히 init에 대해 무지한 경우가 많다. 아마 좋은 리눅스 배포본이라면 init가 대부분의 시스템에서 잘 돌아가도록 설정되어 있을 것이고, 따라서 init에 대해선 별로 신경쓸 필요가 없었을 것이다. 다만, 시리얼 터미널들이나 다이얼-인 모뎀(다이얼-아웃은 아님)들을 연결해야하는 경우, 또는 기본 설정된 실행 레벨을 전환시켜야하는 경우에는 init를 주의깊게 살펴보아야 한다.

커널이 자신의 부팅을 진행할 때(즉, 자기 자신을 메모리에 올리고, 그것을 실행시키고, 장치 드라이버들과 데이터 스트럭쳐들을 초기화시키는 등의 일을 진행할 때), 부트 프로세스로서 커널이 마지막으로 해야할 일은 init를 실행시키는 것이다. 즉, 사용자 레벨의 프로세스인 init를 실행시킴으로 해서, 커널은 부트 프로세스로서의 역할을 마치게 된다. 그래서, init는 언제나 첫번째 프로세스가 되는 것이다(따라서, init의 프로세스 번호도 언제나 1이 된다).

커널은 우선 init가 어디 있는지 찾아본다. 역사적으로 init가 있었던 장소는 몇군데 되지만, 리눅스 시스템에서의 적절한 장소는 /sbin/init이다. 만일 커널이 init를 찾지 못한다면, /bin/sh를 실행시키려 하는데, 이마저도 찾지 못한다면 시스템의 시동은 실패하고 만다.

init가 실행되면, 몇가지 관리 작업을 처리하고 부트 프로세스를 마치게 된다. 즉, 파일시스템을 검사하고, /tmp를 청소하며. 그 밖에 다양한 서비스들을 시작시킨다. 또한 getty를 각각의 터미널과 가상 콘솔에 띄워서 사용자들이 로그인 할 수 있도록 한다(Chapter 8 참조).

부팅이 되어 시스템이 정상적으로 가동되면, init는 사용자들이 로그 아웃한 터미널에 다른 사용자들이 다시 로그인 할 수 있도록 getty를 재실행시킨다. 또한 init는 고아 프로세스들을 거두어 양자로 삼는다. 즉, 한 프로세스가 자식 프로세스를 생성하고서 자식 프로세스보다 먼저 죽어 버렸을 경우, 그 자식 프로세스는 즉시 init의 자식 프로세스가 되는 것이다. 이것은 여러가지 기술적 이유로 해서 무척 중요한데, 간단하게 말하자면 모든 프로세스의 리스트와 그 트리 구조를 알기 쉽게 유지하기 위해서라고 할 수 있다. [1] init에는 몇가지 종류가 있는데, 대부분의 리눅스 배포본들은 System V init 디자인에 기반한 sysvinit(Miquel van Smoorenburg이 만듦)를 사용한다. 반면에 BSD 버전의 유닉스들은 다른 init를 사용하는데, 이 둘간의 가장 큰 차이점은 실행 레벨의 유무에 있다. 즉, System V는 실행 레벨이란 개념이 있지만, BSD는 이런 개념이 없다(최소한 전통적으로는 없다). 그러나 이런 차이점은 별로 본질적인 것은 아니다. 여기서는 sysvinit에 대해서만 살펴보기로 하겠다.

Notes

[1]

init 자신은 죽음이 허락되지 않는다. 심지어 init에 SIGKILL 시그널을 보낸다하더라도 그것을 죽일 수는 없다.