리눅스 디버깅 기술 마스터하기 (한글) 리눅스 상에서 버그를 해결하는 핵심 전략들

문서 옵션 이 페이지를 이메일로 보내기 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백 난이도 : 중급 Steve Best, JFS core team member, IBM 2006 년 6 월 19 일 실행중인 사용자 공간 프로그램을 검사하는 방법은 여러 가지이다. 디버거를 실행하여 프로그램을 직접 관찰하거나, print 문을 추가하거나, 프로그램을 분석하는 툴을 추가할 수 있다. 이 글에서, 리눅스에서 실행되는 프로그램을 디버깅 할 때 사용할 수 있는 방법들을 설명한다. 세그멘테이션 오류, 메모리 오버런 및 누수, 행(hang) 같은 문제들을 디버깅하는 네 가지 시나리오를 검토해 본다. (이 글은 2002년 8월에 IBM developerWorks에 게재되었다.) 이 글에서 네 가지 디버깅 시나리오를 제시한다. 시나리오 1의 경우, 메모리 할당 문제가 있는 두 개의 샘플 프로그램을 사용한다. MEMWATCH와 Yet Another Malloc Debugger (YAMD) 툴을 사용하여 디버깅 한다. 시나리오 2에서는 strace 유틸리티를 사용한다. 시스템 호출과 시그널을 추적하여 프로그램이 어디서 잘못되었는지를 규명한다. 시나리오 3에서는 리눅스 커널의 Oops를 사용하여 세그멘테이션 오류 문제를 해결하고 커널 소스 레벨 디버거(kgdb)를 설정하여 GNU 디버거(gdb)를 사용하여 같은 문제를 해결한다. kgdb 프로그램은 직렬 연결을 통한 리눅스 커널 원격 gdb이다. 시나리오 4는 행을 일으키는 컴포넌트 정보를 디스플레이 한다. 매직 키 시퀀스를 사용한다. 일반적인 디버깅 전략 프로그램에 버그가 포함되어 있다면 대게 코드 어딘가에 있을 것이다. 여러분이 사실이라고 믿는 이러한 상황은 실제로는 잘못되었다. 버그를 찾는다는 것은 무엇인가 잘못되었다는 것을 발견할 때까지 여러분이 사실이라고 믿는 것을 다시 한번 확인하는 과정이다. 다음은 여러분이 사실이라고 믿고 있는 몇 가지 유형이다. 소스 코드의 특정 위치에서, 변수는 특정 값을 가진다. 주어진 위치에서, 구조가 정확히 설정되었다. if-then-else 문에서 if 부분은 실행되었던 경로이다. 서브루틴이 호출될 때 루틴은 매개변수를 정확히 받는다. 버그를 찾는 것에는 이러한 모든 것들을 확인하는 과정이 포함된다. 특정 변수가 특정 값을 갖고 있다고 믿는 다면 서브루틴이 호출될 대 이를 검사해보라. if 구조가 실행된다는 것을 믿는다면 검사해 보라. 여러분이 가정하는 것을 확인해보면 결국 여러분의 신념이 잘못되었다는 것을 발견할 것이다. 결국 여러분은 버그의 위치를 찾게 된다. 디버깅은 피해갈 수 없는 과정이다. 메시지를 스크린에 프린팅 하기, 디버거 사용하기, 프로그램 실행에 대해 생각하기, 문제에 대한 현학적인 고찰하기 같이 디버깅에 대한 많은 방식들이 있다. 버그를 픽스하기 전에 소스의 위치부터 알아야 한다. 예를 들어, 세그멘테이션 오류가 있을 경우, 코드의 어떤 라인에서 seg 오류가 발생했는지를 알아야 한다. 문제의 코드 라인을 찾아내면 그 메소드에서의 변수의 값, 메소드가 호출되었던 방법, 에러가 발생했던 이유 등을 파악하라. 디버거를 사용하면 이 모든 정보를 찾기가 쉬워진다. 디버거를 사용할 수 없다면 다른 툴들도 있다. (제품 환경에서는 디버거를 사용하지 못할 수도 있다. 리눅스 커널에는 디버거가 빌트인 되어있지 않다.) 유용한 메모리 및 커널 디버깅 툴 리눅스에서 디버그 툴을 사용하여 사용자 공간과 커널 문제를 추적하는 방법은 여러 가지이다. 다음 툴과 기술을 사용하여 소스 코드를 디버깅 하라. 사용자 공간 툴: 메모리 툴: MEMWATCH와 YAMD strace GNU debugger (gdb) Magic key sequence 커널 툴: Kernel source level debugger (kgdb) Built-in kernel debugger (kdb) Oops 이 글에서는 코드를 육안으로 검사해서는 찾기 어려운 문제들과, 매우 드문 환경에서 발생하는 문제 유형에 대해 살펴보도록 하겠다. 환경이 결합될 때에만 발생하는 에러가 있고, 프로그램을 전개한 후에만 메모리 버그를 발견할 때가 가끔 있다. 위로 시나리오 1: 메모리 디버깅 툴 리눅스 시스템 상의 표준 프로그래밍 언어로서 C 언어는 동적 메모리 할당에 대한 많은 제어권을 제공한다. 하지만 이러한 자유가 중대한 메모리 관리 문제를 야기시키고 이 문제는 프로그램 충돌 또는 강등으로 이어진다. 메모리 누수(malloc() 메모리가 상응하는 free() 호출로 결코 누출되지 않는다.)와 버퍼 오버런(어레이에 할당되었던 지난 메모리 작성하기)은 공통의 문제들이고 탐지하기 어렵다. 이 섹션에서는 메모리 문제를 탐지하고 고립하는 몇 가지 디버깅 툴에 대해 알아보겠다. 위로 MEMWATCH Johan Lindh가 작성한 MEMWATCH는 다운로드 가능한 C를 위한 오픈 소스 메모리 에러 탐지 툴이다.(참조자료) 헤더 파일을 코드에 추가하고 gcc 문에 MEMWATCH를 정의하면 프로그램에 메모리 누수와 오염을 탐지할 수 있다. MEMWATCH는 ANSI C를 지원하고, 결과 로그를 제공하고, 중복도 없고 에러도 없는 실행하지 않는 메모리와 오버플로우와 언더플로우를 탐지한다. Listing 1. 메모리 샘플 (test1.c) #include <stdlib.h>#include <stdio.h>#include "memwatch.h"int main(void){ char *ptr1; char *ptr2; ptr1 = malloc(512); ptr2 = malloc(512); ptr2 = ptr1; free(ptr2); free(ptr1);} Listing 1에 있는 코드는 두 개의 512-바이트 메모리 블록을 할당하고 첫 번째 블록에 대한 포인터가 두 번째 블록에 설정된다. 결과적으로 두 번째 블록의 주소가 소실되고 메모리 누수가 생긴다. 이제 memwatch.c를 컴파일 한다. 다음은 makefile 예제이다. test1 gcc -DMEMWATCH -DMW_STDIO test1.c memwatchc -o test1 test1 프로그램을 실행하면 누수 된 메모리 리포트가 만들어 진다. Listing 2는 memwatch.log 아웃풋 파일 예제이다. Listing 2. test1 memwatch.log 파일 MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh...double-free: <4> test1.c(15), 0x80517b4 was freed from test1.c(14)...unfreed: <2> test1.c(11), 512 bytes at 0x80519e4{FE FE FE FE FE FE FE FE FE FE FE FE ..............}Memory usage statistics (global): N)umber of allocations made: 2 L)argest memory usage : 1024 T)otal of all alloc() calls: 1024 U)nfreed bytes totals : 512 MEMWATCH는 문제가 있는 실제 라인을 제공한다. 이미 제거된 포인터를 제거하면 알려준다. 제거되지 않은 메모리에도 똑 같이 적용된다. 로그의 끝에 있는 섹션은 얼마나 많은 메모리가 누수가 있었는지, 얼마나 많이 사용되었는지, 총 할당량은 어느 정도인지를 디스플레이 한다. 위로 YAMD Nate Eldredge가 작성한 YAMD 패키지는 C와 C++에서 메모리 할당과 관련 문제들을 찾는다. 이 글을 쓰고 있는 현재 최신 버전의 YAMD는 0.32다. yamd-0.32.tar.gz를 다운로드 하라.(참고자료) make 명령어를 실행하여 프로그램을 구현한 다음 make install 명령어를 사용하여 프로그램을 설치하고 툴을 설정한다. YAMD를 다운로드 한 후에 test1.c에서 이것을 사용한다. #include memwatch.h를 제거하고 makefile을 다음과 같이 변경한다. YAMD를 사용한 test1 gcc -g test1.c -o test1 Listing 3은 test1 상에서의 YAMD의 아웃풋이다. Listing 3. YAMD를 사용한 test1 결과 YAMD version 0.32Executable: /usr/src/test/yamd-0.32/test1...INFO: Normal allocation of this blockAddress 0x40025e00, size 512...INFO: Normal allocation of this blockAddress 0x40028e00, size 512...INFO: Normal deallocation of this blockAddress 0x40025e00, size 512...ERROR: Multiple freeing Atfree of pointer already freedAddress 0x40025e00, size 512...WARNING: Memory leakAddress 0x40028e00, size 512WARNING: Total memory leaks:1 unfreed allocations totaling 512 bytes*** Finished at Tue ... 10:07:15 2002Allocated a grand total of 1024 bytes 2 allocationsAverage of 512 bytes per allocationMax bytes allocated at one time: 102424 K alloced internally / 12 K mapped now / 8 K maxVirtual program size is 1416 KEnd. YAMD는 우리가 이미 메모리를 제거했고 메모리 누수가 있다는 것을 알려준다. 또 다른 샘플 프로그램에서 YAMD를 실행해 보자. Listing 4. 메모리 코드 (test2.c) #include <stdlib.h>#include <stdio.h>int main(void){ char *ptr1; char *ptr2; char *chptr; int i = 1; ptr1 = malloc(512); ptr2 = malloc(512); chptr = (char *)malloc(512); for (i; i <= 512; i++) { chptr[i] = 'S'; } ptr2 = ptr1; free(ptr2); free(ptr1); free(chptr);} 다음 명령어를 사용하여 YAMD를 시작한다. ./run-yamd /usr/src/test/test2/test2 Listing 5는 샘플 프로그램 test2에서 YAMD를 사용한 결과를 보여준다. YAMD는 for 루프에서 우리가 out of bound 조건을 갖고 있다는 것을 말해준다. Listing 5. YAMD를 사용한 test2 결과 Running /usr/src/test/test2/test2Temp output to /tmp/yamd-out.1243*********./run-yamd: line 101: 1248 Segmentation fault (core dumped)YAMD version 0.32Starting run: /usr/src/test/test2/test2Executable: /usr/src/test/test2/test2Virtual program size is 1380 K...INFO: Normal allocation of this blockAddress 0x40025e00, size 512...INFO: Normal allocation of this blockAddress 0x40028e00, size 512...INFO: Normal allocation of this blockAddress 0x4002be00, size 512ERROR: Crash...Tried to write address 0x4002c000Seems to be part of this block:Address 0x4002be00, size 512...Address in question is at offset 512 (out of bounds)Will dump core after checking heap.Done. MEMWATCH와 YAMD 모두 유용한 디버깅 툴이고 다른 접근 방식이 필요하다. MEMWATCH를 사용해서는 include 파일인 memwatch.h에 추가하고 두 개의 컴파일 타임 플래그를 켜야 한다. YAMD는 link 문에 -g 옵션만 필요했다. 위로 Electric Fence 대부분의 리눅스 배포판에는 Electric Fence용 패키지가 포함되어 있지만 다운로드 할 수도 있다. Electric Fence는 Bruce Perens가 작성한 malloc() 디버깅 라이브러리이다. 여러분이 할당한 메모리 바로 뒤에 보호를 받는 메모리를 할당한다. fencepost 에러가 있다면(어레이 끝에서 실행됨) 프로그램은 프로텍션(protection) 에러를 사용하여 즉시 종료된다. Electric Fence와 gdb를 결합하면 어떤 라인이 보호되는 메모리에 접근했는지 정확히 추적할 수 있다. Electric Fence는 메모리 누수를 탐지할 수 있다. 위로 시나리오 2: strace 사용하기 strace 명령어는 사용자 공간 프로그램에서 실행되는 모든 시스템 호출을 보여주는 강력한 툴이다. strace는 호출에 대한 인자를 디스플레이 하고 상징적인 형태로 값을 리턴한다. strace는 커널에서 정보를 받고 커널이 특별한 방식으로 빌트인 될 필요가 없다. strace 정보는 애플리케이션과 커널 개발자에게 유용하다. Listing 6에서 파티션의 포맷은 실패했고 listing은 make file system(mkfs)에 대한 strace의 시작을 보여준다. strace는 어떤 호출이 문제를 일으키는지 결정한다. Listing 6. mkfs에서의 strace 시작 execve("/sbin/mkfs.jfs", ["mkfs.jfs", "-f", "/dev/test1"], & ... open("/dev/test1", O_RDWR|O_LARGEFILE) = 4 stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0 ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument) write(2, "mkfs.jfs: warning - cannot setb" ..., 98mkfs.jfs: warning - cannot set blocksize on block device /dev/test1: Invalid argument ) = 98 stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0 open("/dev/test1", O_RDONLY|O_LARGEFILE) = 5 ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument) write(2, "mkfs.jfs: can\'t determine device"..., ..._exit(1) = ? Listing 6을 보면 ioctl 호출이 파티션을 포맷하는데 사용되었던 mkfs 프로그램이 실패하는데 원인이 된다는 것을 알 수 있다. ioctl BLKGETSIZE64는 실패한다. (BLKGET-SIZE64는 ioctl을 호출하는 소스 코드에 정의된다.) BLKGETSIZE64 ioctl은 리눅스 상의 모든 장치들에 추가되고 있고, 이 경우, 논리적 볼륨 매니저는 이것을 지원하지 않는다. 따라서 mkfs 코드는 BLKGETSIZE64 ioctl 호출이 실패할 경우 오래된 ioctl을 호출해야 한다. 이것은 mkfs가 논리적 볼륨 매니저와 작동하도록 한다. 위로 Scenario 3: gdb와 Oops 사용하기 Free Software Foundation의 디버거인 gdb 프로그램을 사용할 수 있다. 명령행 또는 Data Display Debugger (DDD) 같은 그래픽 툴에서 사용할 수 있다. gdb를 사용하여 사용자 공간 프로그램이나 리눅스 커널을 디버깅 할 수 있다. 이 섹션에서는 gdb용 명령행에 대해서만 설명하겠다. gdb program name 명령어를 사용하여 gdb를 시작한다. gdb는 실행 파일의 심볼을 로딩하고 인풋 프롬프트를 디스플레이 하면, 여러분은 디버거를 사용할 수 있다. gdb 프로세스를 볼 수 있는 세 가지 방법이 있다. attach 명령어를 사용하여 이미 실행중인 프로세스를 본다. attach는 프로세스를 중지시킬 것이다. run 명령어를 사용하여 프로그램을 실행하고 시작할 때 프로그램을 디버깅 한다. 기존 코어 파일을 보고 프로세스가 종료되었을 때의 상태를 파악한다. 코어 파일을 보려면 다음 명령어를 사용하여 gdb를 시작한다. gdb programname corefilename 코어 파일을 사용하여 디버깅 하려면 프로그램 실행 파일과 소스 파일 그리고 코어 파일이 필요하다. 코어 파일로 gdb를 시작하려면 -c 옵션을 사용한다. gdb -c core programname gdb는 어떤 라인의 코드가 문제를 일으켰는지를 코어 덤프에 보여준다. 프로그램을 실행하거나 이미 실행중인 프로그램에 붙기 전에 버그가 있다고 생각하는 소스 코드의 리스트를 만들고, 중단점을 설정하고, 프로그램 디버깅을 시작한다. gdb 온라인 도움말과 help 명령어를 사용하여 상세한 튜토리얼을 참조할 수 있다. 위로 kgdb kgdb 프로그램(gdb를 통한 원격 호스트 리눅스 커널 디버거)은 gdb를 사용하여 리눅스 커널을 디버깅 하는 메커니즘을 제공한다. kgdb 프로그램은 커널의 확장으로서, 원격 호스트 머신에서 gdb를 실행할 때 kgdb 확장 커널을 실행하는 머신에 연결할 수 있다. 커널로 들어가서 중단점을 설정하고 데이터를 검사할 수 있다. (애플리케이션 프로그램에서 gdb를 사용하는 것과 비슷하다.) 이 패치의 주요 기능들 중 하나는 gdb를 실행하는 원격 호스트가 부팅 프로세스 동안 목표 머신(디버깅 될 커널을 실행하고 있음)으로 연결된다는 점이다. 때문에 디버깅을 최대한 빨리 시작할 수 있다. 이 패치는 리눅스 커널에 이 기능을 추가하여 gdb가 리눅스 커널을 디버깅하는데 사용될 수 있도록 한다. kgdb를 사용하려면 두 개의 머신이 필요하다. 하나는 개발 머신이고 다른 하나는 테스트 머신이다. 시리얼 라인(null-modem cable)은 시리얼 포트를 통해 머신으로 연결된다. 여러분이 디버깅 하고자 하는 커널은 테스트 머신 상에서 실행된다. gdb는 개발 머신에서 실행된다. gdb는 시리얼 라인을 사용하여 여러분이 디버깅 하고 있는 커널과 통신한다. 다음 단계를 통해서 kgdb 디버그 환경을 설정한다. 리눅스 커널 버전에 맞는 패치를 다운로드 한다. 커널에 컴포넌트를 구현한다. 이것은 kgdb를 사용하는 가장 쉬운 방법이다. (커널의 컴포넌트를 구현하는 두 가지 방법이 있다. 모듈로서 구현하거나 직접 커널에 구현하는 방법이 있다. 예를 들어, Journaled File System (JFS)은 모듈로서 구현되거나 커널에 직접 구현될 수 있다. gdb 패치를 사용하면 JFS를 커널에 직접 구현할 수 있다.) 커널 패치를 적용하고 커널을 재구현 한다. .gdbinit 라고 하는 파일을 만들고 이것을 커널 소스 하위 디렉토리에 둔다.(/usr/src/linux) .gdbinit 파일에는 다음과 같은 네 가지 라인이 있다. set remotebaud 115200 symbol-file vmlinux target remote /dev/ttyS0 set output-radix 16 append=gdb 라인을 lilo에 추가한다. 이것은 부트 로드로서 커널을 부팅할 때 사용될 커널을 선택한다. image=/boot/bzImage-2.4.17 label=gdb2417 read-only root=/dev/sda8 append="gdb gdbttyS=1 gdb-baud=115200 nmi_watchdog=0" Listing 7은 개발 머신에 구현한 커널과 모듈을 테스트 머신으로 가져오는 스크립트 예제이다. 다음 아이템들을 수정해야 한다. best@sfb: Userid와 머신 이름 /usr/src/linux-2.4.17: 커널 소스 트리의 디렉토리 bzImage-2.4.17: 테스트 머신 상에 부팅 될 커널의 이름 rcp and rsync: 커널이 구현된 머신 상에서 실행되어야 함. Listing 7. 커널과 모듈을 테스트 머신으로 가져오는 스크립트 set -xrcp best@sfb: /usr/src/linux-2.4.17/arch/i386/boot/bzImage /boot/bzImage-2.4.17rcp best@sfb:/usr/src/linux-2.4.17/System.map /boot/System.map-2.4.17rm -rf /lib/modules/2.4.17rsync -a best@sfb:/lib/modules/2.4.17 /lib/moduleschown -R root /lib/modules/2.4.17lilo 커널 소스 트리가 시작되는 디렉토리를 수정함으로서 개발 머신 상에서 gdb 프로그램을 시작할 준비가 되었다. 이 예제에서, 우리의 커널 소스 트리는 /usr/src/linux-2.4.17에 있다. gdb를 입력하여 프로그램을 시작한다. 모든 것이 작동한다면 테스트 머신은 부팅 프로세스 동안 중지된다. gdb 명령어 cont를 입력하여 부팅 프로세스를 계속 진행한다. 한 가지 문제는 null-modem 케이블이 그릇된 시리얼 포트에 연결될 수도 있다는 점이다. gdb가 시작하지 않으면 포트를 두 번째 시리얼로 전환하여 gdb를 시작한다. 위로 kgdb를 사용하여 커널 문제 디버깅하기 Listing 8은 jfs_mount.c 파일의 소스에서 수정되었던 코드이다. 무효 포인터 예외를 만들어서 109 라인에 세그멘테이션 오류를 만들었다. Listing 8. 수정된 jfs_mount.c 코드 int jfs_mount(struct super_block *sb){...int ptr; /* line 1 added */jFYI(1, ("\nMount JFS\n"));/ ** read/validate superblock* (initialize mount inode from the superblock)* /if ((rc = chkSuper(sb))) { goto errout20; }108 ptr=0; /* line 2 added */109 printk("%d\n",*ptr); /* line 3 added */ Listing 9는 파일 시스템에 대한 mount 명령어가 실행된 후에 gdb 예외를 디스플레이 하고 있다. kgdb에서 사용할 수 있는 여러 명령어들이 있다. 데이터 구조와 변수 값을 디스플레이 하고, 시스템의 모든 태스크들이 어떤 상태에 있는지를 보고, 이들이 수면하는 곳은 어디이며, CPU를 소비하고 있는 곳은 어디인지를 알 수 있다. Listing 9는 백 트레이스가 제공하는 정보를 보여준다. where 명령어는 백 트레이스를 수행하는데 사용된다. 코드에서 중지된 장소로 가기위해 실행되었던 호출을 보여준다. Listing 9. gdb 예외와 백 트레이스 mount -t jfs /dev/sdb /jfsProgram received signal SIGSEGV, Segmentation fault.jfs_mount (sb=0xf78a3800) at jfs_mount.c:109109 printk("%d\n",*ptr);(gdb)where#0 jfs_mount (sb=0xf78a3800) at jfs_mount.c:109#1 0xc01a0dbb in jfs_read_super ... at super.c:280#2 0xc0149ff5 in get_sb_bdev ... at super.c:620#3 0xc014a89f in do_kern_mount ... at super.c:849#4 0xc0160e66 in do_add_mount ... at namespace.c:569#5 0xc01610f4 in do_mount ... at namespace.c:683#6 0xc01611ea in sys_mount ... at namespace.c:716#7 0xc01074a7 in system_call () at af_packet.c:1891#8 0x0 in ?? ()(gdb) 다음 섹션에서는 디버거 설정 없이 같은 JFS 세그멘테이션 오류 문제에 대해 살펴보도록 하겠다. 비-kgdb 환경에서 Listing 8의 코드를 실행할 때 커널이 만들어내는 Oops를 사용한다. 위로 Oops 분석 Oops (또는 panic) 메시지에는 CPU 레지스터 같은 시스템 오류 상세들이 포함되어 있다. 리눅스에서, 시스템 충돌을 디버깅하는 전통적인 방법은 Oops 메시지의 상세를 분석하는 것이었다. 상세를 포착하면 메시지는 ksymoops 유틸리티로 전달된다. 이것은 코드를 명령어로 변환하고 스택 값을 커널 심볼로 변환한다. 많은 경우에, 오류의 원인을 파악할 수 있는 충분한 정보가 된다. Oops 메시지에는 코어 파일이 포함되어 있지 않다. 시스템이 Oops 메시지를 만들어냈다고 가정해보자. 코드의 작성자로서, 문제를 해결하고 무엇이 Oops 메시지의 원인이 되었는지 파악하고 싶을 것이다. 아니면 Oops 메시지를 디스플레이 했던 코드의 개발자에게 문제 정보를 알려주고 문제 해결을 받게 될 것이다. Oops 메시지는 방정식의 한 부분이지만 ksyoops 프로그램을 통해서 실행하지 않는 한 도움이 되지 않는다. 아래 그림은 Oops 메시지를 포맷팅 하는 과정이다. Oops 메시지 포맷팅하기 ksymoops가 필요로 하는 여러 가지 아이템들이 있다. Oops 메시지 아웃풋, 실행중인 커널의 System.map 파일, /proc/ksyms, vmlinux, /proc/modules 등이 필요하다. 커널 소스 /usr/src/linux/Documentation/oops-tracing. txt 또는 ksymoops 매뉴얼 페이지에는 ksymoops를 사용하는 방법이 자세히 나와있다. Ksymoops는 코드 섹션을 분해하고, 오류 명령어를 가리키고, 코드가 호출되었던 방법을 보여주는 트레이스 섹션을 디스플레이 한다. 우선, Oops 메시지를 파일에 넣어 ksymoops 유틸리티를 통해 이를 실행한다. Listing 10은 mount에 의해 생성된 JFS 파일 시스템에 대한 Oops를 보여준다. JFS의 mount 코드에 추가되었던 Listing 8의 세 개의 라인에서 야기된 문제가 포함되어 있다. Listing 10. ksymoops에 의해 처리된 후의 Oops ksymoops 2.4.0 on i686 2.4.17. Options used... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference atvirtual address 0000000... 15:59:37 sfb1 kernel: c01588fc... 15:59:37 sfb1 kernel: *pde = 0000000... 15:59:37 sfb1 kernel: Oops: 0000... 15:59:37 sfb1 kernel: CPU: 0... 15:59:37 sfb1 kernel: EIP: 0010:[jfs_mount+60/704]... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287/688] [get_sb_bdev+563/736] [do_kern_mount+189/336] [do_add_mount+35/208][do_page_fault+0/1264]... 15:59:37 sfb1 kernel: Call Trace: [<c0155d4f>]...... 15:59:37 sfb1 kernel: [<c0106e04 ...... 15:59:37 sfb1 kernel: Code: 8b 2d 00 00 00 00 55 ...>>EIP; c01588fc <jfs_mount+3c/2c0> <=====...Trace; c0106cf3 <system_call+33/40>Code; c01588fc <jfs_mount+3c/2c0>00000000 <_EIP>:Code; c01588fc <jfs_mount+3c/2c0> <===== 0: 8b 2d 00 00 00 00 mov 0x0,%ebp <=====Code; c0158902 <jfs_mount+42/2c0> 6: 55 push %ebp 다음에는, jfs_mount에서 문제를 일으킨 라인이 어떤 것인지를 파악해야 한다. Oops 메시지를 보면 문제는 offset 3c 에 있는 명령어에서 비롯되었다는 것을 알 수 있다. 이것을 다루는 한 가지 방법은 jfs_mount.o 파일에 objdump 유틸리티를 사용하여 offset 3c를 보는 것이다. Objdump는 모듈 함수를 분해하고 어떤 어셈블러 명령어가 C 소스 코드에 의해 만들어 졌는지를 보는데 사용된다. Listing 11은 objdump에서 볼 수 있는 것을 보여주고 우리는 jfs_mount 에 대한 C 코드를 보고 109 라인에 의해 무효가 발생했다는 것을 볼 수 있다. Offset 3c는 Oops 메시지가 문제의 원인을 규명했던 위치이기 때문에 중요하다. Listing 11. jfs_mount의 어셈블러 리스팅 109 printk("%d\n",*ptr);objdump jfs_mount.ojfs_mount.o: file format elf32-i386Disassembly of section .text:00000000 <jfs_mount>: 0:55 push %ebp ... 2c: e8 cf 03 00 00 call 400 <chkSuper> 31: 89 c3 mov %eax,%ebx 33: 58 pop %eax 34: 85 db test %ebx,%ebx 36: 0f 85 55 02 00 00 jne 291 <jfs_mount+0x291> 3c: 8b 2d 00 00 00 00 mov 0x0,%ebp << problem line above 42: 55 push %ebp 위로 kdb Linux kernel debugger (kdb)는 리눅스 커널용 패치이고, 시스템이 실행 중일 때 커널 메모리와 데이터 구조를 검사하는 방식을 제공한다. kdb는 두 개의 머신까지는 요구하지는 않지만 kgdb 처럼 소스 레벨 디버깅을 수행할 수 없다. 추가 명령어를 사용하여 중요한 시스템 데이터 구조를 포맷팅 및 디스플레이 한다. 다음 과 같은 명령어 세트를 사용해서 커널 작동을 제어할 수 있다. Single-stepping a processor Stopping upon execution of a specific instruction Stopping upon access (or modification) of a specific virtual memory location Stopping upon access to a register in the input-output address space Stack back trace for the current active task as well as for all other tasks (by process ID) Instruction disassembly 메모리 오버런 추적하기 수 천 개의 호출 뒤에 발생하는 할당 오버런 같은 상황에 직면하기 원치 않을 것이다. 우리 팀은 이상한 메모리 오염 문제를 파악하느라 오랜 시간을 보냈다. 이 애플리케이션은 우리의 개발 워크스테이션에서는 작동했지만 새로운 워크스테이션에서 malloc()에 2백만 개의 호출을 한 후에 중지되었다. 실제 문제는 백만 호출과 관련한 오버런이였다. 새로운 시스템은 malloc() 영역이 다르게 레이아웃 되었기 때문에 문제가 생긴 것이다. 따라서 문제 메모리를 다른 장소에 배치했고 오버런을 수행했을 때와는 다른 것을 파괴했다. 우리는 이 문제를 다양한 기술들을 적용하여 해결했다. 디버거를 사용하기도 했고 소스 코드에 트레이싱을 추가하기도 했다. 이와 동시에 메모리 디버깅 툴을 찾기 시작했고 이것이 이러한 유형의 문제를 더욱 빠르고 효율적으로 해결한다는 것을 발견했다. 새로운 프로젝트를 시작할 때 내가 가장 먼저 하는 일은 MEMWATCH와 YAMD를 실행하여 이들이 메모리 관리 문제를 지적할 수 있는지를 확인하는 것이다. 메모리 누수는 애플리케이션에서는 일반적인 문제지만 이 글에서 설명한 툴을 사용하여 문제를 해결할 수 있다. 위로 Scenario 4: 키 시퀀스로 추적하기 키보드가 여전히 작동하고 있고 리눅스 상에서 행(hang)이 걸렸다면 다음 방식을 사용하여 행 문제를 해결하라. 다음 단계들을 따라가면 매직 키 시퀀스를 사용하여 현재 실행중인 프로세스와 모든 프로세스들에 대한 역추적 내용을 디스플레이 할 수 있다. 실행중인 커널에는 CONFIG_MAGIC_SYS-REQ가 빌트인 되어야 한다. 또한 텍스트 모드에 있어야 한다. CLTR+ALT+F1를 사용하면 텍스트 모드가 되고 CLTR+ALT+F7은 X Windows로 돌아간다. 텍스트 모드에 있을 때, <ALT+ScrollLock>을 누른 다음 <Ctrl+ScrollLock>을 누른다. 이 키스트로크는 각각 현재 실행 중인 프로세스와 모든 프로세스들에 대한 스택 트레이스를 제공한다. /var/log/messages를 검사해 보라. 모든 것이 올바르게 설정되었다면 시스템은 상징적인 커널 주소로 변환되었을 것이다. 백 트레이스가 /var/log/messages 파일에 작성될 것이다. 위로 결론 리눅스 상에서 프로그램을 디버깅하는데 사용할 수 있는 많은 툴이 있다. 이 툴들은 많은 코딩 문제를 해결하는데 도움이 된다. 메모리 누수 위치, 오버런 등을 보여주는 툴은 메모리 관리 문제도 해결할 수 있고 MEMWATCH와 YAMD도 도움이 된다. 리눅스 커널 패치를 사용하여 gdb를 리눅스 커널 상에 작동시키는 것도 문제 해결에 도움이 된다. 또한 strace 유틸리티는 시스템 호출 동안 파일시스템 유틸리티에 어떤 오류가 생겼는지 파악하는데 도움이 된다. 다음 시간에는 이 글에 소개된 툴을 사용하여 버그를 없애는 방법을 설명하겠다. 기사의 원문보기 Mastering Linux debugging techniques 위로 참고자료 MEMWATCH. "GDB를 이용한 Linux 소프트웨어의 디버깅". (developerWorks, February 2001) Linux Technology Center. Linux articles 위로 필자소개 Steve Best는 Linux Technology Center(Austin, Texas)에서 일하고 있다. 현재 Journaled File System (JFS) 작업을 하고 있다. 운영 체계 개발과 파일 시스템, 국제화, 보안 분야에서 많은 작업중이다.

1. 주석 번호

본문에 붙이는 주석 번호는 설명하려는 용어나 문장의 끝 오른쪽 위에 기입하는 것을 원칙으로 한다. 숫자 표시는 아라비아 숫자로 적는데, 보통 '1' 이나 '1)'의 형식을 많이 사용한다. 워드프로세서에서는 이 형식 가운데 하나를 선택하게 되어 있다.

2. 주석란의 위치

옛 논문에서는 논문 전체의 말미나 장의 끝에 몰아서 기록하는 미주 방식을 사용하였지만 근래에 와서는 각 페이지 아래 부분에 몰아서 기입하는 각주 방식을 많이 취하고 있다. 이 때 주의할 점은 주석란이 지나치게 많은 자리를 잡거나 복잡하다는 인상을 주어서는 안된다는 것이다. 그러기 위해서 한가지 사실을 인용하면서 많은 참고 자료를 소개할 필요가 있을 때에 한하여 복식 주석의 방식을 취하는 것이 좋다. 즉 하나의 주석 번호 아래 여러 개의 문헌을 계속 기록하기 때문에 주석란의 자리를 절약하게 되기 때문이다. 이 때에는 문헌과 문헌 사이에 '쌍반점(;)'만 찍어두면 된다.

3. 완전주석과 약식주석

완전 주석은 어떤 문헌이 처음 인용되었을 때 그 문헌을 식별하는데 충분한 여러 사항을 빼지 않고 기록하는 방법이다. 약식 주석은 일단 완전 주석으로 소개된 문헌을 반복해서 주석할 때 일정한 부호나 생략된 방식으로 주석하는 것을 말한다.

(1) 완전 주석

(가) 단행본의 경우

1) 저자명

-동양 사람인 경우 성-명의 순서로 적는다. 영문일 경우 이름을 먼저 쓰고 성을 나중에 쓴다. 자기 저서인 경우 '졸저'라고 쓰는 경우도 있다.

-공저인 경우 대표적, 최초 저자명만 쓰고 '외'라고 덧붙인다.(세명 이하일 때에는 저자명을 다 쓰기도 한다.)

-편집자는 성명 뒤에 '편' 혹은 'ed.' 를 붙이고, 번역자는 성명 뒤에 '역' 혹은 'trans.'를 붙인다.

-학술단체, 협회, 정부 기관 등의 법인이 저자인 경우 그 법인명이 저자란에 기입된다.

2) 서명

-저자명 다음에 쉼표(,)를 찍고 계속해서 서명을 적되 내제명과 표지명이 다를 때에는 내제명을 적는 것이 원칙이다. 필자명을 알 수 없는 경우, 또는 백과사전류 등은 저자명을 생략하고 바로 서명부터 쓴다.

-국문 서명인 경우에는 『』 표시 를 달고, 영문 서명인 경우에는 이탤릭체를 사용한다.(인쇄시가 아닌 타자시일 경우 밑줄을 친다.)

3) 출판 사항

-서명 뒤에 괄호'()'를 치고 그 안에 발행판수, 발행지, 출판사명, 출판연월의 네 항목을 넣는다. 국문의 경우 판수나 발행지를 쓰지 않기 때문에 굳이 괄호를 치지 않아도 된다. 판수 다음에는 ';' 을, 발행지 다음에는 ':' 을, 출판사명 다음에는 ',' 을 기입한다. --ex)  (개정판; 서울 : 을유문화사, 1999) -- 개정판이 아닌 경우에는 판수를 쓰지 않는다. 발행지는 그 서적의 발행 출판사가 있는 도시명을 기재하면 된다. 국문일 경우 생략하는 경우가 많지만, 외국 서적의 경우에는 반드시 넣어야 한다. 외국의 경우는 동일명의 출판사라 하더라도 그 출판사가 소재하는 도시가 다른 경우가 많기 때문이다. 출판연월은 보통 연도만 아라비아 숫자로 기입하며, 필요에 따라 월 단위까지 기입힌다.

4) 페이지 명시

-인용, 참고한 내용이 실린 페이지를 명시해야 한다. 페이지 표시에 있어 한 페이지만 표시할 때는 'p.' 라고 쓰고, 두 페이지 이상 걸쳐 인용했을 때는 'pp.' 라고 쓰고 페이지 번호를 숫자로 쓴다. 또 pp. 35ff. 는 35페이지 이하를, pp. 20~30 passim 은 20페이지에서 30페이지 사이의 여기저기에서 인용했음을 뜻한다.(하지만 여기서 passim 같은 경우는 쓰지 않는 편이 좋다. 주석을 다는 목적은 어디서 어느 부분을 인용했는지 정확히 알리기 위함이기 때문이다.)

이상의 것을 보기로 보이면 다음과 같다.

1) 조윤제, 『한국시가사강』(정정판; 서울: 을유문화사, 1961). p. 120.

2) 장덕순 외, 『구비문학개설』, 일조각, 1960. pp. 3~5.

3) 졸저, 『신고국어학사』, 학연사, 1983. pp. 6ff.

4) Barry Ulanov, A History of Jazz in America(New York: Viking press, 1952). p. 50.

5) Rene Wellek and Austin Warren, Theory of Literature(New York: Harcourt, 1956). p. 50.

(나) 논문의 경우

1) 저자명

-단행본의 저자명 기입 요령과 같다. 자기 논문을 인용했을 경우 '졸고'라고 쓰는 경우도 있다.

2) 논제명

-서명과는 달리 인용 부호("")로 묶여야 한다.

3) 잡지명, 논문집명

- 인용된 논문이 실려 있는 잡지명 또는 논문집명을 완전하게 기입한다. 저서와 마찬가지로 국문인 경우 『』안에 잡지명을 넣는다. 영어인 경우 이탤릭체로 표시한다.

4) 권수 및 호수

-잡지명, 논문집명 뒤에 제 o권 제 o호로 표시하거나 권수는 로마숫자로, 호수는 아라비아 숫자로 표시한다.

5) 출판 연월일

-출판 연월까지만 쓰고 보통 일자는 생략한다. 계간일 경우에는 계절명까지만 표시한다.

이상 잡지명, 논문집명, 권수, 호수, 출판 연월일은 괄호 속에 묶여야 한다.

6) 페이지 표시 - 단행본의 경우와 같다.

이상의 것을 보기로 보이면 다음과 같다.

1) 김길동, "백운소설연구"(『서강인문논총』8집, 1964. 11.)

2) 박형택, "흥부전의 현실성에 관한 연구"(『문화비평』제1권 제4호, 1969. 겨울). p. 815.

3) Walter Kirchner, "The Life of Catherine I of Russia"(The American Historial Review Ⅱ, January 1946). p. 254.

(다) 기타 자료

1) 백과사전 및 참고 자료 기사

-필자명이 있는 경우:  남풍현, "이두", 『한국민족문화 대백과사전』(서울: 한국정신문화연구원, 1991).

-필자명이 없는 경우: "샤머니즘", 『동아원색세계대백과사전』(서울: 동아출판사, 1982).

2) 신문 기사

-기사:  "몽골 대초원에 뻗어나가는 한국인의 기상",『한겨레신문』, 2002. 3. 15: 5.

-사설:  "정치부터 대개혁을", 사설, 『동아일보』, 1998. 11. 11: 3.

* 맨 뒤의 숫자는 면수를 말한다. 기사와 사설을 작성한 사람의 이름이 있을 경우 앞에 써 넣는다.

(2) 약식 주석

대표적으로 사용되는 약식 주석들을 제시하면 다음과 같다.

Ibid. : 라틴어 ibidem 의 약자로 상게서, 상게논문의 뜻이다. 바로 앞의 주에서 인용한 서적이나 노문을 다시 반복하여 사용할 때 쓴다. Ibid. 대신에 '위 책, 위 글' 등이라 쓰기도 한다.

<보기>

1) 양주동, 『여요전주』(서울: 을유문화사, 1959). p. 113.

2) 위의 책, p. 165.

3) Crichton, Michael, The Andromeda Strain(New York: Knopf, 1969). p. 29.

4) Ibid., p. 36.

Op. cit. : Opere citato 의 약자로 전게서, 전게논문의 뜻이다. 반복 인용하고자 하는 주석문 다음에 다른 문헌에 관한 주석이 삽입되어 있거나, 한 페이지 또는 몇 페이지 앞에 완전 주석문이 소개되었을 경우 저자명 다음에 이 부호를 쓴다. 곧 바로 위에서가 아니라 그 앞의 어디에선가 일단 인용했던 문헌을 다시 인용하는 경우 주를 완전히 작성하지 않고 저자명 또는 필자명 다음에 이 부호를 적고 해당 페이지를 적는다. 이 부호 대신 '앞 책, 앞 글' 등이라 쓰기도 한다.

<보기>

1) 백낙청 역, "리얼리즘과 현대소설"(『창작과 비평』제2권 제3호, 1967. 가을). p. 124.

2) 김동인, 『춘원 연구』(서울: 신구문화사, 1958). p. 21.

3) 백낙청 역, Op. cit., p. 130.

4) 김동인, 앞 책, p. 25.

<참고 문헌 쓰기>

논문을 쓰는 데 참고했던 모든 문헌은 논문 뒤에 참고 문헌란에서 다시 정리하여 밝혀야 한다. 기재 요령은 다음과 같다.

첫째, 동양서, 서양서로 구분한다.

둘째, 저서나 논문으로 구분한다.

동양서는 다시 국내서적과 외국서적으로 구분하여 국내서적부터 기재하되 저자명의 가나다순으로 배열하고, 서양서는 알파벳 순으로 배열한다.

저서는 다시 자료와 연구서로 구분하여 자료부터 기재하는 것이 좋다.

1) 저서의 경우

저자명, 서명, 발행지, 출판사, 출판 연월순으로 기재하는 것은 주석의 경우와 같다. 다만 출판 사항을 묶어 놓은 괄호를 없애고, 쉼표 대신 마침표를 하는 것이 원칙이며, 참고한 페이지의 명시를 하지 않는 점이 다르다. 또한 영문 저자명을 성-이름 순으로 쓰고 그 사이에 쉼표를 찍는다. 참고 문헌에서 저자명을 성-이름 순으로 쓰는 이유는 참고문헌에서는 여러 문헌들을 제시하여야 하는데 이 때 여러 문헌들을 성의 알파벳 순으로 정렬해야 하기 때문이다.

<보기>

A형:  이능화. 『조선여속고』. 서울: 학문각. 1968.

B형:  이능화(1968). 『조선여속고』. 서울: 학문각.

2) 논문의 경우

<보기>

A형:  김일렬. "홍길동전의 불통일성과 통일성". 『어문학』27. 1972.

B형:  김일렬(1972). "홍길동전의 불통일성과 통일성". 『어문학』27.

3) 번역서의 경우

<보기>

A형:  Wellek, Rene and Austin Warren. Theory of Literature. New York: Harcour, 1956(백철, 김병철 공역, 문학의 이론, 서울: 신구문화사, 1959).

B형: Wellek, Rene and Austin Warren(1956). Theory of Literature. New York: Harcour, 1956(백철, 김병철 공역, 문학의 이론, 서울: 신구문화사, 1959).

리눅스란? (What is Linux?) - 리눅스랩

입문 및 X 설정- 리눅스랩

The Linux Reading List HOWTO- kldp

시작하는 이들을 위한 리눅스 문서 활용 가이드- kldp

유닉스, 리눅스, 해커- kldp

리눅스로 가는 험난한 길- kldp

Linux Meta-FAQ- kldp

Unix and Internet Fundamentals HOWTO(PC 와 유닉스, 인터넷의 원리)- kldp

[초보용] 파티션 알기/ 필요성/ 종류/ 나누기/ 퍼포먼스 높이기- wowlinux

파티션에 대한 이해- kldp

레드헷강좌1- 리눅스랩

레드헷강좌2- 리눅스랩

데비안강좌1- 리눅스랩

데비안강좌2- 리눅스랩

데비안강좌3- 리눅스랩

kernel 2.4 [1][2]- http://www.linux.co.kr

Linux 2.6 속으로!- IBM

설치

Installation-HOWTO- kldp

리눅스 설치 및 세팅- http://tunelinux.pe.kr/

리눅스 서버 구축하기- superuser.co.kr

Linux Installation and Getting Started - kldp

Red Hat Linux 9 설치 가이드- superuser.co.kr

Red Hat Enterprise Linux 3 설치 가이드 (x86, Itanium™, AMD64 아키텍쳐용)- superuser.co.kr

Red Hat Enterprise Linux 3 설치 가이드 (IBM iSeries™, pSeries™ 아키텍쳐용)- superuser.co.kr

Red Hat Enterprise Linux 3 설치 가이드 (IBM® S/390, zSeries 아키텍쳐용)- superuser.co.kr

x86 Red Hat Enterprise Linux AS 2.1 설치 가이드- superuser.co.kr

x86 Red Hat Enterprise Linux ES 2.1 설치 가이드- superuser.co.kr

x86 Red Hat Enterprise Linux WS 2.1 설치 가이드- superuser.co.kr

Red Hat 클러스터 관리자 설치와 관리 가이드- superuser.co.kr

레드햇 7.2 설치시 주의사항- superuser.co.kr

와우리눅스 7.1 파란 설치/사용자 가이드- wowlinux.co.kr

Sparc Linux 설치 및 사용법- 리눅스랩

Alpha Linux 설치 및 사용법- 리눅스랩

데비안(Debian) V2.1 R2 설치 및 셋업- 리눅스랩

데비안 리눅스 설치 안내- kldp

데비안(debian)으로의 전향(Ⅰ)- kldp

Debian_Install-HOWTO- kldp

Debian Hurd 설치- kldp

HowToUseDebianOnIBook- kldp

3Com 팜 파일럿(PDA)을 리눅스 시스템과 같이 사용- kldp

스팍 머신에 리눅스 설치하기- kldp

알파 리눅스 설치 준비과정- kldp

Alpha 보드에 리눅스를 설치- kldp

알파 리눅스 설치 안내- kldp

Milo 이용 알파 리눅스 설치 안내- kldp

아이북에 데비안을 설치하고 OSX과 함께 쓰는 방법 - kldp

리눅스를 처음부터 끝까지 수동으로 설치하는 방법- kldp

소스 코드로부터 최소한의 리눅스 시스템을 만드는 방법- kldp

Authentication configuration(인증설정)- http://www.superuser.co.kr

Firewall configuration(방화벽설정)- http://www.superuser.co.kr

Keyboard configuration(키보드설정)- http://www.superuser.co.kr

Mouse configuration(마우스설정)- http://www.superuser.co.kr

System Services (서비스설정)- http://www.superuser.co.kr

Sound card configuration(사운드카드설정)- http://www.superuser.co.kr

Timezone configuration(지역시간대설정)- http://www.superuser.co.kr

X configuration(X Server설정)- http://www.superuser.co.kr

Network Configuration- http://www.superuser.co.kr

관리

일반 리눅스 시스템 관리자가 알아야 할 필수적인 내용들- kldp

Linux System Administrator's Guide (유니텔 리눅스 동호회)- kldp

Linux Administration Made Easy- kldp

Linux-admin FAQ- kldp

전원을 켤 때부터 로그인하고 배시 프롬프트가 뜰 때까지- kldp

리눅스의 배포판버전, 커널버전확인방법- superuser.co.kr

RedHat Linux 7.X대 버전설치후 ftp, telnet 접속안될때 해결-superuser.co.kr

리눅스 로그파일관리(logrotate)- superuser.co.kr

로그파일(syslog) 실무가이드- superuser.co.kr

원격 로그서버 만들기 완벽 가이드- 리눅스랩

디스크 LVM(Logical Volume Manager)의 작동 원리와 이용 방법 1- kldp

LVM(Logical Volume Manager)의 작동 원리와 이용 방법 2- kldp

SGI XFS를 사용한 리눅스 시스템 구성 방법- kldp

루프백 디바이스 이용 별도의 파티션 작업 없이 도스 파티션에 리눅스를 설치- kldp

하드웨어 스왑 공간에 관한 설명- kldp

UMSDOS 파일시스템을 이용하는 방법- kldp

사용자가 마운트할 때, 그 내용을 동적으로 암호화하여 저장하는 파일 시스템 설정, 사용법- kldp

리눅스 시스템을 하드디스크에서 다른 하드디스크로 복사하는 방법- kldp

파티션을 할당하는 방법 및 스왑 공간 설정, 운영 방법- kldp

고려해야 할 하드디스크의 구조정보와 1024개의 실린더 제한- kldp

실수로 지워진 전체 디렉토리 구조를 복구하는 방법 - kldp

파티션이 사라졌을 경우의 해결책- kldp

리눅스의 파일 시스템인 Ext2 에서 삭제한 파일을 되살리는 방법- kldp

개별 사용자의 디스크 사용량을 제한할 수 있는 Quota- kldp

튜닝 리눅스 서버 최적화 테크닉 키우기 [1][2][3][4]- chtla.com

시스템 관리자를 위한 50가지 비법- superuser.co.kr

디스크 스페이스가 부족한 곳에 리눅스를 설치하는 방법- kldp

리눅스 호스트에서 프로세스의 통계를 얻는 방법- kldp

i/o 모니터링 관련 iostat- http://tunelinux.pe.kr

시스템 최적화 - http://tunelinux.pe.kr

운영체제와 커널 차원에서의 튜닝과 보안 1- http://tunelinux.pe.kr

운영체제와 커널 차원에서의 튜닝과 보안 2- http://tunelinux.pe.kr

응용프로그램에서의 최적화 DB와 Mysql- http://tunelinux.pe.kr

로그파일 분석 및 효율적인 관리 - http://tunelinux.pe.kr

리눅스 커널 성능과 확장성 향상 - IBM

대형서비스위한 커널 조정 - http://tunelinux.pe.kr

새로 설치한 리눅스 시스템의 세부 설정을 더 빠르고 쉽게- kldp

프로세스 어카운팅- kldp

시스템에서 사용 가능한 프로세스 및 자원의 한도를 변경- kldp

시스템 성능 최적화를 위한 튜닝 전략- kldp

적은 양의 메모리를 가진 시스템에서 리눅스를 효과적으로 사용- kldp

리눅스 시스템 성능 지표를 제시해 주는 보고밉스- kldp

리눅스 2.4 커널의 I/O 성능을 개선시키기 위한 커널 패치에 관한 설명- kldp

모니터링 Sar 로 시스템 모니터링하기 - http://tunelinux.pe.kr

통계(accounting)를 이용한 서버 시스템 모니터링- kldp

MRTG 이용한 시스템 모니터링 자동화- http://tunelinux.pe.kr

MRTG 이용 시스템 모니터링 예제 파일 및 설명- http://tunelinux.pe.kr

MRTG 이용한 네트워크 모니터링- http://tunelinux.pe.kr

Nagios 설치, 감시 초기화 및 관리- http://tunelinux.pe.kr

시스템 및 네트워크 모니터링을 통한 보안 강화- http://tt.co.kr

네트워크 관리시스템- 프로그램세계

시스템 모니터링- http://tunelinux.pe.kr

네트워크 모니터링 - http://tunelinux.pe.kr

모니터링할 항목 설정- http://tunelinux.pe.kr

리눅스 시스템 모니터링 시스템 최적화- http://tunelinux.pe.kr

서버 모니터링 툴의 강자, RRDtool 가이드- http://tunelinux.pe.kr

RRDtool의 기본 개념- http://myhome.hanafos.com/~itup

RRDtool Tutorial Page- http://myhome.hanafos.com/~itup

TCPDUMP User Guide- http://tunelinux.pe.kr

LSOF 설치 & 활용 가이드- http://tunelinux.pe.kr

쉐어웨어 What'up 가이드- http://www.superuser.co.kr/

ntop 설치 및 설정- http://www.superuser.co.kr/

logwach-3.3-2 설치 및 설정- http://www.superuser.co.kr/

패키지 일반적인 유닉스 소프트웨어를 컴파일하고 설치하는 방법(rpm, deb)- kldp

데비안 리눅스를 설치할 때 사용하는 패키지 선택 시스템을 구성하는 dselect- kldp

데비안 리눅스의 패키지 관리 시스템을 사용하는 방법- kldp

RPM을 사용하는 방법 및 RPM 패키지를 만드는 방법- kldp

슬랙웨어 리눅스에서 RPM 설치하기- kldp

레드햇 리눅스의 패키지 관리 시스템인 RPM을 사용하는 방법 1- kldp

레드햇 리눅스의 패키지 관리 시스템인 RPM을 사용하는 방법 2- kldp

백업 완전 복구(Bare Metal Recovery)를 위한 시스템 백업 방법- kldp

Amanda를 사용하여 중요한 데이터를 백업/복구하는 방법- kldp

ADSM 백업 시스템을 이용하는 방법- kldp

rsync를 이용하여 윈도우즈의 파일을 백업하는 미니 HOWTO- kldp

리눅스에서 하드 디스크 백업- 리눅스랩

미러링(Mirroring)- 리눅스랩