(무엇보다도 커널 디버거가 부족한) GNU /리눅스에 대해 갖는 공통적인 불만은 OS 시작에 시간이 많이 걸린다는 것이다. 이 프로세스를 부팅(booting)으로 간주할 수 있지만, 사실 여러 가지 독립적인 태스크들이 개입되어 콜드(cold) 시스템에서 쉘 또는 윈도우 매니저를 통해 인터랙팅 할 수 있는 시스템으로 변해간다. 리눅스 부팅과 초기화 프로세스에 대해 알아보자.

리눅스 부팅의 주요 단계

리눅스 부팅에는 많은 단계들이 있지만, 이 프로세스를 세 가지 기본적인 단계로 나눌 수 있다. 그림 1에서 묘사한 것처럼 BIOS, 커널 부트(kernel boot), 시스템 초기화(system initialization,)로 나뉠 수 있다.

BIOS

여러분이 처음 컴퓨터를 켜거나 리셋 할 때, 컴퓨터 프로세서는 basic input/output system(BIOS)에서 실행을 시작한다. BIOS는 시스템의 마더보드에 있는 플래시 메모리 장치에 저장되어 있으며, 이는 기본 컴포넌트들(시스템 메모리)의 초기 테스팅, OS를 부팅하는 방법 결정 등 많은 작업(job)을 갖고 있다. PC 기반 컴퓨터들이 매우 유연해지면서, 부팅 장치는 하드 디스크, CD-ROM 또는 네트워크 인터페이스 같은 기타 장치들을 포함하여 마더보드에 부착된 많은 개별 장치들 중 하나가 될 수 있다.

여러분이 일반적으로 부팅 할 곳(주로 하드 디스크)에서 장치를 선택함으로써, 부팅 장치를 결정하는 프로세스를 최적화 할 수 있다. 하지만, 지금까지, BIOS 단계 중에서 가장 시간을 많이 소비하는 측면은 메모리 테스트이다. 이 테스트의 특정 측면들(예를 들어, 전체 메모리 테스트 같은)을 실행하지 않으면 속도 향상에는 도움이 될 수 있지만 부팅 시 시스템 무결성 테스트라는 대가를 치러야 한다.

커널 부팅

부팅 장치가 발견되면 리눅스 커널 부팅 프로세스가 시작된다. 이 프로세스는 (대략) 두 단계(제 1 단계 부팅(first-stage boot)과 제 2 단계 부팅(second-stage boot.))로 발생한다. 제 1 단계는 간단한 부트 로더(부팅 장치의 마스터 부트 레코드(MBR)에 있음)로 구성되고, 하는 일은 제 2 단계 부트 로더를 로딩한다. 제 1 단계 부트 로더는 파티션 테이블을 사용하여 제 2 단계 부트 로더를 찾는다. 제 1 단계 부트 로더는 테이블을 검사하면서, 활성 파티션을 찾는다. 로더가 파티션을 배치하면, 제 2 단계 부트 로더를 RAM에 로딩하고 이를 실행한다.

제 2 단계 부트 로더가 RAM에 로딩되면, 리눅스 커널 이미지와 초기 RAM 디스크 이미지(initrd)가 RAM에 로딩된다. 커널이 실행될 때, 하이 메모리로 압축을 풀고 initrd를 나중에 사용할 수 있도록 복사한다.

커널 부트 프로세스는 매우 복잡하지만 매우 빠르다. 대부분의 코드가 해당 시스템의 기계어로 작성되기 때문이다. 커널 부트 순서의 말미에, init 프로세스가 시작되며, init은 리눅스 시스템에서 생성된 첫 번째 프로세스 이므로, 이것은 다른 모든 프로세스들의 엄마(mother)인 셈이다. (모든 프로세스들은 init의 자손(child)이라고 할 수 있다.)

System init

본 글의 주제인 init 프로세스는 커널 부트 시퀀스가 완료되면서 생성된 첫 번째 프로세스이다. 리눅스는 init 프로세스를 사용하여 서비스와 애플리케이션을 초기화 하는데, 이것이 리눅스를 더욱 유용하게 만든다.

init 프로세스가 시작될 때, /etc/inittab.이라고 하는 파일을 연다. 이 파일은 init용 설정 파일이고, 시스템을 초기화 하는 방법을 정의하고 있다. 이 파일에는 전원 오류가 발생할 때 무엇을 해야 하는지에 대한 정보와, Ctrl-Alt-Delete 키 시퀀스를 탐지할 때 반응하는 방법 등을 수록하고 있다. Listing 1은 이 파일의 일부이다.

inittab 설정 파일은 공통 포맷인 id:runlevels:action:process.로 여러 엔트리들을 정의하고 있다. id는 엔트리를 구분하는 문자 시퀀스이다. runlevels는 액션이 취해질 runlevel을 정의한다. action은 특별한 액션을 지정한다. 마지막으로 process는 실행될 프로세스를 정의한다.

				
# The default runlevel
id:2:initdefault

# Boot-time system configuration/initialization script
si::sysinit:/etc/init.d/rcS

# Runlevels
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
z6:6:respawn:/sbin/sulogin

# How to react to ctrl-alt-del
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

init이 /etc/inittab을 로딩하면, 시스템은 initdefault 액션이 정의한 runlevel로 간다. Listing 1에서 보듯, 이것은 runlevel 2가 된다. runlevel을 시스템의 상태로 간주하라. 예를 들어, runlevel 0은 시스템 중지 상태이고, runlevel 1은 싱글 유저 모드이다. runlevel 2에서 5까지는 멀티 유저 상태이고, runlevel 6은 재부팅을 나타낸다. (일부 배포판에서는 runlevel을 다르게 표시할 수 있다.) 또는, 실행될 프로세스(시스템의 상태를 정의하는 프로세스)를 정의하는 방식으로 runlevel을 간주할 수 있다.

주: 시스템의 현재 runlevel을 보려면, runlevel 명령어를 사용한다.

Listing 1에서 정의된 것처럼, initdefault는 기본 init 레벨을 2(멀티 유저 모드)로 정한다. 초기 runlevel이 정의된 후에, 인자 2(runlevel)를 가진 rc 스크립트가 실행되어 시스템을 불러온다. 이 스크립트는 다양한 서비스와 애플리케이션 스크립트를 실행하여 특정 엘리먼트를 시작 또는 중지한다. 이 경우, 파일들은 /etc/rc2.d/에 정의된다. 예를 들어, MySQL 애플리케이션이 시작되었다면(시스템 시작처럼) /etc/rc2.d/S20mysql start로서 실행되었을 것이다. 시스템이 중지될 때, 같은 스크립트가 stop 인자와 함께 실행된다.

결국, 많은 스크립트들이 순차적으로(serially) 실행되어 필요한 다양한 서비스들을 시작한다. (여러분은 리눅스에서 부팅 스크린의 일부로 보게 될 것이다.) 서비스들이 서로 관련이 없다 하더라도, 하나가 시작된 후에 다른 것이 시작된다. 그래서 결국 이 프로세스에 시간이 드는 것이다. (특히, 많은 서비스들을 갖고 있는 큰 시스템이 더욱 그러하다.)

이러한 문제에 대한 확실한 솔루션은 init 명령의 순차성을 없애고 보다 병렬적으로(parallel) 실행하도록 하는 것이다. 많은 곳에서 멀티 프로세싱 시스템을 사용하고 있는 것을 보면 이해가 될 것이다. 예를 들어, 소켓 스크립팅(socket striping,) 또는 두 개 이상의 소켓을 사용하여 데이터를 병렬로 이동하는 것은 이러한 개념에 입각한 솔루션이다. Redundant array of independent disks (RAID) 시스템 역시 디스크 주위를 (병렬 방식으로) 스트리핑 하여 디스크 I/O 성능을 높이고 있다.

위로

Init 데몬 교체

전통적인 init 프로세스(sysvinit)는 순차 프로세스이므로, 이러한 시스템 부분은 최적화 하기에 알맞다. 사실, init 프로세스를 최적화 할 때 여러 가지 방식들을 사용할 수 있다. 이러한 방식 몇 가지를 살펴보고, 문제를 해결하는 방법을 알아보자. 첫 번째 두 방식은 종속 관계(dependency) 기반(종속 관계를 사용하여 병렬화를 이룩한다.)이고, 세 번째는 이벤트 기반 시스템(프로세스가 이벤트에 의존하여 시작과 중지할 때를 지시한다.)이다.

위로

Initng

첫 번째 옵션인 initng( init next generation)은 init 프로세스를 보다 빠르게 완료하기 위해, 프로세스를 비동기식으로 시작하는 init의 완벽한 대안이다. 이 글을 쓰고 있는 현재, initng는 베타 버전으로 릴리스 되었고, 제작자는 Jimmy Wennlund이다.

initng의 기본 개념은 서비스들의 종속 관계가 충족되자마자 서비스들이 시작되는 것이다. 이러한 시스템은 CPU 대 I/O의 균형이 더욱 잘 이루어진다. 하나의 스크립트가 디스크에서 로딩되거나 하드웨어 장치가 시작되기를 기다리는 동안, 또 다른 스크립트가 실행되어 다른 서비스를 시작할 수 있다.

initng의 작동 방법

종속 관계 기반 솔루션으로서, initng는 서비스와 데몬 종속 관계를 인코딩 하는 고유의 초기화 스크립트를 사용한다. Listing 2는 예제이다. 이 스크립트는 해당 runlevel에서 시작될 서비스를 지정한다. 이 서비스는 need 키워드에서 정의된 대로 두 개의 종속 관계(system/initial과 net/all)를 갖고 있으며, 이러한 서비스들은 system/my_service가 시작되기 전에 사용할 수 있어야 한다. 이러한 서비스들이 사용되면, exec 키워드가 실행되며, exec 키워드(start 옵션이 있음)는 서비스를 시작하는 방법과 사용 가능한 옵션들을 정의한다. 서비스가 중지할 때, exec 키워드와 stop 옵션이 사용된다.

				
service system/my_service {

  need = system/initial net/all;

  exec start = /sbin/my_service --start --option;
  exec stop = /sbin/my_service --stop --option;

}

Listing 2처럼, 전체 시스템을 서비스 정의로 인코딩 할 수 있다. 종속 관계가 없는 것은 즉시(그리고 병렬로) 시작될 수 있고, 종속 관계를 가진 것은 안전하게 시작할 때를 기다린다. initng를 목표 기반(goals-based) 시스템으로 생각할 수도 있다. 목표는 시작될 서비스이며, 어떤 명확한 계획은 없는대신, 종속 관계들은 병렬 프로세스에 맞춰 서비스 초기화의 흐름을 정의한다.

initng 사용하기

initng 패키지는 설치가 비교적 간단하다. 비 표준 패키지를 사용하는 시스템의 경우 어셈블리가 필요하다.

initng의 설치에는 initng 배포판(소스 또는 바이너리)과 ifiles 배포판이 필요하다. ./configure, make, make install을 사용하여 initng 배포판을 구현할 수 있다. cmake로 (스크립트 파일인) ifiles을 구현해야 한다. 시스템 요구 사항에 따라, 새로운 서비스/데몬 정의를 만들어야 한다. (이미 initng 커뮤니티의 누군가는 이미 정의했을 수도 있겠다.) 그런 다음, LILO나 GRUB 설정을 수정하여 새로운 /sbin/initng를 가리키도록 한다.

initng를 제어하려면 ngc(전통적인 init의 telinit에 해당)를 사용한다. 문법은 약간 다르지만, 기능은 같다.

위로

Upstart

init을 대체하는 또 다른 옵션인 upstart는 initng와는 약간 다른 방식을 취한다. Upstart는 이벤트 기반 init으로서, 서비스의 시작과 중지가 이벤트들의 통신에 기반한다. Upstart는 Scott James Remnant의 Ubuntu 배포판을 위해 개발되었지만, 여느 리눅스 배포판의 init도 대체할 수 있다.

Upstart 작동 방법

Upstart는 이벤트 기반 작동 모드를 지원하도록 초기화 스크립트를 업데이트 해야 한다. Upstart는 (다른 모든 방식들과 마찬가지로) 시스템 시작 시 시작하는 고유의 init 프로세스를 갖고 있다. 우선, init이 두 개의 핵심 이벤트 중 하나인 startup 이벤트를 나타낸다. startup 이벤트는 시스템이 시작할 때 init에 의해 나타나고, 시스템이 중지될 때 shutdown 이벤트가 나타난다. 다른 핵심 이벤트로는 ctrlaltdel,이 있는데, 이것은 Ctrl-Alt-Delete 또는 kbdrequest,를 누르도록 지시한다. 이것은 Alt-Up 화살표 키 조합을 눌렀다는 것을 나타내는데 사용된다.

다른 용도로 쓰일 새로운 이벤트를 만들 수 있다. 예를 들어, myevent라고 하는 이벤트를 만들어서 echo 명령어를 사용하여 이것의 수혜자를 가리킬 수 있다. 다음과 같이 실행한다.

on myevent
exec echo myevent received
console output

이 코드는 myevent 이벤트를 수신할 때 작업이 실행되도록 지정하고 있다. 이 코드는 지정된 액션을 수행한다. (텍스트를 콘솔에 나타내기) 이 파일이 upstart 설정(/etc/event.d)에 있다면, initctl 유틸리티를 사용하여 이를 실행할 수 있다.

initctl emit myevent

upstart용 스크립트 파일은 전통적인 rc init 파일과 비슷하게 작동한다. 단, 비동기식 이벤트에 기반하여 비동기식으로 작동한다는 점만 다르다. Listing 3은 세 개의 이벤트를 수락하는 예제 스크립트를 보여준다. 작업이 시작되도록 하는 startup, 작업을 중지시키는 shutdown과 runlevel-3,이다. 이 쉘은 이 작업의 script 부분의 내용을 실행한다. (에러 발생 시 -e 옵션을 사용하여 스크립트를 종료함.)

				
start on startup
stop on shutdown
stop on runlevel-3

script
	set $(runlevel --set 2 || true)
	exec /etc/init.d/rc 2
end script

initctl 유틸리티는 telinit과 비슷한 기능을 제공하지만 upstart를 위한 추가 기능을 갖고 있다. 위에서 보듯, initctl과 emit 옵션을 사용하여 upstart에 대한 이벤트를 만들 수 있다. list 옵션은 작업의 상태를 구분함으로써 시스템의 작동 상태를 알 수 있도록 한다. 어떤 것이 대기 중이고, 어떤 것이 실행 중인지를 알려준다. initctl 유틸리티는 또한 디버깅 용도로 수신된 이벤트도 디스플레이 한다.

Upstart는 재미있는 init의 대체이고, 그보다 더 나은 장점도 갖고 있다. 하드웨어가 있는 한 시스템은 부팅할 것이므로 runlevel이 있을 필요 없으며, 존재하지 않는 하드웨어는 작업을 실행하지 않을 것이다. Upstart는 또한 Hot Plugging 장치도 핸들링한다. 예를 들어, 시스템이 부팅된 후에 PCMCIA 네트워크 카드를 꽂았다면, network-interface-added 이벤트가 만들어진다. 이 이벤트로 인해 Dynamic Host Configuration Protocol (DHCP) 작업이 이를 설정하면서 network-interface-up 이벤트를 만든다. 기본 루트가 새로운 인터페이스로 할당되면, default-route-up 이벤트가 나온다. 여기서부터, 네트워크 인터페이스(메일 서버 또는 웹 서버)를 필요로 하는 작업들이 자동으로 시작(중지-인터페이스가 없어질 경우)한다.

Upstart 사용하기

upstart 구현과 설치는 단순하고 전형적인 configure, make, make install 패턴을 따른다. Upstart는 전형적인 init 설정 runlevel과 호환되는 작업들을 제공한다. initng와 마찬가지로, 새로운 애플리케이션들은 요구 사항에 따라 작성된 고유의 작업들을 갖고 있다. (새로운 이벤트를 추가할 가능성도 있다.) 이 같은 경우, 새로운 init 시스템을 전개하는 것에는 위험 요소가 따른다. 하지만 upstart가 제공하는 장점에 비하면 이러한 위험 부담은 아무것도 아니다.

위에서 설명한 것처럼, initctl 유틸리티는 telinit의 기능을 제공한다. 하지만 initctl은 트레이싱과 디버깅을 위한 추가 기능도 제공하고 있다.

위로

기타 옵션들

두 가지 옵션들(initng와 upstart) 뿐만 아니라, runit, pardus, minit, einit 같은 기타 init 대안들도 있다. 이 모두가 리눅스 커뮤니티의 지원을 받고 있다. 이 중, upstart는 대중적인 Ubuntu 배포판의 init 대안으로서 채택되었기 때문에 주목할 만 하다. (참고자료)

위로

bootchart를 사용한 init 성능 모니터링

시스템 부팅 프로세스를 변경할 경우, 무엇이 변경되었고, 이것이 전체적인 부팅 시간에 어떤 영향을 주는지를 파악하는 것이 필요하다. Ziga Mahkovec은 부팅 프로세스를 나타내는 bootchart라는 유용한 툴을 개발했다. 이 툴은 데이터 로거 유틸리티와 시각화 유틸리티를 포함하여 여러 요소들로 구성된다.

데이터 로거(bootchartd)는 init 프로세스 대신 실행된다. (주로, grub 또는 lilo.conf 파일에서 지정된다.) bootchartd가 초기화 된 후에, 컨트롤을 실제 init 프로세스(/sbin/init)에 넘긴다. Bootchartd는 주기적인 간격(기본적으로 200MS 마다 한번씩)로 이 환경을 샘플링 하는 프로파일러이다. 이 환경을 샘플링 함으로써, 현재의 CPU 통계, I/O와 유휴 시간, 디스크 사용, 모든 활성 프로세스 관련 정보(proc 파일 시스템 사용)를 읽을 수 있다. 데이터는 포스트 프로세싱(post-processing)을 위해 임시 파일(/var/log/bootchart.tgz)에 저장된다.

Bootchart는 포스트 프로세싱을 사용하여 미가공 데이터를 부트 차트(boot chart)로 변형한다. 이 프로세스는 자바™ 애플리케이션(bootchart 배포판의 일부)을 사용하여 로컬에서 발생하지만, 더 쉬운 방법은 bootchart 홈 페이지에 있는 웹 폼을 사용하는 것이다. 부트 차트(boot chart)의 모습은 그림 2에 묘사되어 있다. 이 차트는 약간 커지는 경향이 있다. (시작된 서비스와 애플리케이션에 따라 다르다.) (참고자료)

위로

요약

리눅스와 마찬가지로, 부팅 시간 최적화에도 많은 옵션들이 있다. initng 같은 종속 관계 기반 솔루션부터 upstart 같은 이벤트 기반 솔루션까지, 여러분의 필요에 맞는 최적화 솔루션들이 존재한다. bootchart 패키지를 사용하여, 시스템이 어떤 부분에서 시간을 많이 소비하는지를 알고, 이를 최적화에 적용할 수도 있다.

기사의 원문보기

• Parallelize applications for faster Linux booting

참고자료

교육

• developerWorks 기술자료 - differentiating UNIX and Linux.
  
  
• runlevels (Linux)
  
  
• 한국 developerWorks 리눅스 존: 리눅스 개발자들의 기술자료 더 보기
  
  
• developerWorks 기술 행사와 웹캐스트
  
  

제품 및 기술 얻기

• 차세대 init system (initng): 종속 관계 기반 방식
  
  
• Ubuntu upstart 시스템: 이벤트 기반 방식
  
  
• Bootchart : 부팅 프로세스를 취한 성능 분석 및 시각화 툴
  
  
• einit 패키지: Extensible Markup Language (XML)를 사용하는 초기화 스크립트
  
  
• Pardus : init 병렬화 스킴.
  
  
• runit 패키지: 서비스 감시
  
  
• minit 패키지: init 시스템의 소형 버전. sysvinit 소스.
  
  
• Order the SEK for Linux: 리눅스용 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 최신 IBM 시험판 소프트웨어를 두장의 DVD에 담고 있다.
  
  
• IBM 시험판 소프트웨어(한국 developerWorks)
  
  

토론

• developerWorks 블로그와 다양한 한국 developerWorks community 참여하기
  
  

필자소개

M. Tim Jones는 임베디드 소프트웨어 아키텍트이며, GNU/Linux Application Programming, AI Application Programming, BSD Sockets Programming from a Multilanguage Perspective의 저자이기도 하다. 정지 우주선용 커널부터 임베디드 시스템 아키텍처와 네트워킹 프로토콜 개발까지 광범위한 개발 경험을 갖고 있다. 현재 Emulex Corp. (Longmont, Colorado)의 자문 엔지니어이다.

아티클 순위

의견

위로

목차

• 리눅스 부팅의 주요 단계
• Init 데몬 교체
• Initng
• Upstart
• 기타 옵션들
• bootchart를 사용한 init 성능 모니터링
• 요약
• 참고자료
• 필자소개
• 의견