리눅스 부트 프로세스김영휘 이 문서는 전원을 켰을 때 부터 로그인 프롬프트가 화면에 나타날 때까지 리눅스에서 무슨 일이 벌어지는지에 대한 문서입니다. 되도록 자세하게 적으려고 노력하였으며, 부팅 과정에서 사용되는 스크립트에 대해서도 분석(?)하도록 노력하였습니다. 레드햇 기반의 배포판을 기준으로 잡아 설명했습니다. 다른 배포판(debian)의 경우는 필요할 경우 부연설명을 하겠습니다. 문서의 버그패치 환영합니다. 제발 버그패치해 주세요. ^^ 이 문서의 최신버젼은 http://lachesis.pe.kr/documents/bootprocess/ 에서 구할 수 있습니다. 한 페이지에 다 보기를 원한다면, http://lachesis.pe.kr/documents/bootprocess/bootprocess.html 을보세요. 출력할 때 편리합니다. sgml(docbook) 소스입니다 : http://lachesis.pe.kr/documents/bootprocess/bootprocess.sgml
1장. 전원을 넣는 순간으로부터 init 프로세스가 시작될 때까지1.1. lilo 로부터 커널 이미지 vmlinuz 의 로딩우리의 PC 의 전원을 켜면 PC 는 BIOS 에 저장되어 있는 초기화 프로그램을 실행합니다. 초기화 프로그램에 의해 메모리 체크 등이 수행되고 필요한 초기화가 완료되고 나면, 하드 디스크 혹은 다른 부팅 매체 (플로피 디스크나 CDROM 등)의 0 번 섹터의 부트 프로그램을 읽습니다. 보통, 0번 섹터를 MBR (Master Boot Record, 하드디스크의 경우. 플로피디스크의 경우는 부트섹터라고 합니다.) 이라고 합니다. 여기는 리눅스를 위한 lilo 나 grub 등이 들어 있을 수도 있고, NT 나 OS/2 등 다른 운영체제의 부트 로더가 들어 있을 수도 있습니다. lilo 가 MBR 에 있다고 가정하고 계속 진행하겠습니다. lilo 는 커널을 실행하기 위해서 사용자의 입력을 기다립니다. 여러분이 컴퓨터를 켰을때 나오는
라는 프롬프트가 그것입니다. 이때 우리는 lilo 라는 프롬프트 뒤에 커널에 주고싶은 옵션이나, 부팅하고자 하는 커널의 이미지를 지정해 줄 수 있습니다. 이에 관한 자세한 내용은 lilo HOWTO 문서를 참조하십시오. 이제, 사용자는 lilo 에 실행시키기를 원하는 커널의 이미지를 커널에 넘겨주고자 하는 옵션값과 함께 알려줍니다. 그리고, lilo 는 해당하는 커널의 이미지를 로딩해서 실행하게 됩니다. 기본 설정으로는 /vmlinuz 또는 /boot/vmlinuz 이미지가 메모리에 로드되고, 실행을 시작합니다. vmlinuz 는 리눅스 커널의 압축 이미지입니다. 여기서 swapper 라고도 불리우는 프로세스 id 0 인 프로세스가 실행됩니다. 이 프로세스는 운영체제 그 자체라고도 할 수 있는 프로세스로써, 메모리 관리, 디스크 관리, 프로세스 관리 등을 수행합니다. 이 프로세스는 프로세스 id 1 인 init 라는 프로세스를 실행시키고는 본연의 기능인 swapper 로써의 기능을 수행하기 시작합니다. [1] 1.2. process 0 : swapper여기서 swapper 가 무슨 일을 하는지 간단하게 이야기해 보겠습니다. [2] 유닉스 시스템에서 실행되는 모든 프로세스들은 "일생(lifetime)(?)"을 가지고 있습니다. 프로세스 생성에서부트 종료시까지... 그동안 cpu 를 점유하면서 실행되는 시간도 있을 것이고, 할 일 없이 사용자로부터의 입력을 기다린다든지의 이유로 "잠들어" 있는 시간도 있습니다. swapper 프로세스에 대해 설명하면서 이 이야기를 하는 이유는 swapper 가 하는 일이 바로, "잠들어" 있는 프로세스를 메모리에서 내려서 디스크 공간에 잠시 "스왑"시켰다가, 그 프로세스가 깨어나야만 할 시기가 오면, 디스크의 프로세스를 다시 메모리로 적재해 주는 등의 일을 하기 때문입니다. 예를 들어서, 지금 시스템에 너무 많은 프로세스가 실행되고 있어서 그넘들이 다 들어갈 만큼 메모리가 크지 않다고 가정합시다. 그럴때, 시간이 좀 많이 걸리는 I/O 요청을 한 프로세스라든지, 사용자의 입력을 기다리는 프로세스 라든지.. 지금 sleep 상태로 있는 프로세스 (예를 들면, httpd 같은건 대부분의 시간을.. - 그리 접속이 많지 않은 웹 서버라면 - port 에서 요청이 들어오길 기다리면서 잠들어 있는 (asleep) 상태이겠죠?) 와 같은 넘들은 지금 당장 메모리에 있을 필요가 없는 것입니다. 그러면, 지금 메모리가 모자라니까 디스크로 "스왑" 을 해서 당장 실행되어야 하는 프로세스를 위한 메모리 공간을 늘리면 되겠죠? 이때 swapper 가 작동을 해서 메모리에 있는 프로세스를 디스크로 잠시 옮겨 두는 (swap out) 것입니다. 또, swapper 는 반대로 디스크에 스왑되어 있는 프로세스가 메모리로 적재되어서 실행되어야 할 필요가 있을때에도 스왑된 프로세스를 메모리로 다시 올리는(swap in) 일을 하기도 합니다. 리눅스의 모든 프로세스는 모두 "부모" 프로세스를 가지고 있습니다. 즉, 그 프로세스를 생성시킨 넘이 존재한다는 얘기입니다. 그러나, 단 하나. pid 가 0 인 swapper 프로세스만은(이건 프로세스라기 보다는 운영체제 자체라고 해도 좋을 거 같습니다.) 부모가 존재하지 않고, lilo 등에 의해서 "수동"으로 실행이 됩니다. 나머지 프로세스는 모두 fork() 시스템 콜과 exec() 시스템 콜을 이용해서 생성이 됩니다. 또 여기서, fork() 시스템 콜과 exec() 시스템 콜에 대해 간단히 이야기하고 넘어가겠습니다. UNIX 시스템 프로그래밍을 공부해 보신 분들을 다 잘 아시는 내용일 것입니다. fork() 나 exec() 모두 한 프로세스가 다른 프로세스를 실행시키기 위해 사용하는 시스템 호출입니다. 두 함수의 차이점을 위주로 설명하면, 우선 fork() 시스템 호출은 새로운 프로세스를 위한 메모리를 할당합니다. 그리고, fork() 를 호출한 프로세스를 새로운 공간으로 싸그리 복사합니다. 그리고 나서 원래 프로세스는 원래 프로세스대로 실행되고, fork() 를 이용해서 생성된 프로세스도 그 나름대로 fork() 시스템 콜이 수행된 라인의 다음 라인부터 실행이 됩니다. (새로 생성된 프로세스는 원래의 프로세스랑 똑같은 코드를가지고 있습니다.) 반면, exec() 시스템 콜은 fork() 처럼 새로운 프로세스를 위한 메모리를 할당하지 않고, exec() 를 호출한 프로세스의 메모리에 새로운 프로세스의 코드를 덮어씌워 버립니다. 따라서 exec() 를 호출한 프로세스가 아닌 exec() 에 의해 호출된 프로세스만 메모리에 남게 됩니다. 다시 간단하게 말하면, fork() 의 결과는 프로세스가 하나 더 생기는 것입니다. 물론, 프로세스 id (pid) 도 완전히 다른 또 하나의 프로세스가 생기는 것이죠. 반면, exec() 실행의 결과로 생성되는 새로운 프로세스는 없습니다. exec() 를 호출한 프로세스의 pid 가 그대로 새로운 프로세스에 적용이 되며, exec() 를 호출한 프로세스는 새로운 프로세스에 의해 덮어쓰여지게 됩니다. 2장. init 프로세스와 inittab 파일2.1. init 프로세스와 inittab 파일프로세스 id 1 번인 init 프로세스는 사용자들을 위해서 시스템을 설정하게 됩니다. pid 0 인 프로세스가 초기화(?)한 커널의 바탕에서 나머지 작업을 수행하는 것이죠. init 프로세스(/sbin/init) 가 하는일의 대충은 다음과 같습니다 :
init 가 처음 시작해서 수행해야 할 작업들을 설정한 파일은 /etc/inittab 파일 입니다. init 는 새로운 실행레벨에서 실행할 프로세스를 결정하기 위해서 이 파일을 참조합니다. 다시 말하면, inittab 파일은 시스템의 상태에 따라서 해당하는 런레벨에서 init 프로세스가 수행해야 할 일들을 서술해 놓은 파일입니다. init 프로그램은 inittab 파일을 참조하여서 모든 새로운 런레벨에서 실행할 수 없는 프로세스가 만약 지금 실행중이면, 그 프로세스를 죽이고, 새로운 런레벨 에서 실행해야만 하는 프로세스 중 현재 실행되고 있지 않은 프로세스는 새로이 실행을 시킵니다. 2.2. /etc/inittab 파일의 예아래에 예시한 것은 제 컴퓨터에 있는 inittab 파일입니다. (좀 허접하기 때문에 이해해 주시기 바랍니다. 단지 예시용으로 인용하였습니다. -_-;)
2.3. runlevel그럼 이제, inittab 파일을 한줄한줄 분석해 보겠습니다. # 으로 시작하는 줄은 주석이라는거 다 알고 계실 겁니다. inittab 파일의 용도와 저자가 나오고, 각 런레벨(ren level) 에 대한 간략한 정의(?)가 나옵니다. [4]
의 라인을 혹은 등으로 지정해 버리면, 여러분의 리눅스 시스템은 부팅하자마자 종료되어 버리거나, 재시작을 거듭 반복하게 되어 버리므로 주의하시기 바랍니다. 그럴때에는 부팅시 lilo 에 옵션을 주어서 0이나 6 이외의 런레벨로 부팅해서 고쳐 주시면 됩니다. 잠깐! 런레벨이란 무엇인가... 하고 생각하시는 분들이 있을 겁니다. 아마, 여기까지 읽으셨다면, 대충 짐작은 하고 계시리라 생각합니다.
시스템을 관리하다 보면, 시스템의 점검 혹은 디버깅을 위해서 보통때의 설정 과는 좀 다르게 몇가지 서비스를 시작하지 않고 부팅하고 싶은 경우가 있을 것입니다. 예를 들어서, 네트워크 지원 기능을 off 하고서 부팅하고 싶다든지, 다중 사용자 모드가 아니라 싱글 사용자 모드로 부팅하고 싶다든지 하는 경우가 생길 수 있습니다. 이처럼 서로 다른 설정으로 부팅하기 위해서 각각의 설정을 "런레벨" 이라는 이름으로 나누어 놓은 것입니다. 그리고, "런레벨" 에 대한 약속으로 0, 1, 2, 3, 5, 6 번 런레벨 [8] 은 미리 예약되어서 "시스템 종료, 재부팅, 싱글유저모드, 다중사용자 모드, 네트워크가 지원되지 않는 다중 사용자 모드 등으로 하자" 라고 약속을 해 둔 것입니다. (사실 예약된 런레벨은 0, 1, 6 밖에 없습니다. 하지만 나머지 2, 3, 5 번은 "관례상" 각각의 해당 용도로 사용하고 있는 것 같습니다. 런레벨 2, 3 은 SunOS 등 다른 System V 계열의 init 프로세스를 쓰는 운영체제에서도 리눅스와 동일하게 사용하고 있습니다.) 그 외에 7, 8, 9번 런레벨도 사용자가 정의해서 쓸 수 있지만, 관례상 그렇게 하지 않는다고 합니다. 그리고, S 와 s 런레벨도 특수한 런레벨로써 존재합니다. 만약 여러분이 시스템 종료시에 디폴트로 제공되는 일에 더해서 실행시키고 싶은 것이 있다면, 런레벨 0 에 추가를 하시면 되는 것입니다. 이렇게 각각의 런레벨에 원하는 작업을 추가하기 위해서는 /etc/rc.d/rcN.d [9] 디렉토리 아래의 심볼릭 링크들을 조정하시면 됩니다. 자세한 내용은 이 문서 4절에 적어 두었습니다. 2.4. man inittab이제 inittab 파일의 형식을 살펴 보도록 하겠습니다. 자세히 inittab 파일을 보신 분이라면 모든 줄이 다음과 같은 형식으로 되어 있다는 것을 아셨을 겁니다.
제일 처음에 나오는 id 는 해당 state를 구분하기 위한 레이블이라고 보시면 됩니다. 그리고, 그 다음의 rul-levels 는 그 줄의 내용을 적용하기 위한 런 레벨의 목록입니다. 그리고, action 은 그 줄(엔트리라고 하겠습니다.), 엔트리에 의해 실행되는 프로세스를 어떻게 할 것인가에 대한 설명입니다. 마지막으로 나오는 process 는 프로세스의 실행파일의 경로와 프로세스에 넘겨줄 인수입니다. (쉘에서 실행시키는 명령어와 같은 형식이라고 생각하세요, 즉, 해당 엔트리를 실행할 때 process 부분에 나오는 명령어로 실행하라는 뜻입니다. -_-;) action 부분에 올 수 있는 키워드는 다음과 같습니다. (맨페이지에서 참조한 내용입니다.)
2.5. /etc/inittab 의 분석아마 앞절의 내용만 보셔도 자신의 inittab 파일의 대부분은 이해하실 수 있을 겁니다. 이제, 쓸데없을지도 모르지만, 제 inittab 파일을 한줄씩 분석해 보겠습니다.
이 줄은 디폴트 런레벨을 3으로 지정하는 줄입니다. initdefault 키워드 뒤에는 process 필드가 무시된다고 윗부분에서 설명되어 있지요? ^^; 이 줄에 의해서 부팅한 후에 런레벨 3 으로 커널의 런레벨이 조정됩니다. 만약, 처음에 리눅스를 부팅하면, 바로 X 로 들어가시는 분이라면 이부분이 다음과 같이 되어 있을 겁니다.
런레벨 5에 대한 설명을 inittab 파일에서 보십시오. X11 이라고 되어 있지요? 그러면, 그 다음줄입니다.
이 라인에는 sysinit 라는 키워드가 action 필드에 지정되었습니다. action 필드에 지정할 수 있는 키워드 중 sysinit 를 찾아보면, 프로세스가 시스템 부팅시에 실행되며, 런레벨은 무시한다는 내용과, 다른 boot 나 bootwait 가 action 필드에 지정된 프로세스들보다 먼저 실행된다는 내용이 있습니다. 즉, 제일 처음 init 프로세스가 실행시키는 명령입니다. 정확히 말하면, start-up 스크립트라고 할 수 있습니다. process 필드에 /etc/rc.d/rc.sysinit 라고 명시되어 있습니다. 다시한번 단순화시켜서 이야기하면, 위에 예시한 inittab 파일을 사용하는 제 리눅스 박스는 전원을 올리면, /etc/rc.d/rc.sysinit [12] 가 실행된다는 것입니다. rc.sysinit 의 내용은 나중에 살펴보기로 하고, 다음줄로 진행하겠습니다.
보시고, 짐작하신 바와 같이 각 런레벨별로 지정된 시작 스크립트들입니다. /etc/rc.d/rc 스크립트에 해당 런레벨을 인수로 넘겨주는군요. /etc/rc.d/rc 스크립트의 내용은 나중에 하나씩 분석해 보겠습니다. 각 런레벨 별로 지정된 스크립트는 그 실행이 종료될 때까지 init 프로세스가 진행하지 않고, 기다리라는 의미의 wait 키워드를 action 필드에 지정해 두었군요.
그 다음줄에는 action 필드에 once 키워드가 쓰였습니다. 그래서 각 런레벨별로 한번씩만 실행되는 프로세스입니다. /sbin/update 를 실행하는군요. /sbin/update 는 bdflush 라는 커널 데몬(커널 스레드)을 실행시킵니다. 이 데몬은 버퍼를 갱신한다든지 하는 일을 합니다. 자세한 내용은 man update 를 해 보시면 알 수 있습니다.
그 다음으로 나오는 것은 사용자가 콘솔에서 CTRL-ALT-DEL 키의 조합을 눌려서 싱글 유저모드로 들어가거나 혹은 시스템을 셧다운 하려고 할 때 불려지는 프로세스를 정의합니다. /sbin/shutdown -t3 -r now 로 정의했군요. 3초 후에 재부팅하게 됩니다. shutdown 이 재부팅을 수행하기 위해서는 init 프로세스에게 런레벨을 바꾸도록 하라는 시그널을 보내게 됩니다. 런레벨 0은 시스템 halt 에 사용되고, 런레벨 6은 재시작, 1은 싱글유저 모드에 사용됩니다. 재미있는 것으로, 사용자가 (root 사용자일 경우) init 프로세스에게 구체적으로 어떤 런레벨에서 init 를 수행시킬지 커맨드라인에서 명시해 줄 수 있습니다.
이라고 명령을 내리면, N 에 명시된 실행레벨로 init 가 진입하게 됩니다.
이라고 하면, init 는 런레벨 6 으로 진입하게 되면서 시스템은 재부팅 되게 됩니다. 다른 System V 계열의 운영체제에서는 이러한 경우를 위해서 특별히 telinit 라는 명령어도 준비해 놓고 있습니다. (리눅스도 마찬가지입니다.)
다음 두줄은 전원에 관계된 것으로, UPS 를 사용하는 분들에게만 해당되는거 같군요.
그리고, 거의 마지막 부분에 붙어 있는 여섯줄, 이 줄은 각 런레벨 2,3,4,5 일 때 실행되는 것으로써, 콘솔을 열고, 응답을 기다리는 부분입니다. 앞서의 모든 초기화 과정이 끝나고 마지막으로 실행되는 부분이죠. 컴을 켰을 때 바로 X 가 시작되는 분들은
등과 같이 런레벨 5에만 해당되는 로그온 프로세스가 명시되어 있을 겁니다. 3장. init : 그 이후앞 절에서 설명한 바와 같이 init 프로세스가 자신에게 할당된 초기화 과정을 모두 끝마치고 나면, inittab 파일의 맨 끝부분에 명시된 것처럼 mingetty 혹은 getty 프로세스를 실행시킵니다. 실행시키는 방법은 최초에 pid 0 의 프로세스 [13] 에 의해 실행된 init 가 fork() 시스템 콜을 한번 수행하고, 그에 의해 생성된 자식 init 가 exec() 시스템 콜을 이용해서 getty 혹은 mingetty 등의 프로세스를 수행하게 됩니다. 프롬프트를 띄우고서 사용자의 userid 가 입력되기를 기다리는 일입니다. 사용자가 자신의 userid 를 입력하고서 엔터키를 치게 되면, getty 는 /bin/login 을 실행시키게 됩니다. 라는 프롬프트를 띄우고, 사용자가 password 를 입력하기를 기다립니다. 사용자가 암호를 입력하면, /etc/passwd 혹은 /etc/shadow 파일로부터 패스워드를 읽어서 암호화 한 패스워드와 일치하는지를 검사합니다. 만약 패스워드가 일치하지 않으면, login 프로그램은 에러를 내고 종료합니다. 그러면, init 프로세스는 다시 자신을 fork() 하고, /sbin/getty 프로그램을 exec() 해서 화면에 로그인 프롬프트를 출력하도록 하고 사용자의 입력을 기다리게 됩니다. 만약 패스워드가 일치하면, login 프로그램은 홈디렉토리를 바꾸는 등 여러가지 작업을 하고, 최종적으로 exec()를 하여, 로그인 쉘 [14] 을 띄우게 됩니다. 그러면, 사용자는 자신의 쉘 (주로 bash) 로 작업을 하고, 쉘에서 입력하는 명령어들은 먼저 쉘이 fork() 를 한 후 쉘의 자식프로세스가 exec() 를 하여 실행되고, 종료하는 것입니다. 이 과정을 간단하게 그림으로 그리면 다음과 같습니다.
4장. /etc/rc.d/rc.sysinit, /etc/rc.d/rcrc.sysinit 스크립트는 살펴본 결과 크게 특이할 것은 없는 것 같습니다. 하는 일들은 레드햇 기반 배포본을 모델로 설명하겠습니다. [15] 이 파일은 inittab 의 정의에 따라, 시스템 초기화시 맨 먼저 딱 한 번 실행되는 초기화 스크립트입니다.
의 일을 수행합니다. 자세한 것은 rc.sysinit 파일을 찬찬히 읽어 보면 알 수 있습니다. 정작, 우리가 주의를 기울일 초기화 스크립트는 각종 데몬들을 실행시키고, 죽이는데 사용되는 /etc/rc.d/rc 스크립트입니다. 이 스크립트는 인수로 실행 레벨을 받습니다.(-_-; 표현이 좀 매끄럽지 못하군요) 즉,
과 같은 형식으로 실행시킵니다. n 에는 실행레벨이 들어갑니다. 좀 더 나은 이해를 위해서 다음의 명령을 실행시켜 보십시오.
실행 결과로 /etc/rc.d 디렉토리의 내용이 나오는데, 그 중에 다음과 같은 디렉토리들이 있습니다.
각각의 디렉토리는 rc런레벨.d 로 이름이 지어져 있습니다. 각 디렉토리 아래에는 해당 런레벨에서 실행할 서비스나 프로세스들이 정의되어 있습니다. 한 디렉토리를 정해서 어떤 파일들이 있는지 살펴보겠습니다.
보시는 바와 같이 S 로 시작하는 파일들과, K 로 시작하는 파일들이 주욱~ 있는데, 거의 /etc/rc.d/init.d 아래의 파일들에 링크가 되어 있습니다. 이처럼, rcN.d 디렉토리의 모든 파일들은 오로지 링크로만 되어 있으며, 실제 서비스를 시작하거나 종료하는 스크립트는 /etc/rc.d/init.d 디렉토리 아래에 존재합니다. S 로 시작하는 파일은 해당 서비스를 실행시키는데 사용되고, (Start) K 로 시작하는 파일은 해당 서비스를 죽이는데 사용됩니다.(Kill) 제 컴퓨터에서는 디폴트 런레벨인 3 에서 network, syslog, inet, named, sendmail, mysql, smb 등을 실행하도록 구성해 두었습니다. (아파치와 proftpd도 실행이 되는데, 일일이 링크 걸기가 귀찮(^^;)아서 S99local 이 가리키는 /etc/rc.d/rc.local 안에 시작 스크립트를 적어 두었습니다.) 그럼 재미삼아서, /etc/rc.d/rc0.d 디렉토리의 내용도 살펴 보겠습니다.
예상했던 대로 거의 모두가 K 로 시작하는 링크만 존재합니다. 단 하나 S 로 시작하는 링크는 halt 입니다. 시스템 종료를 하는 스크립트에 링크가 걸려 있습니다. 이제, 이렇게 실행레벨 별로 적절한 디렉토리를 찾아서 그 디렉토리 아래의 링크가 가리키는 스크립트들을 실행시키는 스크립트인 /etc/rc.d/rc 를 살펴보겠습니다. 아래에 제 컴퓨터의 /etc/rc.d/rc 파일의 일부를 발췌해 보았습니다. 레드햇 인스톨한 후에 하나도 바꾸지 않았습니다. (^^;)
세부적인 내용은 스크립트를 차분히 분석해 보시면 아실 수 있을 것입니다. 여기서 중요한 것은, 자신이 부팅시에 실행시키기를 원하는 데몬을 지정할 수 있다는 것입니다. rc 스크립트에 보면, rc 에 인수로 건네진 런레벨의 숫자를 보고, 해당하는 디렉토리에서 K 로 시작하거나, S 로 시작하는 모든 파일을 찾아서 죽이거나 실행시킵니다.
과
부분이 그 일을 하게 됩니다. 우리가 다중 사용자 모드로 부팅했을 때, 즉, 컴퓨터를 켰을 때 자동으로 실행시키고자 하는 데몬 중에, 예를들어, httpd 가 있다고 가정하면, httpd 가 컴을 켰을 때 자동으로 실행되게 하기 위해서 /etc/rc.d/rc3.d 디렉토리 아래에 SNNhttpd 라는 파일과 KNNhttpd 파일을 심볼릭 링크로 httpd 혹은 apachectl 에 링크시켜 주면 되는 것입니다. 그러면, 부팅시에 런레벨 3으로 진입하면서, /etc/rc.d/rc3.d 디렉토리의 S* 파일들을 실행하게 되고, (S 뒤에 번호가 있는데 그 순서로 실행됩니다.) 우리가 만든 SNNhttpd 링크도 실행하게 됩니다. (여기서 NN 은 적절한 번호입니다. 네트워크가 활성화 된 후에 apache 데몬이 실행되어야 하는것을 고려해 적절하게 번호를 할당해 주시면 됩니다. 참고할 부분은, 해당 프로세스를 실행시키거나 종료시키는 스크립트는 반드시, 항상, 인수로 start 혹은 stop 이라는 것을 넘겨 받도록 작성해야 한다는 것입니다. 만약 여러분이 해당 프로세스를 실행 혹은 종료시키는 스크립트를 직접 만들기를 원하신다면, 다음과 같은 코드가 반드시 포함되어서 /etc/rc.d/rc 스크립트에서 실행할 수 있도록 작성을 하셔야 합니다. 그리고, 시스템 관리상, 일관성 있게, 그 스크립트는 /etc/rc.d/init.d 에 넣어 주시는것이 보기에 좋을 것 같습니다.
이게 좀 복잡하다고 느끼시는 분들은 /etc/rc.d/rc.local 스크립트가 있는데, 이 스크립트 마지막 부분에 실행시키기를 원하는 데몬을 실행하는 코드를 넣어 주시면 됩니다. 단, rc.local 스크립트는 실행레벨 2, 3, 5 일 때만 실행되도록 설정되어 있습니다. rc.local 스크립트는 rcN.d 디렉토리에서 S99local 이라는 이름으로 링크되어 실행됩니다. S99local 이라는 파일이 rc2.d rc3.d rc5.d 에만 있죠? 5장. 꼬릿말여러가지로 부족한 문서이지만, 나름대로 리눅스의 부트 프로세스에 대해 알고 있는 내용들을 정리해 보았습니다. 제가 처음 리눅스를 공부할 때 이에 관한 자료가 없어서 여기저기 삽질하면서 고생한 것이 생각나는군요 T_T 부디 초보자(나도 아직 초보를 못벗어난거 같지만 -_-;)님들이 이 문서를 보고 자신의 리눅스 시스템 설정을 바꾸는 일을 좀 더 수월하게 느꼈으면 좋겠습니다. 이 문서가 다른 많은 문서들 사이에서 쓸데없는(!) 문서 하나를 더하는 꼴이 되어서 자료를 찾으시는 분들께 혼란을 끼치게 되지나 않을까 하는 걱정도 있지만.. ^^; 감히 이렇게 kldp 에 제 저작물을 올려 봅니다. 읽으시는 분들의 따끔한 지적을 기다리겠습니다. - 2000. 8 애초에 계획한 것은 데비안의 경우를 모두다 포함시키는 것이었는데, 하다보니 게으름이 나는군요. 헤헤... 원리는 같기 때문에 조금만 삽질을 해 보시면 데비안에서도 무난히 적용할 수 있을 것입니다. - 2001. 7 참고문헌주석
|
When the wind is great, bow before it; when the wind is heavy, yield to it.    
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
