본문 : http://www.ischo.net -- 조인상 //시스템 엔지니어

+++++++++++++++++++++++++++++++++++++++++++++++++++++++


출처 : http://www.systemadmin.pe.kr



시스템 초기화란 시스템에 전원을 인가한 후 boot 프로그램을 통해 OS가 메모리로 로드되는 과정을 말한다. 시스템 초기화 과정을 시스템 관리자가 알아 두어야 할 이유는 장애가 발생한 경우 문제 해결의 실마리를 알아 내는데 도움이 되기 때문이다. bootstraping이라고도 알려진 boot 처리는 사용자가 시스템을 사용할 수 있도록 커널을 메모리에 로드하는 여러 단계들로 구성되어 있다.

인텔기반 시스템을 예로 들면, 시스템 BIOS는 일련의 POST(Power-on Self-Tests)라 부르는 작업을 수행한다. 우리가 부트 디스크라 부르는 하드 드라이브에서 시스템이 기동한다는 사실을 잘 알고 있다. 이때 시스템은 액티브 파티션으로 지정된 디스크에 있는 fdisk 테이블을 검사한다. 이 시점 까지는 OS와는 아직 무관한 단계이다. 즉 우리가 주로 사용하는 OS인 DOS, NT, UNIX가 아직 작동하지 않는 단계란 말이다. 액티브 파티션이 지정될 때 시스템은 partition boot 코드를 로드하게 된다.


UnixWare의 기동


UnixWare가 부팅하는데 필요한 정보와 파일들을 boot 파일이라 부르는데, 주로 boot와 /stand에 위치하고 있다. 여기서 언급하는 boot란 boot 프로그램을 포함하고 있는 UnixWare 파티션에 있는 slice이지 파일시스템은 아니다. 주 기능은 커널 즉 unix 파일을 부트하게 만들고 위치를 지정해 주는 것이다. /stand는 bootable OS라 부르는 unix 파일이 있는 장소이고 부트가 진행되는 동안 사용되는 모든 프로그램과 bootable data 파일들이 있는 곳이다. 이를 확인 하는 방법은 디스크의 정보를 알 수 있는 명령어로 ‘prtvtoc’이 있다.

[#]prtvtoc /dev/rdsk/c0b0t0d0s0
slice 0: DISK permissions: VALID UNMOUNTABLE starting sector: 63 (cyl 0) length: 7100667 (442.00)
slice 1:ROOT permissions:VALID starting sector: 321299 (cyl 19) length: 6683040 (416.00)
slice 2:SWAP permissions: VALID UNMOUNTABLE starting sector: 64259 (cyl 3) length: 257040 (16.00 c)
slice 7: BOOT permissions: VALID UNMOUNTABLE starting sector: 63 (cyl 0) length: 34 (0.00 cyls)
slice 8:ALT SEC/TRK permissions: VALID UNMOUNTABLE starting sector: 97 (cyl 0) length: 15968 (0.99 cyl)
slice 10: STAND permissions: VALID starting sector: 16065 (cyl 1) length: 48194 (3.00 cyl)
slice 15:VOLPRIVATE permissions: VALID UNMOUNTABLE starting sector: 7004339 (cyl 435) length: 16065 ()

slice 7로 명시된 부분이 boot slice 부분이고, 파티션 boot 코드가 로드가 된 후에 OS가 로드하기 시작한다. Boot 처리를 제어하는 커널과 파일들은 /stand 파일시스템에 상주하고 있다. /stand 파일시스템은 특정 디바이스 파일들도 없고 서브디렉토리도 없는 간단한 bfs 파일 시스템이다.

현재 설정되어 있는 파일 시스템 종류와 같은 정보를 알아 보는데는 /etc/vfstab 파일에 담겨져 있으므로 아래와 같이 확인하여 보면 된다.

[#]vi /etc/vfstab
/dev/root /dev/rroot / vxfs 1 no mincache=closesync SYS_RANGE_MAX
/dev/stand /dev/rstand /stand bfs 1 no - SYS_RANGE_MAX


/stand 디렉토리

이 디렉토리에는 boot 처리를 제어하기 위한 커널 파일들이 들어 있다. 아래에 해당 파일들의 리스트이다. 이중에 알아 두어어야 할 몇가지만 언급하겠다.

[#] stand:>ls
bfs.blm dcmp.blm license resmgr stage3.blm boot hd.blm logo.img resmgr.sav unix bootmsgs help.txt platform.blm smallfs.blm unix.old

확장명이 .blm인 파일들은 boot-loadable module들이다. 특히 stage3.blm은 UnixWare7 boot 프로그램 이다. slice 7에 있는 bootstrap에 stage3.blm이 있다. 이를 확인 해 볼려면 바이너리 코드를 보는 명령어인 ‘strings’ 명령어로 확인해 보면 된다.

[#]strings /dev/rdsk/c0b0t0d0s7|more
dcmp.blm
stage3.blm
b_driver

strings란 명령어로 그 내용을 추적하여 보면 위의 스트링들이 존재함을 알 수 있다.

root 디스크의 슬라이스7 번째에 boot-loadable 모듈에 위의 항목이 있음을 알 수 있다. 우리가 ‘fdisk’ 명령어로 파티션을 나누면 firmware 레벨에서 시스템을 initialize하기 위해(이 부분은 ROM BIOS의 역할) boot-loader가 동작하도록 active partition을 지정해 준다. 그러면 OS가 부팅하기 위해 해당 boot-loadable 모듈을 특정 슬라이스에 심어 놓는데 이 부분이 바로 UnixWare7에서는 slice 7에 해당되는 것이다.

boot 절차

부트 프로그램은 stand-alone 프로그램들과 UnixWare Kernel을 로드하고 실행시킨다. Stand-alone 프로그램은 OS가 동작하기 전에 실행되며, 그래서 OS가 제공하는 서비스들과는 무관하다.

UnixWare 시스템 설치 동안에는, boot 프로그램은 active 파티션의 로지컬 블록 0에서 시작하는 하드 디스크(일반적으로 root 디스크라고 부름)에 놓이게 된다. boot 절차는 시스템이 부팅된 매번 일어나며, 처음에 플라피 디스크를 검색하고 없으면 하드 디스크에 있는 내용을 수행한다.

플라피 디스크 부트 절차:
1. 파일 시스템의 0 섹터에 있는 부트 블록이 boot를 로드한다.
2. boot는 UnixWare kernel을 로드하고 실행한다.

하드 디스크 부트 절차:
1. 시스템 firmware는 하드 디스크의 절대 섹터(absolute sector) 0으로부터
master boot를 로드한다.
2. masterboot는 active 파티션으로부터 파티션 boot 프로그램을 로드한다.
3. boot의 나머지가 /stand로 부터 로드된다.

/stand/boot 파일

처음 시스템이 부팅될 때, 다음 메시지가 나오는 순간이 있다.

Starting UnixWare...

이 시점에서 부팅을 일시 중지시켜 시스템 작업을 할 수 있는데, 이때 BCP(Boot Command Processor)가 기동된다. BCP를 이용하여 파라미터를 추가 및 수정도 할 수 있다. 기본적인 boot 파일의 내용은 다음과 같다.
[#]stand:>cat boot
BLM=hd.blm
files=resmgr,license
rootfs=vxfs
TZ_OFFSET=-32400

boot 파일 파라미터들은 “/stand/boot” 파일에 적용시켜도 되고 boot 프롬프트 상태에서 수동으로 입력시켜도 적용된다. 다음에는 시스템 관리에 유용한 몇 가지 파라미터들을 서술 하겠다. boot 프롬프트 상태로 전환되려면 시스템을 리부팅 시켜야 한다. 리부팅 초기에 메모리를 초기화하고, 프라세서를 초기화하고, SCSI 디스크를 초기 프로빙하는 메시지가 끝나자마자 공백화면에 커서가 나오면 이때 스페이스 키나 엔터 키를 몇 차례 누른다(실지로는 UnixWare7 logo가 보일 때 적용되지만 기회를 놓칠 수 있기 때문). 그러면 다음 메시지를 화면에서 볼 수 있다:

Bootstrap Command Processor
Ready for boot commands … [ ? for help]
[BOOT]

옵션값을 실행시키려면 “go”, “boot”, ‘b” 중에 아무 것을 사용해도 된다. 부트 옵션을 변경하고자 할 때 값을 어떻게 적용시켜야 할지 잘 모를 때에는 ‘show -a’ 명령어를 이용하면 현재의 설정 값을 알 수 있으므로 값을 어떻게 적용할지를 쉽게 알 수 있다.

[BOOT] show BOOTDEV ; 하고 엔터키를 치면 현재 설정 값을 알 수 있음.
BOOTDEV=hd(0,2)

이때 “show param= 파라미터”를 입력하여 주면 파라미터를 추가할 수 있다.
“show –a” 하면 모든 파라미터 및 메시지를 보여준다.

Boot 파일 파라미터

/etc/boot 파일에 추가할 파라미터들을 알아보자.

BOOTPROG=filename filename 칸에다가 부트하는 동안 로드될 프로그램을 입력한다. 현재 적용되어 사용되는 유닉스 커널은 “/stand/unix” 파일이나, 만약 새로운 커널에 문제가 발생되어 부팅이 안될 때 이전 커널로 부팅해야 한다. 이전 커널은 “/stand/unix.old”란 파일로 항상 존재한다. 커널이 수정될 때는 반드시 수정전의 현제 커널을 다른 이름으로 복사한 다음에 작업해야 한다.

[#]cp /stand/unix /stand/unix.org ; 문제 발생시 이전 커널로 부팅해야
하므로

예) 시스템을 리부팅 하다가 boot 프람프트 상태로 빠진다.

Bootstrap Command Processor
Ready for boot commands ……[ ? for help]
[BOOT] BOOTPROG=unix.org
[BOOT] go

INITSTATE=sysstate 부팅된 후의 시스템 run level 상태를 정의함. 이 파라미터는 /sbin/init 실행
파일로 전달이 되고 /etc/inittab 파일에 있는 initdefault 라인에 있는 시스템
run level을 오버라이드한다. 아래에는 run level이 3 으로 되어 있다 할지라
도 예에서 single mode로 해주면 오버라이드 된다는 의미이다.

[#]cat /etc/inittab
is:3:initdefault: ; 3이 run level이 됨

이 파라미터는 네트웍상의 문제나, 비디오 드라이버의 오류, 그래픽
화면 로그인 실패로 인해 부팅이 안될 때 Single user로 로그인 하여
문제를 해결하고자 할 때 유용한 옵션이다.

예) [BOOT] INITSTATE=S ; single-user로 부팅하고자 할 때
[BOOT] boot

AUTOBOOT=YES|NO|num 이 파라미터는 boot가 커널을 어떻게 로드할 것인 가를
지정할 때 사용. 명시하지 않으면 디펄트 값이 적용되므로
디펄트는 5 초 대기하다 부팅을 개시한다.
YES는 커널을 로드하자마자 boot가 시작된다.
No는커널이 로드되자 마자 BCP를 입력하라는 의미.
num은 커널이 로드된후 boot하기 위해 대기하는 시간.

TIMEOUT=number 자동 부팅하기전에 대기할 초단위의 시간.

BLM=filename[,filename ...] boot내로 로드될 Bootstrap Loadable Module들을 지정하는
파라미터. BLM 파일들은 filename이 디바이스를 명시하지
않으면 STARTDEV로 부터 로드 된다.

ENABLE_4GB_MEM=(YES|NO) YES를 선택하면 4GB 이상의 메모리 감지를 가능하게 해줌.

ROOTFS=fstype 커널로 빌드된 디폴트 root 파일 시스템 타입을 오버라이드
하게 허용하며, 정의되어 있지 않으면 vfstab에 정의된
타입을 사용한다.

CONSOLE=device(minor[,param]) 디폴트 콘솔 디바이스를 오버라이드: CONSOLE=kd(0).
COM1과 COM2등으로 콘솔을 리다이렉트(redirect) 시킬 수
있다. iasy는 시리얼 포트 디바이스를 지원하고, minor는 0 ~15까
지 지원한다.
예) CONSOLE=iasy(5,B9600) ; /dev/term/01h 디바이스의 minor #가 5이고 9600의 baud
rate에서 hardware flow control 디바이스를 콘솔로 설정

DISABLE_CACHE=(YES|NO) YES 라면 내부 및 외부 캐쉬 사용을 억제한다.

INITFILE=filename 부트할 때 init로 전달된 파일로, 디폴트는 /etc/inttab이다.
임의로 정의한 파일로 기동될 수 있게 하여준다.

/stand/bootmsgs 파일

부트하는 동안의 모든 메시지가 이 파일에 저장된다. 그 내용은 다음과 같다:

[#] /stand:> cat bootmsgs
BOOTMSG1=Starting UnixWare...
BOOTMSG2=Bootstrap Command Processor\
Ready for boot commands... [? for help]\

TITLE=UnixWare 7, based on UNIX System V Release 5 from SCO
COPYRIGHT=Copyright (c) 1976-1998 The Santa Cruz Operation, Inc. and its suppliers.\
All Rights Reserved.\
\
RESTRICTED RIGHTS LEGEND:\
\
When licensed to a U.S., State, or Local Government, all Software produced\
by SCO is commercial computer software as defined in FAR 12.212, and has\
been developed exclusively at private expense. All technical data, or SCO\
commercial computer software/documentation is subject to the provisions of\
FAR 12.211 - "Technical Data", and FAR 12.212 - "Computer Software"\
respectively, or clauses providing SCO equivalent protections in DFARS or\
other agency specific regulations. Manufacturer: The Santa Cruz Operation,\
Inc., 400 Encinal Street, Santa Cruz, CA 95060.
AUTOMSG=Automatic Boot Procedure
REBOOTMSG=Press any key to reboot...
STARTUPMSG=The system is coming up. Please wait.
RMEM=bytes of memory were detected.
UMEM=bytes of memory are in use.
PMEM=bytes of memory are in the page pool.
DMEM=bytes of memory are dedicated.

/stand/resmgr 파일

/sbin/resmgr 실행 파일은 Resource Manager Database를 표시하여주고 갱신하는데 사용되는 명령어이다. 대부분의 사용자들은 DCU(Device Configuration Utility)를 사용하여 in-core Resource Manager database 와 상호작용 한다. resmgr 명령어는 주로shell script들과 debugging에 주로 사용된다.

/stand/resmgr 파일은 바이너리 데이터 파일이며, 이전 복사본은 resmgr.sav에 저장된다. 이 파일은 부팅될 때 읽혀지며 시스템상에 구성된 디바이스 하드웨어와 소프트웨어의 상세 부분을 포함하고 있다.

간혹 디스크를 빼내고, 레이블링이 다시되고 이동되는 경우 원래의 디바이스 구성정보들이 resmgr 파일에 저장되어 있어서 디바이스가 교체되더라도 이전의 정보(일명 ghost name라 함) 를 가지고 있어 변경이 안되는 경우가 있다. 이럴 경우 콘솔에서 아래와 같이 재구성 작업을 해주어야 변경이 된다.

# cd /stand
# cp resmgr resmgr.sav
# for i in ‘resmgr | grep vtoc | sed -e ‘s/.*//’
do
resmgr -k $i -r
done
# vi /etc/device.tab
(optional) removes duplicate disk entries
# /etc/conf/bin/idconfupdate -f
#init 6

작업시 참조하는 명령어로는 sdighost가 있다.

Sdighost 명령어

Ghost name과 관련된 디바이스 노드들을 리스트하거나 제거하는데 사용된다.


/stand/unix 파일

모든 유닉스들은 커널이라 부르는 파일이 존재하며, UnixWare 7에서도 /stand/unix라는 실행파일을 커널이라 부른다. 우리가 외관상 커널 파라미터라 부르는 파일들은 /etc/conf/cf.d 디렉토리 밑에 mtune, stune란 파일들로 정의되어 있다. mtune 파일은 마스터 튜닝 파일로 대부분의 커널 파라미터를 정의되어 있는 곳이며, stune은 mtune에 있는 파라미터의 값을 변경하고자 할 때 여기에 정의하여 사용한다. 이 파일들 이외에도 다른 곳에 정의된 파라미터 값들이 어우러져 컴파일 되면 /etc/conf/cf.d/unix란 실행 파일이 만들어 진다.

리부팅이 되면 새로운 커널이 적용되는데, 이때 /etc/conf/cf.d/unix가 /stand/unix로 복사가 되어 새로운 커널로 자리잡는다. 그러면 부팅할 때 기존에 있던 커널을 /stand/unix.old로 복사한다. 자세한 내용은 커널 및 튜닝 편에서 다루겠다.

init과 inittab

일단 OS 초기 로드가 완료되면 즉 커널이 로드 됨에 따라, boot는 init이라 부르는 프로세스를 작동시킨다. init의 PID는 항상 1 이다. init 프로세스는 프로세스들을 기동(spawn) 시키는 역할을 담당하는데, 모든 다른 프로세스의 부모(parent)로 알려져 있으며 user 프로세스가 아닌 system 프로세스 즉 시스템 데몬을 기동 시키는 프로세스를 말한다.

init은 process spawner이기 때문에 “/etc/inittab” 파일에 저장된 정보를 가지고 프로세스들을 생성시키는 역할을 하고 있다. “/etc/init” 실행 파일을 분석해 보면 “inittab”을 동작시킴을 알 수 있다.

[#]:>strings /etc/init|more
/etc/inittab

디펄트 inittab 파일은 “/etc/inittab” 이다. 물론 다른 이름으로 변경시키는 것도 가능하나 이렇게 하려면 “/stand/boot” 파일에 등록을 해 주어야 한다. 그 이유는 부트할 때에 디펄트 파일인 “/etc/inittab” 파일을 찾게 되어 있기 때문이다. 아래와 같이 임의의 파일에 “inittab”과 같은 내용의 파일을 만들어 주고 등록해 주면 된다.

[#]vi /stand/boot
INITFILE=/etc/inittab.file

작업하기 전에 “inittab” 파일을 복사해 두는 것이 좋다. 시스템과 관련된 파일을 수정 할 때에는 반드시 그 복사본을 만드는 습관이 중요하다. 시스템 복구에 중요한 관건이 되기 때문이다. 시스템 사용 중에 “inittab” 파일을 실수로 삭제하였을 때 “Cannot start /etc/inittab”란 에러 메시지가 콘솔에 계속 디스플레이 될 것이다. 이때 복사본도 없을 때에는 “/etc/conf/init.d/kernel” 파일이 같은 내용이나 그 역할을 대신해 주지 않으므로 복사해 와야 한다. 아니면 파일 내용중의 필요한 일부만 복사해 오면 된다.
[#]cp /etc/conf/init.d/kernel /etc/inittab

항상 시스템과 관련된 파일을 복사를 한 후에는 반드시 owner, group, permission등을 원래의 것과 같은 특성으로 맞추어 주는 습관을 길러야 한다.

아래에 있는 “inittab” 파일의 디펄트 값으로 맞추어 주면 된다.
[#]ls -al inittab
-r--r--r-- 1 bin bin 2867 Jul 28 14:34 inittab
[#]ls -al /etc/conf/init.d/kernel
-rw-r--r-- 1 root sys 2656 Jul 28 14:15 /etc/conf/init.d/kernl


이제 inittab의 내용을 살펴보자. 대략 알아두면 유용한 몇 가지만 언급하기로 하자. inittab은 init에 의해 처리되는 프로세스들을 열거해 놓고 있다. 여기에 정의되어 있는 프로세스들은 주로 시스템 데몬들이며, 되도록 일반 사용자가 만든 프로세스를 여기에 입력해 놓지 말아야 한다. 사용자가 만든 프로세스를 입력시켜 놓으면 시스템에 장애를 일으킬 수 있기 때문이다. 가령 시스템이 부팅하지 않거나 부팅이 되더라도 콘솔에 에러 메시지를 계속 뿌려주기 때문이다. 하지만 가능하지 않는 것도 아니라는 것이다. 주로 데몬이다 보니까 우리가 “#ps –ef” 하였을 때 보이는 프로세스도 있고 없는 것도 존재한다. 그 이유는 여기에 사용된 데몬들은 필요에 따라 메모리에 로드 되었다가 자기 작업을 수행한 후 즉시 빠져나가기 때문이다.

/etc/ inittab 파일

[#]cat /etc/inittab
swp1::sysinit:/sbin/swap -a /dev/swap >/dev/sysmsg 2>&1
cr::sysinit:/sbin/ckroot >/dev/sysmsg 2>&1
swp2::sysinit:/sbin/swap -c >/dev/console 2>&1
bchk::sysinit:/sbin/bcheckrc </dev/console >/dev/console 2>&1
is:3:initdefault:
r0:0:wait:/sbin/rc0 off >/dev/console 2>&1 </dev/console
r1:1:wait:/sbin/rc1 >/dev/console 2>&1 </dev/console
r2:23:wait:/sbin/rc2 >/dev/console 2>&1 </dev/console
r3:3:wait:/sbin/rc3 >/dev/console 2>&1 </dev/console
sd:0:wait:/sbin/uadmin 2 0 >/dev/console 2>&1 </dev/console
fw:5:wait:/sbin/uadmin 2 2 >/dev/console 2>&1 </dev/console
rb:6:wait:/sbin/uadmin 2 1 >/dev/console 2>&1 </dev/console
sc:234:respawn:/usr/lib/saf/sac -t 300
d2:23:wait:/sbin/dinit >/dev/console 2>&1 </dev/console

구성은 콜론으로 구분되며 “Id: Run-level: Action: Process” 순이다. 각각의 한 라인을 엔츄리라 부르며, 한 엔츄리에 512 문자 까지 입력되며 다음 라인으로 넘어갈 때에는 백 슬래쉬( \ )를 사용하면 된다. 엔츄리 수에는 제한이 없다.

다음에는 엔츄리를 구성하는 요소들을 설명 하겠다.

Id 최대 4 문자까지 기술되며 유일한 단순 식별자. 이름을 변경시켜도
시스템에 특별한 영향을 안 미치는 경우도 있고, 유일한 식별자라
하지만 같은 이름을 주어도 아무 이상이 없는 경우도 있었다.역할은
테이블에 있는 프로그램이 기동 되고 중지될 때 마다 /etc/wtmp로
엔츄리를 init이 기록하게 하는데, 무엇인지를 식별하는 이름으로
이용된다고 이해를 하면 된다. 확인 방법은 ‘#strings /etc/wtmp|more’를
이용하라. inittab 파일에 있는 여러 이름들이 들어 있음을 알 수
있을 것이다.

Run-level init이 엔츄리를 실행하는 레벨을 언급하고 있으며, 명시된 레벨에서
이 프로세스가 실행된다는 의미이다. 여기에서 사용되는 run-level
범위는 0 ~6까지가 사용된다. 23이라면 run level 2에도 3에서도 구동
된다는 말이다. init이 run level을 변경하라는 요청을 받으면, 요청된
level을 갖고 있지 않는 프로세스들은 warning signal인 SIGTERM이
전송되며 kill signal인 SIGKILL에 의해 강제로 종료되기 전에 5초의
유예시간을 준다. Run-level이 명시되지 않으면 모든 run-level을
수용한다는 의미이다.


Action init이 취하는 동작을 지시하는 키워드
sysinit init이 호출될 때만 해당 엔츄리들을 검색하여 동작을 시키고, 아닐
때에는 대기하고 있다. 그래서 이 프로그램은 시스템 초기화와 관련
있다. 그리고 콘솔을 액세스 하기 전에 실행하라는 의미도 있다.

initdefault 디펄트 시스템 상태를 지정해줌. init이 호출될 때만 해당 엔츄리를
검색하여 동작을 시킨다. run-level이 명시되면 지정된 run- level로
부팅하라는 의미이다. 만일 run-level에 아무 것도 명시하지 않으면
시스템은 0123456으로 인식하여 리부팅을 계속 반복(init 6를 계속
반복하는 것과 같은 결과) 할 것이다. 그리고 아예 init이 “inittab”에
“initdefault” 엔츄리를 찾을 수 없다면 리부팅 할 때에 run-level을
무엇으로 할 것인가를 물어 본다.

respawn 프로세스가 떠 있지 않으면 자동으로 시작하라는 의미이다. 그래서
respawn으로 언급되어 있는 엔츄리는 ‘#ps –ef” 했을 때 항상 존재
해야 한다. Inittab 파일을 계속 검색하고 있기에 이에 해당하는
프로세스가 없다면 무언가 문제가 있다고 보면 된다.

wait 현제의 프로세스가 끝나야지만 다른 프로세스가 정상 작동하는
경우에 사용한다. 이 곳에 언급된 작업이 끝날 때까지 다음 엔츄리
에 있는 작업은 대기하고 있으라는 의미이다.

once init이 엔츄리에 언급된 run-level을 만날 때, 프로세스를 시작하라.
그러나 프로세스가 종료할 때 까지 기다리지는 말라는 의미이다.
그리고 프로세스가 죽으면, 그 프로세스를 재 기동 시키지는 마라.
init이 새로운 run-level로 변경된다 할지라도, 이전의 내용 그대로를
유지하고 프로그램은 재기동 시키지 말라는 의미이다.

powerfail init이 power fail signal인 SIGPWR을 수신했을 때만 이 엔츄리와
관련된 프로세스를 실행하라. 그리고 프로세스가 종료될 때 까지
기다리지는 마라.

powerwait init이 power fail signal인 SIGPWR을 수신했을 때만 이 엔츄리와
관련된 프로세스를 실행하라. 그리고 프로세스가 종료될 때 까지
대기하고 있으라는 의미.

Run-level 결정

시스템이 부팅될 때 부팅될 run-level의 결정은 아래에 있는 파일의 엔츄리에서 해준다.

[#] cat /etc/inittab
is:2:initdefault:

시스템이 부팅할 때 run level을 자동으로 결정해주려면, 위의 예제를 보면 두번째 컬럼에 있는 숫자에 따라 결정이 된다. 그러나 커널을 컴파일할 경우 주의 해야 할 사항이 있다.

“/etc/conf/init.d/kernel” 파일은 “/etc/inittab”과 같은 내용이기는 하나 단순한 복사본이라 할 수 없다. 커널을 리빌드(rebuild) 하고 변경된 커널값이 시스템에 적용하려면 리부팅을 해주어야 하는데, 이때 “/etc/conf/init.d/kernel”의 내용이 “/etc/inittab” 파일을 업어치기(overwrite) 때문이다. 그래서 “/etc/conf/init.d/kernel”에 run-level을 변경시켜 주어도 커널을 리빌드 안하고 리부팅만 하면 run-level에는 적용이 되지 않는다.

결과적으로 부팅할 때 자동으로 run-level을 바꾸고자 할 때에는 단지 “/etc/inittab”에 있는
파일에만 적용시켜 주면 된다.

d2:23:wait:/sbin/dinit >/dev/console 2>&1 </dev/console

로그인 후에 multi-user 환경을 위하여 수행되는 명령어들을 동작시키는 역할을 한다. 멀티 유저 상태(주로 run-level 2와 3 )로 전환할 때 시스템 기동의 성능을 개선하는 것이 “/sbin/dinit” 실행 파일의 목적이다.

Run-level

시스템은 8 종류의 시스템 상태에서 동작할 수 있다. 시스템 상태(system status)란 선택된 프로세스들 그룹만이 존재하도록 설정된 조건 하에서 시스템의 소프웨어적인 구성을 말한다. 이들 시스템 상태 각각에 대하여 init에 의해 기동된 프로세스들은 inittab 파일에 정의되어 있다. init은 이들 각 상태로 전환시켜 주는 명령어라 여겨도 무방하다. 가장 많이 사용되는 시스템 상태는 0, 2, 3, 6, S 이다. 이 명령어들은 일반 사용자 권한이 아니라 root 권한을 갖는 사용자만이 사용가능하다.

아래에 각각의 run-level 상태로 전환하는 방법과 의미에 관하여 알아보자.

#init 0 시스템의 전원을 내릴수 있는 상태로 전환시키는 명령어이다. 시스템의 전원을
끄고 작업을 하여야 할 때 사용된다. 일반적으로 이 명령어를 사용하기 전에
우선 사용중인 DB나 사용자 프로그램을 끊고 프로세스의 상태를 확인하는
명령어인 ‘#ps –ef ’로 관련 프로세스들이 정상적으로 죽었는지를 반드시 확인
하여야 한다. 그러나 시스템 다운될 때 자동 다운될 수 있도록 스크립트를
만들어 놓았다면 굳이 확인할 필요는 없다.
#init 1 시스템을 시스템 관리 상태로 전환시킨다. 특정 프로그램 패키지를 깔 때
사용하면 편리하다. 모든 파일 시스템은 그대로 마운트되며, 시스템의 기본적인
커널 프로세스들만이 동작한다. 모든 파일로의 액세스는 가능하나 일반 사용자
로그인은 안된다. 잘 사용안하는 시스템 상태이다.
#init 2 시스템을 multiuser-mode로 전환시키며, multiuser 환경의 터미널 프라세스와 데몬
들이 기동된다. 대부분의 시스템 리소스들을 이용가능한 상태라 할 수 있다.
/etc/vfatab에 있는 모든 것을 마운트 시킨 상태. 네트웍을 통한 리모트 리소스를
사용하지 않을 때, 일반적으로 가장 많이 이용되는 시스템 상태이다. 그리고
/etc/rc2.d 디렉토리 밑에 있는 스크립트들이 수행된다.
#init 3 리모트 파일 공유 프로세스들과 데몬들이 시작된다. 주로 리모트의 리소스를
사용할 수 있게 하여 주며, 시스템 상태 2의 확장개념으로 네트웍의 nfs 관련
기능이 추가된 networking state로 알려져 있기도 하다. 멀티유저 환경으로 구축
할 때 시스템 환경에 맞게 DB나 NFS를 구동시킬수 있게 함.
#init 4 run-level 3와 유사하며 일반적으로 사용하지 않는 시스템 상태.
#init 5 OS가 멈추고 f/w(firmware) 모드로 빠짐. 되도록 사용하지 말 것.
#init 6 시스템을 리부팅 시킬 때 가장 많이 사용되는 시스템 상태로, /etc/inittab 파일에
나타난 initdefault 항목에 적혀진 상태로 리부팅됨. 주로 변경된 시스템 내용을
새로 적용시키거나, 프로그램을 설치하였거나, 좀비 프로세스를 제거하기 하기
위해 등등의 다양한 목적으로 이용할 때 사용된다. 물론 이때에도 ‘init 0’ 할때
처럼 DB나 사용자 프로그램을 죽이고 하는 것이 원칙이다.
#init q/ Q /etc/inittab에 정의된 것들을 현재 정의된 내용들로 새로 적용시킬 때 사용
한다. 특별히 변경된 내용없이 실행시키면 일반 사용자는 ‘#init q’를 했는지
인식하지 못한다.

#init s/S singleuser-mode. 현제 마운트되어 있는 화일 시스템이 살아있는 상태에서, 단지
init에 의해 기동된 프라세스들만 죽인다. 만일 콘솔이 아닌 일반 터미널에서
이 명령어를 실행시켰다면, 일반 터미널이 /dev/syscon으로 링크되어 시스템
콘솔이 된다. 이 명령어에 의해 나타나는 시스템의 상태는 항상 같다고 볼 수
없다. 경우에 따라 마운트된 파일 시스템이나 프로세스들이 다르게 나타날 수도
있다는 말이다.

현재의 run-level을 알아보는 방법은 아래와 같으며, 맨 앞의 숫자 2가 현재의 run-level을
나타낸다:

[#] who -r
. run-level 2 Aug 30 15:18 2 0 S

이외에도 시스템 상태를 바꾸는 명령어로 shutdown이 있는데, 주로 run-level 2 상태에서 다른 시스템 상태로 전환시키는데 이용된다. init 명령어는 시스템을 죽이는데 별다른 메시지 없이 죽이기에 실수를 할 수도 있지만, shutdown 명령어는 관련 경고 메시지를 콘솔에 뿌려주기 때문에 자신이 무슨 일을 하고 있는지 상기 시켜주는 효과가 있다. 일반으로으로 시스템을 죽이라 할 때, 셧다운 시키라고 말한다. 이 상태가 바로 전원을 꺼도 되는 run-level 0 상태를 말한다.

기동 디렉토리

init이 inittab을 읽어서 그 내용을 수행할 때, 각각 inittab의 내용에 따라 /sbin 디렉토리 밑에 있는 rc와 dinit로 시작하는 스크립트들을 구동시킨다. 이들 파일은 또 /etc 디렉토리에 있는 파일들과 링크되어 있다.
[#] sbin:>ls -al rc*
-rwxr--r-- 2 root sys 3746 Apr 8 1998 rc0
-rwxr--r-- 1 root sys 2177 Mar 6 07:31 rc1
-rwxr--r-- 1 root sys 3243 Apr 8 1998 rc2
-rwxr--r-- 1 root sys 1571 Apr 8 1998 rc3
-rwxr--r-- 2 root sys 3746 Apr 8 1998 rc6
-rwxr--r-- 1 root sys 2186 Mar 6 07:31 dinit


이들 스크립트에 따라 rc0는 /etc/rc0.d 디렉토리, rc1는 /etc/rc1.d 디렉토리, rc2는 /etc/rc2.d 디렉토리, rc3는 /etc/rc3.d 디렉토리, dinit는 /etc/dinit.d 디렉토리와 관련되어 동작한다. 이들 디렉토리에 있는 파일들을 필요없다고 삭제하지 말고 대문자 S는 소문자 s로, 대문자 K는 소문자 k로 변경시켜 놓고 사용하여야 한다. 소문자로 시작하는 스크립트들은 실지로 실행은 안된다는 의미이다. 대문자 S는 스크립트를 starting 시킨다는 의미이고, 대문자 K는 stopping 시킨다는 의미이다. 반드시 대문자로 시작하는 S와 K로 시작하는 스크립트들만 이들 디렉토리에서 작용한다.

특정 run-level에서 스크립트가 기동되기를 원한다면, 해당 디렉토리에 스크립트를 삽입시켜야 한다. 그 스크립트는 /etc/init.d에 만들어져 있어야 하며, 해당 run-level에서 동작할 수 있도록 적절한 디렉토리와 링크되어 있어야 한다. 예를들어 보자:

/etc/rc2.d/S01MOUNTFSYS 파일은 /etc/init.d/MOUNTFSYS 파일과 하드링크되어 있다. 이를 확인해 보는 방법은 다음과 같다. 하드링크라는 의미는 파일이 같은 i-node를 사용한다는 의미이므로, 3825란 i-node번호로 하드링크 되어있음을 알 수 있다. 3 번째 컬럼의 3의 의미는 아래와 같이 링크된 파일이 시스템에 3개 존재한다는 말이다.

[#] ls -il /etc/init.d/MOUNTFSYS
3825 -r--r--r-- 3 root sys 873 Apr 8 1998 /etc/init.d/MOUNTFSYS
[#] ls -il /etc/rc2.d/S01MOUNTFSYS
3825 -r--r--r-- 3 root sys 873 Apr 8 1998 /etc/rc2.d/S01MOUNTFSYS
[#] ls -il /etc/rc1.d/S01MOUNTFSYS
3825 -r--r--r-- 3 root sys 873 Apr 8 1998 /etc/rc1.d/S01MOUNTFSYS

/etc/rc1.d 디렉토리

다음은 run-level 1에서 동작하는 파일들이다. 대부분이 중지하는 스크립트들이 대부분이다.

#/etc/rc1.d:>ls
K00ANNOUNCE K30dmi K67snmp K68sendmail S01MOUNTFSYS S70eels
K10dtlogin K40nfs K68Nnuc K69inet S02mse
K19np K40ppp K68Pnw K80nis S10dstsync
K20lp K44ldap K68Rnwip K85nd S42ls

/etc/rc2.d 디렉토리

이 디렉토리에 있는 파일들은 run-level 2로 갈 때 수행되는 스크립트들을 기술해 놓은 곳이다.
먼저 디렉토리에 들어있는 스크립트들이 무엇이 있는지 살펴보자.

[#] /etc/rc2.d:>ls
K20nfs S15mkdtab S69inet S71ppp S90sysinfo2html
S01MOUNTFSYS S15nd S70Nnwip S73snmp S93scohelphttp
S02PRESERVE S15static_conf S70Pnw S75rpc S96isapnp
S02audit S42ls S70Rnuc S80nis S98vesa
S02mse S51domain S70eels S81sendmail S99dtlogin
S05RMTMPFILES S53x25 S70pf S88ldap s74netbios
S10dstsync S65loopback S70unixtsa S89dmi

사용자가 자신이 만든 스크립트를 어디에 어떻게 삽입하여야 할지를 알아야 한다. 스크립트는 소트된 순서로 수행이되기 때문에, 시스템 관련 스크립트들이 사용자가 만든 스크립트보다 먼저 수행되어야 한다. 대부분이 사용되는 번호는 S99로 시작하게 작성하면 된다.

만일 NFS나 VisionFS와 관련된 스크립트라면, rc3.d 디렉토리 밑에다 작성하여 놓아라. 또 사용자 스크립트를 사용하기 전에 반드시 테스트를 거친 후에 정식으로 사용하여야 한다. 만들어진 스크립트로 인하여 시스템이 부팅하다가 정지되거나 시스템을 사용하지 못하는 사례가 종종 발생하기 때문이다. 테스트는 명령어 모드에서 테스트하면 되고, 테스트에 장시간 소요된다면 그 작업을 백그라운드에서 동작하도록 하면 된다.

백그라운드 작업 방법은 명령어의 끝에 한 칸 띄우고 & 표시를 삽입시켜 주면 된다. 예를들어 passwd란 이름을 가진 파일을 백그라운드로 찾아라 할 때 사용한다.
#find . –name passwd –print &

/etc/dinit.d 디렉토리

/sbin/dinit이 실행되면 “/etc/dinit.d” 디렉토리에 있는 파일들을 동작시킨다. 이러한 기능은 OS에 따라 /etc/rc2.d 디렉토리에 넣어 사용하기도 한다.
[#]ls /etc/dinit.d
S23ttymap S70uucp S80cs S81np
S69keymaster S75cron S80lp S85perf

“/etc/dinit.d”에 있는 파일을 살펴보면 “S”나 “K”로 시작 함을 알 수 있다. S란 파일이 start 옵션으로 실행된다는 의미이고, K stop 옵션으로 실행된다는 의미이다. 반드시 대문자 여야 하고 S나 K 이외의 문자는 무시된다. 이들 파일들은 ASCII 지정 순서로 “/usr/bin/sh”에 의해 실행된다. 위에서 S80으로 시작하는 스크립트가 두개가 있는데 상관은 없다. 알파벳 순으로 찾으며 그 이름이 틀리면 스크립트들이 동작하는 데에는 아무 문제가 없다는 말이다. /etc/rc2.d 디렉토리 밑에 있는 스크립트들도 마찬가지로 같은 번호이어도 상관은 없다.

단지 사용자가 작성한 스크립트는 시스템에서 디폴트로 제공하는 스크립트들 보다는 뒤쪽 번호로만 작성하기만 하면 된다. 만약 디폴트 시스템 스크립트 중간에 위치한 임의의 번호로 스크립트를 작성한다면 시스템 기동에 문제가 발생 할 수도 있다.

스크립트가 알파벳 순서로 동작하게 되는데 사용자가 작성한 스크립트가 아직도 동작 안한 시스템 스크립트 중의 어느 기능을 요구할 때에는 시스템 부팅을 못하고 계속 루핑을 돌고 있을 수도 있기 때문이다.

cs 명령어는 TLI connection-oriented 와 serial connection들 상에서 통신하는 모든 네트웍 서비스에 대한 접속을 설정하도록 CS(Connection Server)를 시작한다. Connection Server는 시스템이 멀티 유저 모드로 갈 때 자동으로 시작된다. CS는 클라이언트 어플리케이션들로부터 네트웍 서비스에 대한 연결 요청(connection request)을 받고, machine 과 service name들을 transport-dependent 어드레스들로 메핑(mapping) 시키고, 필요하다면 연결을 인증하고, 그리고 그 연결을 다시 어플리케이션들에게로 되돌려 준다. CS는 네트웍 연결을 설정하기 위해 주로 cu와 uucp 명령어에 의해 사용된다.

그 기능을 테스트하기 위해 다음을 예로 시험하여 보자.
[#]/etc/dinit.d:>sh S80cs stop
[#]/etc/dinit.d:>ps -ef|grep cs
[#]/etc/dinit.d:>cu -l term/01m
UX:cu: ERROR: connect failed: CONNECTION SERVER PROBLEM

cs 프로세스를 일단 죽이고 모뎀 연결을 시도해 보면 접속이 실패함을 알 수 있다. CS에 문제가 있음을 보여주고 있다. cs 프로세스가 안 떠 있기 때문이다. 그러나 TCP/IP의 소켓(socket)으로 연결된 프로세스나 프로그램들은 사용할 수 있다.
[#]/etc/dinit.d:>sh S80cs start
[#]/etc/dinit.d:>ps -ef|grep cs
root 10203 1 TS 80 0 13:40:09 ? 0:00 /usr/sbin/cs
[#]/etc/dinit.d:>cu -l term/01m
Connected

cs 프로세스를 살리고 접속을 시도하니 정상 동작이 됨을 알 수 있다. cs는 고정된 PID를 사용하지 않고 죽었다 살 때마다 변경이 된다.


/etc/rc3.d 디렉토리

멀티유저 시스템 환경에다 네트웍 파일 공유기능도 할 수 있는 스크립트를 제공하는 디렉토리이다. Run-level 3로 갈 때 수행되는 스크립트들이 있다.

[#] /etc/rc3.d:>ls
S22nfs S90Webtop S90visionfs

위의 경우는 S90*가 마지막이므로 사용자 스크립트는 S91로 시작하도록 작성하면 무난하다.













System Shutdown


시스템을 죽이는 방법은 앞에서 거론한 바와 같이 여러가지 방법이 있다. 크게 두 가지 사용 방법이 있는데 한가지는 일반적으로 사용하는 명령어를 이용한 방법이고, 다른 한가지는 SCOadmin 메뉴에서 제공하는 “Shutdown Manager”가 있다. 어떤 방법이 더 편리한가는 개개인의 습관에 달려 있다.

시스템 셧다운 을 하고 난 후 정상적으로 셧다운이 되면 콘솔에 시스템의 전원을 꺼도 된다는 곳과 유사한 메시지가 뿌려질 것이다. 이때에 전원을 내려야 한다. 그렇지 않으면 무언가 시스템이 추가 조치를 요구한다는 의미이다. 가령 DB나 애플리케이션이 물고 있어서 셧다운 진행이 안되는 경우도 있으니까 말이다.

Command 방식

시스템을 다운시키는 방법으로 init과 shutdown 명령어를 주로 사용한다. 기존에 시스템을
셧다운 하기 전에 ‘sync’ 명령어로 모든 시스템 버퍼에 있던 내용을 디스크로 저장하도록
사용하였다. 그러나 굳이 셧다운 전에 sync를 해줄 필요는 없다. 디스크들이 언마운트 될
때, 시스템이 셧다운 되기전에 디스크로 버퍼 캐쉬를 플러쉬(flush)하도록 sync가 수행되기
때문이다. 이외에도 /usr/ucb/halt, /usr/ucb/reboot , /sbin/uadmin 이란 명령어들도 있으나 잘 사용
하지 않는다.

init 명령어

init 명령어중에서 셧다운 상태로 전환시키는 run-level 0가 시스템을 죽이는 명령어이다.

#init 0

위와 같이 간단한 명령어로 시스템을 셧다운 시킬 수 있다. 이 명령어를 사용하면 특별한
메시지 없이 내부적으로 즉시 시스템을 죽이는 단계로 돌입한다. 전에 언급한 바와 같이
시스템을 셧다운 시키기 전에 반드시 DB(Oracle, Informix,Ingres,M 데이터베이스)나 사용자
프로그램은 다운시키고 하는 습관을 길러야 한다. 대부분 DB나 프로그램들이 안정적이고
복구가 된다고들 하지만 만에 하나 파일 시스템이나 DB가 깨질 경우가 발생하기 때문이다.

shutdown 명령어

shutdown 명령어는 init에 비해 보단 유연성을 제공하지만 옵션이 많아 잘 사용하지 않는다.

#shutdown –y –i<grace> -g<level>

-y : 이 옵션이 없으면 시스템에서 “Do you want to continue”라고 확인하는 차원에서
물어본다. 이 옵션을 사용하면 물어보지 않고 수행된다.
-i<grace> : grace에는 run-level에 해당하는 숫자를 넣어준다.
-g<level> : level은 초단위로 몇초 후에 셧다운 시키라고 할 때 사용 된다.







다음에는 많이 사용되는 예제이다.

#shutdown –y –i0 –g0 ; init 0 한 것과 같고, 즉시 시스템을 run-level 0로 셧다운
시킬때 사용한다.
#shutdown –y –i6 –g0 ; init 6 한것과 같으며 즉시 run-level 6으로 리부팅하란 의미.
#shutdown –y –i0 –g60 ; 60초 후에 셧다운 시키라는 의미.