Handbook:Parts/Working/Initscripts/ko

시스템 부팅
시스템을 부팅하면 수많은 텍스트가 떠다닙니다. 더 자세히 들여다보면 여러분이 다시 부팅할 때마다 이 텍스트가 같은 내용이 항상 나오는 것을 보실 수 있습니다. 이 동작의 순서를 부트 시퀀스라고 하며, (더 혹은 덜) 정적으로 정의합니다.

먼저 부트로더는 CPU한테 커널을 실행하라고 알린 다음에 부트로더 설정에 지정되어 있는 커널 이미지를 메모리에 불러옵니다. 커널을 불러와서 실행한 후 모든 커널 관련 구조를 초기화하고 init 과정을 시작합니다.

이 프로세스는 (에 지정한) 모든 파일 시스템을 마운트 했는지 사용할 준비가 되었는지를 확인합니다. 그 다음 시스템을 성공적으로 부팅하기 위해 필요한 서비스를 시작하려고 의 수 많은 스크립트를 실행합니다.

Finally, when all scripts are executed, init activates the terminals (in most cases just the virtual consoles which are hidden beneath +, +, etc.) attaching a special process called to it. This process will then make sure users are able to log on through these terminals by running login.

Initscripts
여기서 init는 에 있는 스크립트를 임의대로 실행하는 것이 아닙니다. 게다가 에 있는 모든 스크립트를 실행하는 것도 아니며 실행하라고 지시한 스크립트만 실행합니다. 이는 를 확인하여 어떤 스크립트를 실행할 지 결정합니다.

먼저 init는 에서 에 심볼릭 링크한 모든 스크립트를 실행합니다. 보통 철자순으로 스크립트를 실행하겠지만 어떤 스크립트의 경우 이들 스크립트를 실행하기 전에 다른 스크립트를 먼저 실행해야 한다고 시스템에 알려주는 의존성 정보를 가지고 있습니다.

When all referenced scripts are executed, init continues with running the scripts that have a symbolic link to them in. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence. The latter is also the reason why commands used during the installation of Gentoo Linux used, as in.

init 동작 방법
물론 init 에서 모든 사항을 자체적으로 결정하지 못합니다. 어떤 동작을 취해야 할지 지시하는 설정 파일이 필요합니다. 이 설정 파일은 입니다.

Remember the boot sequence that was just described - init's first action is to mount all file systems. This is defined in the following line from :

This line tells init that it must run to initialize the system. The script takes care of the initialization, so one might say that init doesn't do much - it delegates the task of initializing the system to another process.

두번째로, init은 에 심볼릭 링크를 걸어둔 모든 스크립트를 실행합니다. 이는 다음의 줄에서 설정했습니다:

다시 말씀드리지만 rc 스크립트는 필요한 작업을 수행합니다. 참고로 rc (boot) 에 주어진 옵션은 이것이 사용하는 의 하위 디렉터리와 같습니다.

이제 init 는 어떤 실행 레벨을 실행할 지 설정 파일을 확인합니다. 에서 다음 줄을 읽어 들들이고 실행할 실행 레벨을 결정합니다.

이 경우 (대부분의 젠투 사용자들이 사용할 경우), 실행레벨 id는 3입니다. 이 정보를 사용하여 init 은 실행레벨 3을 시작하기 위해 무엇을 실행해야 하는지 확인합니다:

The line that defines level 3, again, uses the rc script to start the services (now with argument ). Again note that the argument of rc is the same as the subdirectory from.

rc 실행이 끝나면 init은 어떤 가상 콘솔을 활성화 할지, 각 콘솔에서 실행할 명령을 결정합니다.

존재하는 실행 레벨
이전 절에서, init에서 어떤 실행 레벨을 활성화 할지 결정하는 숫자 방식을 활용함을 보았습니다. 실행 레벨은 시스템이 실행중인 상태를 나타내며, 실행 레벨에 진입하거나 벗어날때 실행해야 할 여러가지 스크립트(실행 레벨 스크립트 또는 초기화 스크립트)를 가지고 있습니다.

In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initialize the system, powering off the system, and rebooting the system.

사용자 런레벨은 의 하위 디렉터리 boot, default, nonetwork, single과 연결됩니다. boot 런레벨은 모든 기타 런레벨에서 사용하려는, 전체 시스템에서 필요한 서비스를 시작합니다. 나머지 세가지 런레벨은 어떤 서비스를 시작하느냐에 따라 차이가 있습니다. default는 항상 실행할 때 사용하고, nonetwork는 네트워크 연결이 필요하지 않을 때 사용하며, single은 시스템을 복구해야 할때 사용합니다.

초기화 스크립트(initscript) 다루기
The scripts that the rc process starts are called init scripts. Each script in can be executed with the arguments ,  ,  ,  ,  ,  ,  ,  ,  , or.

To start, stop, or restart a service (and all depending services), the,  , and   arguments should be used:

To stop a service, but not the services that depend on it, use the  option together with the   argument:

To see what status a service has (started, stopped, ...) use the  argument:

If the status information shows that the service is running, but in reality it is not, then reset the status information to "stopped" with the  argument:

To also ask what dependencies the service has, use  or. With  it is possible to see the services that are really necessary for the correct functioning of the service. on the other hand shows the services that can be used by the service, but are not necessary for the correct functioning.

Similarly, it is possible to ask what services require the service or can use it :

마지막으로 서비스에서 필요로 하는 것중에 빠진 의존성이 무엇인지 확인할 수 있습니다:

rc-update
젠투의 init 시스템은 의존 트리를 사용하여 어떤 서비스를 먼저 시작해야 할지 결정 합니다. 사용자 여러분들이 이 지루한 작업을 하지 않도록 실행 레벨과 초기화 스크립트 관리를 쉽게 하는 도구를 만들었습니다.

With it is possible to add and remove init scripts to a runlevel. The tool will then automatically ask the  script to rebuild the dependency tree.

서비스 추가/삭제
In earlier instructions, init scripts have already been added to the "default" runlevel. What "default" means has been explained earlier in this document. Next to the runlevel, the script requires a second argument that defines the action: ,  , or.

To add or remove an init script, just give the   or   argument, followed by the init script and the runlevel. For instance:

The command will show all the available init scripts and list at which runlevels they will execute:

It is also possible to run (without  ) to just view enabled init scripts and their runlevels.

왜 추가 설정이 필요한가
초기화 스크립트는 조금 복잡할 수 있습니다. 때문에 오류에 취약하게 만들 수가 있어 사용자가 초기화 스크립트를 올바르게 수정하는게 만족스럽진 않습니다. 그러나 서비스를 설정할 수 있는 방법에 있어서는 중요합니다. 예를 들어 여러분이 서비스 자체에 더 많은 옵션을 주고 싶어할 수도 있습니다.

두번째 이유로는 초기화 스크립트의 외부 설정을 보유하려면, 바꾼 설정을 되돌릴 수 없다는 두려움을 없애고 초기화 스크립트를 업데이트할 수 있어야 하기 때문입니다.

conf.d 디렉터리
Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in. For instance, the initscript (called ) has a configuration file called, which can contain the options to give to the Apache 2 server when it is started:

이런 설정 파일에는 서비스 설정을 쉽게 하는 ( 같은)변수만 들어있습니다. 변수에 대한 더 자세한 정보도(주석을 통해) 제공해줄 수 있습니다.

필요한가요
아닙니다. 초기화 스크립트 작성은 보통 젠투가 모든 제공하는 서비스에 대해 준비된 초기화 스크립트를 제공하는 만큼 필요하지 않습니다. 그러나 포티지를 사용하지 않는 서비스를 설치할 때가 있는데, 초기화 스크립트의 거의 대부분을 만들 필요가 있습니다.

젠투용으로 확실하게 작성한 것이 아니라면 서비스에서 제공하는 init 스크립트를 사용하지 마십시오. 젠투의 초기화 스크립트는 다른 배포판에서 사용하는 초기화 스크립트와 호환되지 않습니다!

배치
초기화 스크립트의 기본 배치는 아래와 같습니다.

Every init script requires the start function to be defined. All other sections are optional.

의존성
초기화 스크립트의 준비와 순차진행에 영향을 주는 요소가 무엇인지 지정할 수 있는 의존성 유사 방식에는 use와 need가 있습니다. 순서에 관계된 메서드에는 before과 after가 있습니다. 후자의 두가지 키워드는 그 자체로 의존성을 지니지 않습니다 어떤 스크립트가 시작하도록 계획하지 않았을 때(또는 시작에 실패했을 때) 원 초기화 스크립트의 동작이 실패하지 않도록 합니다.


 * use 설정은 선택한 스크립트의 기능을 이 스크립트가 사용하지만 직접적인 의존성을 지니지 않도록 init 시스템에 알려줍니다. 좋은 본보기로 use logger나 use dns를 들 수 있습니다. 이 서비스가 존재한다면 사용하기 좋은 상태로 두겠지만 로거나 DNS 서버가 없다 하더라도 서비스는 여전히 동작할 것입니다. 서비스가 존재한다면 use에 있는 스크립트보다 먼저 서비스를 시작합니다.
 * need 설정은 강한 의존성입니다. 이는 need(필요)한 스크립트일 경우 명시한 스크립트를 성공적으로 실행하기 전에 시작하지 않음을 의미합니다. 또한 언급한 다른 스크립트를 다시 시작하면 마찬가지로 해당 스크립트도 다시 시작합니다.
 * before를 사용하면, 선택한 요소가 init 레벨의 일부일 경우 선택한 요소를 실행하기 전에 주어진 스크립트를 실행합니다. 그래서 before alsasound를 정의한 xdm 초기화 스크립트는 alsasound 스크립트를 실행하기 전에 시작하겠지만, alsasound가 동일한 init 레벨에서 실행하도록 계획했을 경우에만 해당합니다. alsasound를 시작하도록 계획하지 않았다면, 일부 설정은 효력이 없으며, 스크립트 자신이 가장 적당하다고 여기는 시점에 xdm을 실행합니다.
 * 이와 마찬가지로 after를 사용하면, 선택한 요소가 init 레벨의 일부일 경우 선택한 요소를 실행한 다음에 주어진 스크립트를 실행합니다. 아니면 설정이 효력이 없으며, 적당하다고 여기는 시점에 init 시스템이 스크립트를 실행합니다.

need가 스크립트를 시작하든 아니든 영향을 주는 진성 의존성 설정이라는 점을 분명히 이해해야합니다. 다른 모든 요소는 명령 스크립트를 실행(할 수 있거나 해야)할 수 있을때 init 시스템에 대해 분명히 가리킬 뿐입니다.

이제 젠투에서 사용하는 초기화 스크립트를 살펴보고, 초기화 스크립트가 아닌 의존성 요소를 살펴보십시오. 이"것"을 가상요소라고 부릅니다.

"가상 의존성"은 서비스에서 제공하는 의존성이지만 서비스에서 단독으로 제공하지 않는 의존성입니다. 초기화 스크립트는 시스템 로거에 의존할 수 있습니다만 시스템 로거는 여러가지가 있습니다(metalogd, syslog-ng, sysklogd, ...). 스크립트에서 이들 각자의 단일 모듈(모든 시스템 로거를 설치하고 실행중인지 시스템에서 신경쓰지 않음)을 필요로하지 않기 때문에, 이런 모든 서비스에서 가상 의존성을 제공함을 확인합니다.

Postfix 서비스의 의존성 정보를 살펴보겠습니다:

보시는 바와 같이 Postfix서비스에는 다음과 같은 내용이 있습니다:


 * (가상)net 의존 요소가 필요합니다 ( 같은 요소로 제공)
 * (가상)logger 의존 요소를 사용합니다 ( 같은 요소로 제공)
 * (가상)dns 의존 요소를 사용합니다 ( 같은 요소로 제공)
 * (가상)mta 의존 요소를 제공합니다 (모든 메일 서버의 공통요소)

순서 처리
이전 장에서 설명한 바와 같이 스크립트를 시작(하고 중지)하는 순서를 어떻게 할지 init 시스템에 알려줄 수 있습니다. 이 순서는 use와 need 의존 설정을 통해 다룰 뿐만 아니라 before와 after로도 순서 설정을 다루기도 합니다. 역시 앞의 설명과 마찬가지로 초기화 스크립트 중 하나의 예제로서 portmap 서비스를 살펴보겠습니다.

비록 별로 도움이 되는 이야기는 아니지만, 동일한 실행 레벨의 모든 서비스를 포함하려면 "*" 글롭을 사용할 수 있습니다.

서비스가 반드시 로컬 디스크에 기록을 해야 한다면 localmount가 필요합니다. pidfile 같은 것을 에 두었다면 bootmisc 다음에 실행해야합니다:

표준 함수
함수 다음,  함수 정의가 필요합니다. 이 함수에는 서비스를 시작하는데 필요한 모든 명령어를 담고 있습니다. 사용자에게 무슨 일이 일어나고 있는지를 알리려면 ebegin과 eend함수를 사용하는 것이 좋습니다.

와 를 사용합니다. 그렇지 않으면 pidfile를 사용하지 않습니다. 또한 start-stop-daemon의 옵션으로 를 추가할 수 있지만 서비스에서 너무 많은 메시지를 뿌려대지 않은 이상 추천하는 방법은 아닙니다. 를 사용하면 서비스 시작에 실패했을 때 디버깅 내용을 못볼 수도 있습니다.

위의 예제에서 눈에 띄는 설정은 RC_CMD 변수 내용의 확인입니다. 이전 초기화 스크립트 시스템과는 다르게 새로운 openrc 시스템에서는 스크립트별 다시 시작 기능을 사용하지 못합니다. 대신 함수( 나 )를 다시 시작 과정의 일부로 호출했든지 아니든지간에 RC_CMD 변수의 내용을 스크립트에서 확인해야합니다.

함수에 대한 더 많은 예제를 보시려면 디렉터리에 있는 초기화 스크립트의 소스 코드를 살펴보십시오.

Another function that can (but does not have to) be defined is. The init system is intelligent enough to fill in this function by itself if start-stop-daemon is used.

If the service runs some other script (for example, Bash, Python, or Perl), and this script later changes names (for example, to foo), then it is necessary to add   to start-stop-daemon. This must specify the name that the script will be changed to. In this example, a service starts, which changes names to foo:

참고할 내용이 더 많이 필요할 경우를 대비하여 start-stop-daemon은 최고의 맨 페이지를 보유하고 있습니다:

젠투의 초기화 스크립트 문법은 POSIX 쉘을 기반으로 하기 때문에 자유롭게 초기화 스크립트에 sh-호환 문법 스크립트를 사용할 수 있습니다. init 시스템에서 젠투가 처리할 변경 사항과는 상관 없이 스크립트의 기능이 남아있는지 확인하는, init 스크립트 외적인 배시 맞춤형 구성체처럼 다른 요소도 유지합니다.

개별 옵션 추가
앞서 우리가 언급했던 옵션보다 더 많은 옵션을 초기화 스크립트에서 지원하도록 하려면 extra_commands 변수에 옵션을 추가하고, 옵션 이름과 동일한 함수를 만들어야 합니다. 실례로 restartdelay라고 하는 옵션을 지원하게 해보겠습니다:

서비스 설정 변수
의 설정 파일을 지원하려 어떤 내용도 구현할 필요가 없습니다. 초기화 스크립트를 실행하면 다음 파일을 자동으로 참조합니다(예: 사용할 수 있는 변수):



또한 초기화 스크립트에 (net과 같은)가상 의존성을 제공하면, (과 같은) 의존성의 관련 파일도 참조합니다.

누가 이득을 볼까요
많은 랩톱 사용자들은 이런 상황을 알고 있습니다. 밖에서 (사용할 수 있는 네트워크가 없을 때) net.eth0를 시작하고 싶지 않은데 집에서는 net.eth0를 시작해야 할 때가 있습니다. 젠투에서는 여러분이 실행할 실행 레벨 동작을 바꿀 수 있습니다.

다른 초기화 스크립트를 할당하여 부팅할 수 있는 두번째 "default" 실행 레벨을 만들 수 있습니다. 사용자는 부팅 시간에 활용할 기본 실행 레벨이 어떤 레벨인지 선택할 수 있습니다.

소프트 레벨 사용
제일 먼저, 두번째 "default" 실행 레벨에 대한 실행 레벨 디렉터리를 만드십시오. 다음 예제에서 "offline" 실행 레벨을 만들겠습니다.

새로이 만든 실행 레벨에 필요한 초기화 스크립트를 추가하십시오. 현재 기본 실행 레벨에 net.eth0를 제외한 정확한 복사본을 보유하려면:

net.eth0을 offline 런레벨에서 제거했지만서도, udev가 감지한 장치를 시작하고 핫 플러그라는 기능의 적당한 서비스를 실행하려 들지도 모릅니다. 기본적으로 젠투는 핫 플러그를 활성화하지않습니다:

핫 플러그 기능을 활성화하지만 선택한 스크립트 모음에 한정하려면, 의 rc_hotplug 변수를 사용하십시오:

부트로더 설정을 편집하여 오프라인 실행 레벨에 대한 새 항목을 추가하십시오. 해당 항목에서 부팅 매개변수로 를 추가하십시오.

부트 레벨 사용
bootlevel을 사용하는 것은 softlevel과 완전히 유사합니다. 두번째 "default" 런레벨 대신에 두번째 "boot" 런레벨을 정의하는 점만 다릅니다.