썬 시스템 10대 장애 분석

[ 썬 시스템 10대 장애 분석]

안녕하세요. 꿈꾸는 개발자입니다. 오늘 포스팅 내용은 썬(SUN) 시스템 10대 장애 분석을 해볼게요.

 

[1] Root(/) 파일 시스템 복구
root(/) 파일 시스템이 손상되어 시스템 부팅이 않되는 경우 backup 받아 놓은 data를 사용하여 아래와 같이 복구할 수
있습니다.

1. 시스템을 down 시키고 OS CD를 CD-ROM drive에 넣는다.
2. 아래와 같이 CDROM 을 이용하여 single-user mode로 부팅한다
 ok boot cdrom -sw
3. Bourne shell prompt(#)가 나타나면, /로 사용하던 disk device에 새로운 파일 시스템을 만든다. /로 사용하던
disk device가 /dev/dsk/c1t0d0s0인 경우 아래와 같이 한다.
 # newfs /dev/rdsk/c1t0d0s0
4. 새로운 root file system을 fsck명령을 사용하여 점검한다.
 # fsck /dev/rdsk/c1t0d0s0
5. root file system을 /a로 mount한다.
 # mount /dev/dsk/c1t0d0s0 /a
 6. root 파일 시스템을 backup 받아놓은 tape을 tape drive에 넣고 아래의 명령을 실행하여 restore한다.
 # cd /a
 # ufsrestore rvf /dev/rmt/0
7. restore가 끝나면 "restore symbol table"을 지우고 새로 만든 root partition을 unmount 한다.
 # rm restoresymtable
 # cd /
 # umount /a
8. fsck 명령을 사용하여 새 root partition을 다시 한번 점검한다.
 # fsck /dev/rdsk/c1t0d0s0
9. 아래의 명령을 사용하여 bootblock을 설치한다.
 # cd /usr/platform/`uname -i`/lib/fs/ufs
 # installboot bootblk /dev/rdsk/c1t0d0s0
10. 시스템을 재 부팅한다.
 # reboot 

[2] / 파일 시스템이 full 되었을 경우 조치 방법 / (root) 파일시스템이 full 되었을 경우에 다음에 열거한 순서대로 파일 시스템을 점검한다.

1. / 파일시스템에 사용자가 임의로 만들어 준 디렉터리가 있는면 정리한다.
2. /dev 디렉터리 밑에 일반파일이 있는지 조사한다.
 # find /dev -type f -exec ls -l {} ₩;
y 일반 파일이 있을 경우, 모두 지우면 된다. 특히 테이프에 백업을 받을 경우에 사용자가 디바이스명을 잘못 지
정하여, 테이프에 백업되지 않고 파일에 저장하는 경우가 있다.
3. 시스템에 있는 core 파일을 제거한다. core 파일을 찾아 보려면 다음과 같은 명령어를 사용한다.
 # find / -name core -print
 y core 파일을 찾아서 자동으로 지우려면 다음과 같은 명령어를 실행한다.
 # find / -name core -exec rm {} ₩; -print
4. /var가 root 파일 시스템이 있을 경우, /var 디렉터리 밑을 조사한다.
 # du -sk /var/* | sort -nr
 y 이 명령어를 실행하면 /var 밑에 있는 디렉터리 별로 그 서브 디렉터리까지 포함하여 KB 단위의 크기를 출력한
다. 거기에서 사이즈가 큰 디렉터리에 대하여 조사한다. 정상적인 시스템에 주로 문제가 될 만한 디렉터리는 다
음과 같다.
 /var/adm
 /var/mail
 /var/log
 /var/preserve
 /var/spool
 4.1 /var/adm
 /var/adm 디렉터리에는 시스템이 운용중이 발생하는 메세지나 기타 정보들이 누적 보관된다. 이 디렉터리에 큰
파일이 있으면 정리한다.
 messmages.0, messages.1, ...
 이러한 파일이 있으면 그냥 지워도 상관없다.
 messages 파일의 크기가 너무 크면 " # cp /dev/null messages " 명령어를 사용하여 파일 크기를 0으로 만들 수
있다. 이 파일은 시스템에서 발생되는 메세지를 보관하는 파일이다.
 wtmp 또는 wtmpx 파일의 크기가 너무 크면 다음과 같은 명령어를 실행하여 그 크기를 0으로 만들 수 있다. 이
파일에는 시스템에 접속한 사용자에 대한 정보를 가지고 있는 파일이다. 
 # cp /dev/null wtmp
 # cp /dev/null wtmpx
 만일 pacct이 있으면 그 파일의 크기를 다음과 같은 명령어를 사용하여 크기를 0으로 만들 수 있다. 이 파일은
accounting 정보를 가지고 있는 파일이다.
 # cp /dev/null pacct
 pacct1, pacct2, ... 등등의 파일이 있으면 그냥 지우면 된다. 그 외에도 사이즈가 큰 파일을 알아서 정리한다.
 4.2 /var/mail
 /var/mail 디렉터리에는 메일 데이타가 보관되는 곳이다. 이 디렉터리에 사이즈가 큰 파일이 있으면, 해당 사용
자에게 그 메일을 정리하도록 한다.
 4.3 기타 디렉터리에 대해서도 조사하여 불필요하게 사이즈가 큰 파일 있을 경우 알아서 정리한다. 단 파일을 지울
때, 그 파일이 어떤 파일인지 숙지한 후에 지울 것인가 아닌가를 결정한다.
5. / 파일 시스템에 있는 1 MB 이상되는 파일을 조사하여, 파일 크기 순으로 sort하여 그 내용을 조사한다.
 # find / -mount -size +1024k -ls > /tmp/find.list
 # sort -nr +6 /tmp/find.list > /tmp/find.list.s
 find.list.s 파일에서 비정상적인 큰 파일이 있는지 조사한다. 

[3] local network상의 다른 시스템과 통신이 않되는 경우 점검사항 시스템에서 갑자기 LAN 상의 다른 시스템과 통신이 안 되는 경우 다음과 같은 사항들을 순차적으로 점검해 본다.

1. LAN cable이 시스템의 LAN card 와 HUB/SWITCH 간에 연결이 제대로 되어 있는지 확인한다.
 2. LAN card에 LED(Lamp)가 있는 card인 경우 LAN cable을 연결했을 때 LED가 "green" 으로 변하는지 확인한다.
3. ifconfig 명령으로 network interface에 대한 flag가 "up" 과 "running" 상태인지 확인한다.
 # ifconfig -a
 lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 inet 127.0.0.1 netmask ff000000
 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
 inet 129.158.153.167 netmask ffffff00 broadcast 129.158.153.255
4. ifconfig 명령으로 network interface에 지정된 IP address가 시스템에 할당된 IP와 맞는지 확인한다.
 # ifconfig -a
 lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 inet 127.0.0.1 netmask ff000000
 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
 inet 129.158.153.167 netmask ffffff00 broadcast 129.158.153.255
 ^^^^^^^^^^^^^^^ <-- IP address 확인
 5. ifconfig 명령으로 network interface에 지정된 IP address에 대한 netmask 값과 broadcast 값이 맞게 지정되어 있
는지 확인한다.
 # ifconfig -a
 lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 inet 127.0.0.1 netmask ff000000
 le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
 inet 129.158.153.167 netmask ffffff00 broadcast 129.158.153.255
 ^^^^^^^^ ^^^^^^^^^^^^^^^
6. routing table에 local network에 대한 routing이 맞게 잡혀 있는지 확인한다.
 # netstat -rn
 Routing Table:
 Destination Gateway Flags Ref Use Interface
 -------------------- -------------------- ----- ----- ------ ---------
 129.158.153.0 129.158.153.167 U 3 323 le0
 224.0.0.0 129.158.153.167 U 3 0 le0
 default 129.158.153.1 UG 0 546 
 127.0.0.1 127.0.0.1 UH 0 9459 lo0

 위의 결과처럼 Interface le0에 대한 routing이 잡혀 있는지 확인한다.
 7. 위의 1-6 항목이 모두 이상이 없으면 아래와 같이 ping 명령을 사용하여 LAN 상의 다른 시스템으로부터 응답을 받
는지 확인한다.
 # ping -s 129.158.153.255 

[4] FCAL boot disk로 booting을 못할 경우 복구방법 FCAL disk를 boot disk로 사용할 경우 disk가 WWN을 가지고 있기 때문에 disk 교체 시 WWN을 바꿔주어야만 error 없이 booting을 할 수 있다.

다음과 같은 순서대로 실행 하여야 한다.
1) disk를 교체 한다.
2) OS cdrom 을 이용하여 single user mode 로 booting한다.
3) disk partition을 만든후 filesystem을 creation하고, mount한 후 data를 restore한다.
4) "installboot" command를 이용하여 bootblock을 install 한다.
5) root partition을 mount한후 device tree를 re-build한다.
 # drvconfig -r /a -p /a/etc/path_to_inst
 # cd /devices
 # find . -print | cpio -pduVm /a/devices
 # disks -r /a
 # devlinks -r /a
6) luxadm command를 사용하여 EEPROM의 "boot-device" parameter를 수정한다.
 # luxadm set_boot_dev /dev/dsk/{root slice entry}
 (가능하면, EEPROM의 "boot-device" parameter로 같이 수정한다.)
7) system을 rebooting한다. 

[5] 시스템이 자동으로 재부팅 되었을 경우 점검/조치 방법 증상 : EP3500 서버로 운영 중인 시스템이 자동 재부팅되어 정상적으로 재부팅되었음. 시스템 LED는 모두 정상적으로 나 타남

장애처리 절차 :
y /var/adm/messages (시스템 메시지 파일)에서 panic 메시지 여부 확인
y /usr/platform/sun4u/sbin/prtdiag –v 명령어로 하드웨어 이상여부 확인
y crash 파일 쌓이는 곳에서 unix.0 vmcore.0 파일을 iscda.sh 로 분석.
y iscda.sh 는 sunsolve.sun.com 접속 및 로그인하면 좌측상단에 Diagnostic Tools에 들어가면 존재함.
y Msgbuf 내용 점검하여 panic 원인 판단
위의 단계에서 해결하지 못할 경우 SUN explorer 자료 수집하여 SUN에 분석의뢰.

예) 다음 메시지가 /var/adm/messages 파일에 존재함.
에러 메시지 :
panic[cpu7]/thread=0x6401e040: CPU7 Ecache SRAM Data Parity Error:
 AFSR 0x00000000 00400008 AFAR 0x00000000 00200000
 syncing file systems... [14] 18 [14] [14] [14]panic[cpu7]/thread=0x30037ec0: panic sync timeout
원인 : Ecache SRAM Data Parity Error로 인한 시스템 다운
조치사항 : 해당 CPU 교체 (CPU#7) 

[6] 시스템이 down 되었을 경우 점검/조치 방법 증상 : EP6500서버로 운영 중인 시스템이 shutdown 되어 재부팅되어 있지 않음.

장애처리 절차 :
y 현재 시스템 전원이 켜져 있는지 확인(꺼져 있으면 전원에 해당하는 부품 불량)
y 켜져 있으면 콘솔화면에 있는 메시지 확인
y ok prompt 상태이라면 sync 명령어로 현재운영상태를 core dump 받음
y 시스템 부팅을 진행하여 진행중인 메시지를 유심히 관찰.
y 정상 진행 된다면 /var/adm/messages 파일에서 panic 메시지 여부 확인
y /usr/platform/sun4u/sbin/prtdiag –v 명령어로 하드웨어 이상여부 확인
y crash 파일 쌓이는 곳에서 unix.0 vmcore.0 파일을 iscda.sh 로 분석.
y iscda.sh 는 sunsolve.sun.com 접속 및 로그인하면 좌측상단에 Diagnostic Tools에 들어가면 존재함.
y Msgbuf 내용 점검하여 panic 원인 판단
위의 단계에서 해결하지 못할 경우 SUN explorer 자료 수집하여 SUN에 분석의뢰.

예1) 시스템 전원이 정상상태가 아님
증상 : 시스템 전원부(AC Power Supply) LED가 황색 상태임
원인 : 황색 상태의 전원 부품(AC Power Supply) 이 불량
조치사항 : 해당 부품(AC Power Supply) 교체
예2) 시스템 전원은 정상이나 ok prompt 상태임. 콘솔화면에 메시지 있음.
증상 : 시스템이 shutdown되어 있고 콘솔화면에 메시지가 존재하나 화면에 밀려 정확하게 분석하기 힘듬.
원인 : sync 명령어로 core dump 받으면서 시스템 재부팅 시킨 후, 메시지 파일에 쌓인 에러메시지 점검결과 전산
실 온도상승으로 인해 자동 shutdown 된 상태임.
조치 사항 : 담당자에게 통지후 시스템 가동 온도를 60도 이하로 낮춤. 

[7] 시스템 부팅을 시켰으나 maintenance 모드로 진행됨 증상 : 사용자가 특정 파일시스템 I/O가 되지 않아 시스템을 재부팅시켰지만 정상 부팅 안됨

장애처리 절차 :
y 정상부팅 안되는 시점의 콘솔 메시지를 확인
y root 패스워드 입력 하여 maintenance 모드로 들어감
y 시스템 메시지 분석하여 파일시스템 I/O 발생되지 않은 원인 찾음
y format 명령어로 디스크의 상태가 정상인지 확인
y /etc/vfstab 파일 점검하여 사용해야 할 파일시스템을 check
y filesystem check 에러 발생 여부 확인
예) 인터널 디스크 2번으로 사용중인 /data 파일시스템이 check 되지 않아 maintenance 모드로 진행됨
증상 : /data 파일시스템 check 하면 i/o error가 발생함
 format 명령어로 디스크 상태 확인시 c0t2d0 디스크가 <drive not available: formatting> 상태임
원인 : c0t2d0 디스크가 물리적으로 정상동작 하지 않음.
조치 : 해당 디스크 교체 및 파일시스템 원복(백업 본) 

[8] A5000 볼륨 디스크 불량시 조치방법 증상 : A5000내의 디스크가 H/W적으로 이상이 있어 교체를 해야 할 필요가 있다.

조치 방법 :
A5000의 DISK가 SEVM(Sun Enterprise Volume Manager)의 control을 받고있을 때는 각각의 disk가 가지고 있는
WWN(World-wide number) 때문에 반드시 다음 에 기술한 순서대로 실행하여야 한다.
만일, 이 순서를 따르지 않을 경우 다음과 같은 Error Message가 console화면에 display될 것이다.
 device cxtxxdxsx online failed : device path not valid
장애 처리 방법 :
Volume manager를 사용하고 있을 경우, 반드시 다음의 순서대로 실행하여야 한다.
1) vxdiskadm utility를 이용하여 교체하고자 하는 disk를 volume에서 remove한다.
 # vxdiskadm
 > menu에서 4번을 선택하여 volume에서 disk를 remove 한다.
2) disk를 Offline 시킨다.
 vxdiskadm option 11 (Disable (offline) a disk device)
 (use the c#t#d# name)
 or
 GUI Advanced-Ops->Disk->Offline
 (use the Disks window; highight c#t#d#s#)
3) 명령어로 디스크장치를 제거한다
 luxadm remove_device (controller, slot)
 Controller name은 A5000 LCD pannel의 BOX ID이며, slot No는 front일 경우 f0~f6, rear일 경우 r0~r6이다.
 만일, multi-initiated mode로 연결되어 있으면, 반드시 양쪽 system 모두에서 실행하여야 한다.
4) 물리적으로 하드디스크를 삽입한 후 다음명령어를 수행한다.
 luxadm insert_device (controller, slot)
 만일, multi-initiated mode로 연결되어 있으면, 반드시 양쪽 system 모두에서 실행하여야 한다.
5) 볼륨메니저에 변경된 구성정보를 알리기 위해 다음 명령어 수행한다
vxdctl enable
6) 볼륨메니저에서 디스크를 온라인 시키기 위해 다음을 수행한다.
 vxdiskadm option 5 (Replace a failed or removed disk)

[9] 텔넷 “connect refused remote hosts”

1. 문제 개요
 remote system으로 telnet 접속을 시도하였을 때 remote system에서 telnet request를 거부하는 경우 "telnet:
Unable to connect to remote host: Connection refused" 와 같은 에러가 발생한다.
2. 문제 원인 및 해결방법
 telnet request를 받으면 "inetd" daemon에 의해서 in.telnetd가 수행되고 telnet 서비스를 요청해온 시스템에 login
prompt를 띄워준다. 따라서 위와 같은 에러 메세지가 발생하면 telnet request를 받은 remote system에서 아래와 같은
사항들을 점검한다.
 2.1 "inetd" daemon이 실행 중인지 확인한다.
 # ps -ef|grep inetd
 inetd daemon이 실행 중이 아니면 아래와 같이 inetd daemon을 실행한다.
 # /usr/sbin/inetd -s
 2.2 /etc/inetd.conf 파일에 "telnet" 에 관해서 아래와 같이 정의되어 있는지 확인 한다.
 # grep telnet /etc/inetd.conf
 telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

위와 같이 정의가 되어 있지 않으면, 위의 내용을 추가한 후 "inetd" daemon을 re-start 시킨다.
 # ps -ef|grep inetd
 root 162 1 0 11월 28 ? 0:01 /usr/sbin/inetd -s
 ^^^^
 "inetd"의 process 번호

 # kill -HUP 162 

[10] libthread panic - 임계 영역에서 Signal 11 오류 발생

문제 설명:
많은 스레드를 로드하는 환경에서 다중 스레드 애플리케이션은 다음과 비슷한 오류를 출력합니다.
signal fault in critical section
signal number:11, signal code:1
fault address:0x69d63e28, pc:0x6fe4884c, sp:0x698b39e0
libthread panic:fault in libthread critical section (PID:375 LWP 260) stacktrace:
6fe49a24
6fe52114
6fe48830
6fe485d8
6fe5525c
991b0
78078
af33c
af1c0
6fe54fb8
af194
코어 파일은 이러한 패닉에 의해 생성되지 않습니다.
문제 해결 방법:
libthread에서 패닉이 발생하는 기본적인 원인은 두 가지가 있습니다. 운영 체제의 버그로 인해 발생하는 패닉의 가
능성을 조사하기 전에 이와 같은 두 가지 원인을 신중하게 검토해야 합니다.
* 여러 개의 스레드는 동일한 주소 공간을 공유합니다.
다중 스레드 컨텍스트에서 사용되는 vfork(), system(), fork() 등과 같이 스레드와 fork에 안전하지 않은 함수를 호출
하는 경우와 상호 배제 잠금을 사용하여 주소 공간을 보호하는 경우에도 이러한 패닉이 발생할 수 있습니다. fork1()은
execl()과 마찬가지로 스레드에서 안전하며, 이러한 함수는 system() 호출 대신 사용할 수 있습니다.
* 시스템 자원이 없습니다.
예를 들어 운영 체제에서 할당할 수 있는 사용 가능한 스왑 공간이나 스택 공간이 없습니다. 
가장 흔한 원인은 스레드에 사용 가능한 스택 공간이 없는 경우입니다. 그 결과 libthread 라이브러리에 할당된 메모리
의 일부에 스택 데이터를 겹쳐 쓰게 되어 패닉이 발생하게 됩니다.
이러한 패닉이 발생할 경우 다음과 같은 두 가지 접근 방법으로 문제를 해결할 수 있습니다.
(1) 사용 가능한 스택 공간이나 스왑 공간의 크기를 증가시킵니다.
실행하고 있는 쉘에 따라 limit 또는 ulimit 명령을 사용하여 스택 크기를 확인하고 조정할 수 있으며, 모든 쉘에
서 makefs 및 swap 명령을 사용하여 스왑 공간을 관리할 수 있습니다. limit 설정은 사용하고 있는 쉘 및 그 자식
들에 대한 하나의 인스턴스에만 영향을 미칩니다. 따라서 스택 설정을 전역으로 만들려면 부팅 사이클이 끝나는
부분에서 수행되도록 해야 합니다. ulimit 명령을 /etc/rc2.d/ 디렉터리에서 적합한 시작 스크립트에 추가하여 이
를 수행할 수 있습니다.
(2) 각 사용자 스레드에 대한 개별 스택을 만듭니다.
pthread(POSIX 스레드)를 사용한 다중 스레드 프로그래밍을 다루는 서적에는 스레드에 대한 스택 크기 및 스택 주
소를 올바르게 변경하는 방법에 대해 잘 설명되어 있습니다. 요약해서 말하면, 스택 크기를 사용자 정의하려면
pthread_attr_init()를 사용하여 사용자 정의 스레드 속성 개체(pthread_attr_t)를 초기화해야 합니다. 그러면
pthread_attr_getstacksize()를 호출하여 스택 크기를 확인하고 pthread_attr_setstacksize()를 이용하여 스택 크
기를 조정할 수 있습니다. 그런 다음 pthread_create()를 사용하여 원하는 속성을 가진 스레드를 만들 수 있습니
다.
끝으로, 다중 스레드에 영향을 미칠 수 있는 알려진 버그를 예방하려면 libthread 라이브러리(libthread.so)용 패치와
현재 사용하고 있는 운영 체제 버전에 대한 커널 패치를 설치해야 컴퓨터 시스템을 최신 상태로 유지할 수 있습니다.