시스템을 부팅할때, 둥둥 떠다니는 많은 글자들을 보실 것입니다. 만약 이걸 가까이 주의를 기울여보시면, 이 글들이 항상 독자여러분의 시스템을 재부팅할때 나타나는 것과 같음을 보실 것입니다. 이들동작의 반복은 부트 시퀀스라고 불리우며, (이보다 더 혹은 덜) 정적으로 정의되어 있습니다.

먼저, 부트로더는 CPU더러 커널을 실행하라고 하기 전에 부트로더에 정의된 환경설정에 정의된 커널이미를 메모리로 로드할 것입니다. 커널이 로드되고 실행할때는 커널 특유의 구조와 작업들을 초기화 하고 init 프로세스를 시작합니다.

그리고 난 프로세스는 (/etc/fstab에 정의된)모든 파일 시스템이 사용할 수 있게 마운트 하고 준비되었는지를 확인합니다. 다음 독자여러분이 성공적으로 시스템 부팅을 수행하기 위해 필요로 하는 서비스들을 시작하는, /etc/init.d에 위치한 각각의 스크립트를 실행할것입니다.

최종적으로 모든 스크립트가 실행되면 init 는 agetty라고 불리우는 특별한 프로세스가 붙은 터미널(대부분의 경우 Alt-F1,F2 키에 숨겨진 가상 콘솔입니다)을 시스템 상에 활성화 합니다. 이 프로세스는 로그인을 실행함으로서 이들 터미널들을 통해 로그 온 할 수 있게 확인할 것입니다.

자.. init는 /etc/init.d의 스크립트로서 무작위로 실행되는 것만이 아닙니다. 심지어 /etc/init.d에 있는 모든 스크립트를 실행할수도 없으며, 단지 실행하라고 지시한 스크립트만 실행하는 것도 아닙니다. /etc/runlevels를 찾아서 어떤 스크립트를 실행할지를 결정하는 것입니다.

먼저, init는 /etc/runlevels/boot에 있는 심볼릭 링크가 담긴 /etc/init.d로부터 모든 스크립트를 실행합니다. 종종 스크립드들이 알파벳 순으로 시작하겠지만, 어떤 스크립트의 경우 그들에 있는 의존정보를 포함하고 있어 다른 스크립트가 그것들이 시작되기 전에 반드시 실행되어야 한다는것을 시스템에 알립니다.

모든 /etc/runlevels/boot 의 참조된 스크립트가 실행되었을때, init 는 /etc/runlevels/default의 심볼릭 링크된 스크립트를 계속 실행합니다. 다시 말하자면, 유효한 시작 시퀀스를 제공하기 위해 순서가 바뀐 경우 이에 대한 의존정보를 포함하는 스크립트가 있기 전에는, 어떤 순서로 실행하든지간에 알파벳 순서를 사용합니다.

물론 init 자신이 모든 것을 결정하는 것은 아닙니다. 어떤 동작을 취할 필요가 있는지 정의한 환경설정파일이 필요합니다. 그 파일이 /etc/inittab 입니다.

우리가 그냥 설명한 부트 시퀀스를 기억한다면 init의 첫번째 동작은 모든 파일 시스템을 마운트하는것임을 기억할것입니다. 이는 /etc/inittab의 다음 줄에 정의되어 있습니다.

예제 1-1: /etc/inittab에서의 시스템 초기화 줄

si::sysinit:/sbin/rc sysinit

이 줄은 init가 /sbin/rc sysinit을 실행하여 시스템을 초기화 해야 함을 말하고 있습니다. /sbin/rc 스크립트는 초기화를 다룹니다. 그래서 init가 더 이상 할 수 없는 것 -- 이는 다른 프로세스에게 시스템의 초기화 작업을 위임한다는 것입니다. -- 을 말할 것입니다.

두번째로, init는 /etc/runlevels/boot에 있는 심볼릭 링크에 딸린 모든 스크립트를 실행합니다. 이는 다음줄에 정의되어 있습니다.

예제 1-2: 계속되는 시스템 초기화

rc::bootwait:/sbin/rc boot

다시 말하지만 rc 스크립트는 필요한 작업을 수행합니다. 유의해야 할 점은 rc (boot)에 주어진 선택사항은 사용되는 /etc/runlevels의 하위디렉토리와 유사합니다.

이제 init는 런레벨이 실행해야 할 것을 찾기 위해 환경설정 파일을 점검합니다. 이것이 결정되면 /etc/inittab에서 다음 줄을 읽어들입니다.

예제 1-3: initdefault 줄

id:3:initdefault:

이 경우 (젠투 사용자들이 사용할 대부분), 실행단계 아이디는 3입니다. 이 정보를 사용하여 init는 어떤 것이 실행단계 3에서 실행해야 하는지를 점검합니다.

예제 1-4: 실행단계 정의

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

단계 3을 정의한 줄에서 rc스크립트가 (이제 default 변수와 함께)서비스를 시작하도록 합니다. 다시 말해서 rc의 변수는 /etc/runlevels의 하위디렉토리와 같습니다.

rc 동작이 끝났을때, init는 어떤 가상 콘솔이 활성화되고 어떤 명령이 각각의 콘솔에서 실행될 필요가 있는지를 결정합니다.

예제 1-5 : 가상 콘솔 정의

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

독자여러분은 init가 번호조직을 어떤 실행단계가 활성화 될지를 결정하는데 사용한다는걸 봤습니다. 실행단계는 시스템이 실행하는것이 어떤지에 대한 상태이며 실행단계를 진입할때 혹은 벗어났을때 실행해야하는것이 무엇인지에 대한 스크립트 모음(실행단계 스크립트 혹은 initscript)을 포함하고 있습니다.

젠투에서는 7가지 실행단계가 정의되어 있습니다 세개의 내부적 실행단계와 네개의 사용자 정의된 실행단계가 그것입니다. 내부적 실행단계는 sysinit으로 불리우며, 종료하고 재시작하며 그들의 이름이 함축하는 바를 정확하게 수행합니다. 시스템을 초기화하고 시스템을 종료하여 전원을 차단하며 시스템을 재부팅합니다.

사용자 정의된 실행단계는 /etc/runlevels 하위디렉토리에 있는 것들로, boot, default, nonetwork, single이 그것입니다. boot 실행단계에서는 다른레벨들 모두가 사용하는 시스템에서 필요로 하는 모든 서비스를 시작합니다. 남은 세가지 실행단계에선 어떤 서비스를 시작하느냐에 따라 구분됩니다. default는 매일 수행하기 위해 사용되고, nonetwork 네트워크 연결이 안될때 요구되며, single은 시스템을 복구할 필요가 있을때 사용합니다.

rc 프로세스가 시작하는 스크립트를 init 스크립트라고 합니다. /etc/init.d에 있는 각각의 스크립트는 start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme 또는 broken인자와 함께 실행될 수 있습니다..

서비스(그리고 모든 의존적 서비스)의 시작, 중지, 재시작을 하려면, 다음과 같이 사용될 것입니다.

예제 1-6: postfix 시작

# /etc/init.d/postfix start

중요 : 오직 주어진 서비스중 필요한 서비스만 정지하고 재시작할 수 있습니다. 다른 의존하는 서비스(필요하진 않지만 사용하는 서비스)들은 손댈 수 없습니다.

서비스를 중단하지만, 이에 의존하는 서비스들은 유지하기 위해 pause 인자를 사용할 수 있습니다.

예제 1-7: postfix를 중단하지만 이에 의존하는 서비스는 계속 실행하기

# /etc/init.d/postfix pause

서비스의 상태(started, stopped, paused, ...)가 어떤지 보기 위해 status변수를 함께 사용할 수 있습니다.

예제 1-8: postfix 상태 정보

# /etc/init.d/postfix status

상태정보가 어떤서비스를 실행하고 있지만 실제 독자여러분이 알기로 그게 아니라면 zap 인자를 통해 "stopped"정보로 상태를 재설정 할 수 있습니다.

예제 1-9: postfix 상태정보 재설정

# /etc/init.d/postfix zap

또한 어떤 서비스를 의존하고 있는지 요청하려면, iuse나 ineed를 사용할 수 있습니다. ineed를 통해서는 서비스의 올바른 기능을 위해 진정 필요한 서비스가 무엇인지를 볼 수 있습니다. 반면에 iuse 는 서비스에 의해 사용될 수 있는 서비스가 무엇인지를 보여줍니다. 하지만 올바른 기능을 위해 필요한 것은 아닙니다.

예제 1-10: postfix에 의존하는 필요한 모든 서비스 목록 요청

# /etc/init.d/postfix ineed

이와 유사하게 어떤 서비스가 이 서비스를 필요(needsme)로 하거나 이 서비스를 사용(usesme)할 수 있는지 요청할 수 있습니다.

예제 1-11: postfix를 필요로 하는 모든 서비스 목록 요청

# /etc/init.d/postfix needsme

마지막으로 서비스가 필요로 하는 빠진것이 무엇인지 요청해볼 수 있습니다.

예제 1-12: postfix의 빠진 의존성 목록 요청

# /etc/init.d/postfix broken

Gentoo의 init 시스템은 어떤 서비스가 먼저 시작되어야 할지 결정하는 의존성트리를 사용합니다. 이는 우리의 사용자들이 수동으로 해야 하는 것들중 아주 지루한 일입니다. 우리는 실행단계(runlevel)과 init 스크립트의 관리 용이성을 제공하는 도구를 만들었습니다.

rc-update를 통해 init 스크립트를 실행단계로 추가하거나 제거할 수 있습니다. rc-update 도구는 자동으로 depscan.sh 스크립트에 의존성 트리를 재빌드하도록 요청합니다.

이미 젠투 설치과정에서 "default" 실행단계로 init 스크립트들을 추가하였습니다. 이제 "default"가 어떤 것을 위한 것인가에 대한 실마리를 가지지 못했겠지만 이제는 이 실마리를 풀게 될 것입니다. rc-update스크립트는 두번째 인자를 다음 동작을 정의하기 위해 필요로합니다. add, del, show

init 스크립트를 추가하거나 제거하려면, 단지 rc-update에 init 스크립트와 실행단계가 따라오는 add나 del인자를 주면 됩니다. 예를 들자면,

예제 2-1: 기본 실행단계에서 postfix제거하기

# rc-update del postfix default

rc-update -v show 명령은 모든사용가능한 init 스크립트를 보여줄 것이며, 어떤실행단계에서 그들이 실행되는지에 대한 목록을 보여줍니다.

예제 2-2 : init 스크립트 정보 받기

# rc-update -v show

또한 rc-update show (-v없이.) 실행하여 사용 가능케 된 init 스크립트와 그들의 실행단계만을 볼수도 있습니다.

Init 스크립트는 약간 복잡할 수 있습니다. 그래서 사용자가 좀더 에러가 나기 쉬운 init 스크립트를 직접 편집할 수 있을 정도로 매력있는 것은 아닙니다. 그러나 각각의 서비스를 설정할 수 있기 위해선 중요합니다. 예를 들어 서비스에 보다 더 많은 선택사항을 부여한다고 칩시다.

두번째 이유로는 init 스크립트 외부의 환경설정을 함으로 인해 init 스크립드들을 환경설정 변경이 제대로 되지 않을 거다라는 불안감(두려움) 없이 갱신할 수 있다는 것입니다.

젠투는 각각의 서비스 설정을 위해 쉬운 방법들을 제공합니다. /etc/conf.d에 있는 파일들로 하여금 모든 init 스크립트들이 설정될 수 있습니다. 예를 들어 apache2 initscript (/etc/init.d/apache2)는 /etc/conf.d/apache2라는 환경설정파일을 지니고 있어 아파치 서버가 시작될때 부여하고픈 선택사항들을 포함할 수 있습니다.

예제 3-1: /etc/conf.d/apache2에 정의된 변수

APACHE2_OPTS="-D PHP5"

이런 환경설정 파일은 변수들 혹은 변수만(/etc/make.conf같이) 포함하고 있으며, 이는 서비스 설정을 매우 쉽게 합니다. 또한 변수에 대한 좀 더 많은 정보를 (주석으로) 우리에게 제공하기도 합니다.

아뇨. init 스크립트 작성은 젠투가 모든 제공하는 서비스를 위해 사용할 수 있게 init 스크립트를 준비하는만큼 종종 필요치 않습니다. 그러나 포티지를 사용하지 않고 서비스를 설치하였다고 할때 이런 경우 init 스크립트를 만들어야 할 것입니다.

젠투용으로 명확하게 작성된 것이 아니라면 서비스에서 제공하는 init 스크립트를 사용하지 마세요. 젠투의 init 스크립트는 다른 배포판에서 사용되는 init 스크립트와는 호환성이 없습니다.

init 스크립트의 기본 레이아웃은 아래와 같습니다.

예제 4-1: init 스크립트의 기본 레이아웃

#!/sbin/runscript

depend() {
  (Dependency information)
}

start() {
  (Commands necessary to start the service)
}

stop() {
  (Commands necessary to stop the service)
}

restart() {
  (Commands necessary to restart the service)
}

어떤 init 스크립트는start() 함수가 정의되어 있어야 합니다. 다른 섹션은 선택사항입니다.

독자여러분이 정의할 수 있는 것은 두가지 의존성입니다. use와 need가 있는데요 이전에 우리가 알던 대로라면 need의존성은 use의존성보다는 좀더 엄격합니다. 다음 의존성 형태를 따르자면 사용자 여러분이 의존하는 서비스를 입력하거나 가상의존성을 입력합니다.

가상 의존성은 서비스가 제공하는 의존성이지만 서비스에 의해 단독으로 제공되는 것은 아닙니다. init 스크립트는 시스템 로거에 의존할 수 있지만 그 시스템 로거는 여러가지가 있습니다. (metalogd, syslog-ng, sysklogd, ...). 그들중 각각의 모든 것들을 필요로 할 수 없어(둔한 시스템은 모든 시스템 로거가 설치되고 동작할 것입니다) 우리는 이들 서비스들에게 가상의존성을 제공하여 확인합니다.

이제 postfix 서비스를 위한 의존성 정보를 보도록 하죠.

예제 4-2 : postfix의 의존성 정보

depend() {
  need net
  use logger dns
  provide mta
}

여기서 볼 수 있는대로, postfix 서비스는:

• (가상의) net 의존성을 필요로합니다. (이를 통해 /etc/init.d/net.eth0와 같은 것들이 제공됩니다.)
• (가상의) logger 의존성을 사용합니다. (이를 통해 /etc/init.d/syslog-ng와 같은 것들이 제공됩니다.)
• (가상의) dns 의존성을 사용합니다. (이를 통해 /etc/init.d/named와 같은 것들이 제공됩니다.)
• (가상의) mta 의존성을 사용합니다. (이를 통해 모든 메일 서버가 제공됩니다.)
  
  

어떤 경우에는 서비스에서 필요로 하지 않는 것이 있지만, 다른 서비스가 시스템에서 사용가능하다면 시작되기 이전(혹은 이후)에 서비스를 시작하고 싶을때가 있고 (그때그때 다릅니다. 이는 더이상의 의존성을 요구하지 않습니다) 이를 같은 실행단계에서 실행하고 싶을 것입니다 (그때그때 다릅니다 - 같은 실행단계의 서비스들이 포함됩니다). 이 정보를 before과 after 설정을 사용하여 제공할 수 있습니다.

예제에서와 같이 우리는 Portmap 서비스의 설정을 보도록 합니다.

예제 4-3 : Portmap서비스에서의 depend() 함수

depend() {
  need net
  before inetd
  before xinetd
}

"*" 이거 하나로 같은 실행단계의 모든 서비스를 잡아내어 사용할 수 있습니다. 비록 그것이 현명한 방법은 아닐지라도요.

예제 4-4 : 실행단계에서 첫번째 스크립트로서 init 스크립트 실행

depend() {
  before *
}

로컬 디스크에 서비스를 기록해야만 한다면 localmount를 필요로 할 것입니다. 이게 /var/run에 pid파일같은 어떤것이 놓여져 있다면, bootmisc를 실행한 다음 이것을 시작해야 할 것입니다.

예제 4-5: depent() 함수 예제

depend() {
  need localmount
  after bootmisc
}

depend() 기능 다음으로, start() 함수의 정의도 필요합니다. 이는 서비스를 초기화 하기 위한 모든 명령들이 들어있습니다. 사용자에게로 하여금 어떤 일이 일어났는지에 대해 알려주기 위해 ebegin과 eend 함수를 사용하는 것은 권장할만한 일입니다.

예제 4-6: start() 함수 예제

start() {
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

--exec 와 --pidfile 둘은 start, stop 함수에서 쓰일것입니다. 서비스가 pidfile을 만들지 않는다면, 가능하면 --make-pidfile 를 써서 이게 제대로 동작되는지 시험할 것입니다. 이 경우가 아니면 pidfile 들을 쓰지 마십시오. 또한 --quiet를 start-stop-daemon 옵션에 덧붙일 수 있습니다만 이는 극단적으로 메세지를 주구장창 내뱉는 서비스가 아니라면 추천하지 않습니다. --quiet를 사용함으로 인해 서비스 시작이 실패했을 경우 문제점 추적을 방해할 것입니다.

중요 : --exec가 실제로 서비스를 호출하고, 쉘스크립트가 단지 서비스를 실행하고 종료하기만 하는것이 아닌지를 확인해 보십시오. 이것은 init 스크립트가 할 일을 가정하는 것입니다.

start()함수에 대한 더 자세한 예제를 보려명 /etc/init.d 디렉토레이 있는 사용가능한 init 스크립트들의 소스코드를 보시기 바랍니다.

독자여러분이 정의할 수 있는 다른 함수들로는 stop() 과 restart()함수가 있습니다. 이 함수들을 꼭 정의할 필요는 없습니다. start-stop-daemon을 사용하신다면, 젠투 init 시스템은 자신이 충분히 이들 함수를 채워놓습니다.

비록 stop() 함수를 행성하지 않았겠지만, 여기 예제가 있습니다.

예제 4-7 : stop() 함수 예제

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

서비스가 (배시, 파이선, 펄과 같은) 어떤 다른 스크립트를 실행하고 그 스크립트 이름을 변경했다(foo.py에서 foo로 변경)면 start-stop-daemon에 --name을 추가할 필요가 있을 것입니다. 스크립트가 바뀔 것에 대한 이름을 정해야 합니다. 이예제에서 foo로 이름이 바뀐 서비스는 foo.py로 시작합니다.

예제 4-8 : foo 스크립트를 시작하는 서비스

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

}

좀 더 자세한 정보가 필요한 분들을 최상의 start-stop-daemon 맨 페이지를 갖춰놓았습니다.

예제 4-9: start-stop-daemon 맨페이지 보기

$ man start-stop-daemon

Gentoo의 init 스크립트 문법은 본 어게인 쉘(bash)을 기반으로 하기 때문에 init 스크립트에 배시호환 구성물을 자유롭게 사용할 수 있습니다.

(역자 주 : 번역결과가 꽤 껄떡찌근합니다 ㅡ.ㅡ ... 더 좋은 번역단어를 추천해주시면 번역문서의 완성에 큰 도움이 됩니다.)

init스크립트를 통해 우리가 접해보았던 것들보다 더 많은 옵션을 지원하게 하려면, opts변수에 옵션을 추가하고, 선택사항에 추가한 요소와 같은 이름을 가진 함수를 생성할 수 있습니다. 다음에서는 restartdelay로 불리우는 옵션을 지원하고 있습니다.

예제 4-10 : restartdelay 옵션 지원

opts="${opts} restartdelay"

restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

/etc/conf.d에 있는 설정파일을 지원하기 위해 그 어떤것을 할 필요가 없습니다. init 스크립트가 실행되었을때 다음 파일들은 자동으로 생성됩니다. (사용가능한 변수들 등):

• /etc/conf.d/<your init script>
• /etc/conf.d/basic
• /etc/rc.conf
  
  

또한 init 스크립트에 가장 의존성 (net 같은것들)을 제공한다면, 의존성과 관련된 파일들(/etc/conf.d/net 같은 것들) 역시 생성될 것입니다.

대부분의 랩탑 사용자들은 이런 상황에 대해 잘 알것입니다. 집에서는 net.eth0을 시작할 필요가 있는데 (네트워크를 사용할 수 없는)길가에서는 net.eth0을 시작하고 싶어하지 않습니다. 젠투에서는 독자 여러분 자신이 하게 될 것을 런레벨 동작으로 대체할 수 있습니다.

예를들어 독자여러분은 다른 init 스크립트를 할당하여 부팅하는 제 2의 "default" 런레벨을 만들수 있습니다. 그런 후 어떤 기본 런레벨을 사용할 것인지 부팅할 때 선택할 수 있습니다.

먼저, 제 2의 "default" 런레벨을 위한 실행단계 디렉토리를 만들어즙니다. 다음 예제에서 우리는 오프라인 실행단계를 만들어주고 있습니다.

예제 5-1 : 런레벨 디렉토리 생성

# mkdir /etc/runlevels/offline

필요한 init 스크립트를 생성된 실행단계에 새로이 추가합니다. 예를 들어 현재 기본 런레벨에서 net.eth0을 제외한 정확한 복사본을 원한다면,

예제 5-2 : 필요한 init 스크립트 추가

(Copy all services from default runlevel to offline runlevel)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Remove unwanted service from offline runlevel)
# rc-update del net.eth0 offline
(Display active services for offline runlevel)
# rc-update show offline
(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

net.eth0가 오프라인 런레벨에서 없어졌지만, udev는 여전히 감지된 장치를 시작하고 허용된 서비스를 실행하려들 것입니다. 따라서 독자 여러분은 실행을 원하지 않는 각각의 네트워크 서비스를 /etc/conf.d/rc에 보기와 같이 추가할 필요가 있을 것입니다. (udev로 시작된 어떤 다른 디바이스들을 위한 서비스 같은 것들을요.)

예제 5-3 : /etc/conf.d/rc에서 장치 초기화 서비스를 사용중지

RC_COLDPLUG="yes"
(Next, specify the services you do not want automatically started)
RC_PLUG_SERVICES="!net.eth0"

유의사항: 장치 초기화 서비스에 대한 더 자세한 정보를 알려면 /etc/conf.d/rc에 있는 주석을 읽어보세요.

이제 부트로더 환경설정을 편집하고 오프라인 실행단계를 위한 새로운 엔트리를 합니다. /boot/grub/grub.conf를 예로 들어보자면,

예제 5-4 : 오프라인 런레벨을 위한 엔트리 추가

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

자 어떤가요? 이제 모든 것을 설정하셨습니다. 독자여러분의 시스템을 부트하고 새롭게 추가된 엔트리를 부팅시 선택한다면 오프라인 런레벨은 기본사항 대신에 사용될 수 있을 것입니다.

부트레벨 사용은 소프트레벨에서와 완벽하게 유사합니다. 차이점이있다면 제 2의 "boot" 런레벨을 제 2의 "default" 레벨 대신 사용한다는 것 뿐입니다.

이전으로 가기