지식의힘!! [강컴]

Home >

리눅스 문제 분석과 해결 [- 아무도 가르쳐주지 않았던 리눅스 실전 노하우]

지은이 마크 윌딩 , 댄 버만 | 출판사 에이콘 | 발행일 2006년 09월 28일

	판매가	28,000원 → 25,200원 10%
	마일리지	10% 2,520원

	발행일	2006-09-28
	ISBN	8989975999 \| 9788989975991
	기타정보	번역서 \| 464쪽

	예상출고일	1~2일 이내 (근무일기준)
	배송비	무료배송

운영체계(OS)

종합지수 6p 143 위

※ 네이버 체크아웃으로 구매시 비회원으로 구매가
됨으로 강컴 마일리지는 적립 되지 않습니다.

	이 책의 원서
		Self-Service Linux: Determining Problems and Finding Solutions Prentice Hall \| Mark Wilding

운영체계(OS) 분야 베스트(월)

1.	리눅스 커널 내부구조
2.	IT EXPERT 리눅스 디바이스 드라이버
3.	유닉스 • 리눅스 프로그래밍 필수 유틸리티 : vi, make, gcc, gdb, cvs, rpm

운영체계(OS) 분야 베스트(주)

1.	아이폰 3 프로그래밍: iPhone SDK를 이용한 아이폰 개발
2.	[패키지]대용량 데이터베이스솔루션 I+대용량 데이터베이스솔루션 II
3.	Objective-C : 맥과 아이폰 애플리케이션 프로그래밍

운영체계(OS) 분야 신간

1.	Architecture of Windows NT
2.	Advanced Configuration and Power Interface
3.	Unix

리눅스 활용서. 이 책은 리눅스 사용시 발생하는 문제의 해결을 위한 실전 노하우를 담은 가이드북으로 비정상 종료, 정지, 성능 저하, 기대하지 않은 행동 양식, 기대하지 않은 결과를 시스템적으로 파헤치며, strace, gdb, kdb, SysRq, /proc 등 핵심적인 리눅스 문제 해결 도구에 통달하는 방법을 담았다.

1장 우수 문제 해결 기법과 초반 조사
1.1 시작
1.2 효과적으로 문제를 판별하기 위한 시스템 준비
1.3 네 단계 조사 과정
1.3.1 제 1 단계: 자기 힘으로 초반 조사 수행
1.3.2 제 2 단계: 효과적인 인터넷 검색
1.3.3 제 3 단계: 심도 있는 조사 수행 (우수한 문제 조사 기법)
1.3.4 제 4 단계: 도움/아이디어 얻기
1.4 기술적 조사
1.4.1 증상과 원인
1.5 상용 제품 문제 해결 방법
1.6 결론

2장 strace와 시스템 호출 추적
2.1 소개
2.2 strace란?
2.2.1 커널 측면에서 이해하기
2.2.2 언제 strace를 사용할까?
2.2.3 간단한 예제
2.2.4 동일한 예제를 정적으로 빌드한 경우
2.3 주요 strace 옵션
2.3.1 자식 프로세스 추적
2.3.2 시스템 호출 활동 시간 측정
2.3.3 상세 출력 모드
2.3.4 실행 중인 프로세스 추적
2.4 strace 영향과 고려 사항
2.4.1 strace와 EINTR
2.5 디버깅 실례
2.5.1 LD_LIBRARY_PATH 경로를 수정하여 시작 시간 줄이기
2.5.2 PATH 환경 변수
2.5.3 inetd 또는 xinetd (수퍼 서버) 추적하기
2.5.4 통신 오류
2.5.5 strace로 정지 상태 조사하기
2.5.6 역공학 (strace 도구가 동작하는 방식)
2.6 시스템 호출 추적 예제
2.6.1 예제 코드
2.6.2 시스템 호출 추적 코드 설명
2.7 결론

3장 /proc 파일시스템
3.1 소개
3.2 프로세스 정보
3.2.1 /proc/self
3.2.2 /proc/ 세부 사항
3.3.3 /proc/cpufreq
3.3.4 /proc/cpuinfo
3.3.5 /proc/devices
3.3.6 /proc/kcore
3.3.7 /proc/locks
3.3.8 /proc/meminfo
3.3.9 /proc/mm
3.3.10 /proc/modules
3.3.11 /proc/net
3.3.12 /proc/partitions
3.3.13 /proc/pci
3.3.14 /proc/slabinfo
3.4 시스템 정보와 조작
3.4.1 /proc/sys/fs
3.4.2 /proc/sys/kernel
3.4.3 /proc/sys/vm
3.5 결론

4장 컴파일
4.1 개요
4.2 GCC
4.2.1 GCC의 간단한 역사
4.2.2 GCC 버전 호환성
4.3 기타 컴파일러
4.4 리눅스 커널 컴파일
4.4.1 커널 원시 코드 얻기
4.4.2 아키텍처 관련 원시 코드
4.4.3 커널 컴파일 오류 처리하기
4.4.4 일반적인 컴파일 문제
4.5 어셈블리 목록
4.5.1 어셈블리 목록의 목적
4.5.2 어셈블리 목록 생성하기
4.5.3 어셈블리 목록 읽기와 이해하기
4.6 컴파일러 최적화
4.7 결론

5장 스택
5.1 개요
5.2 실생활에 비유한 예제
5.3 x86/x86-64 아키텍처 스택
5.4 스택 프레임이란?
5.5 스택 동작 방식
5.5.1 BP와 SP 레지스터
5.5.2 함수 호출 규약
5.6 스택 자료 참조와 수정
5.7 디버거로 스택 보기
5.8 스택 이해하기
5.8.1 직접 설계한 스택 역추적 기능
5.9 결론

6장 GNU 디버거(GDB)
6.1 개요
6.2 디버거를 사용하는 시점
6.3 명령행 편집
6.4 GDB로 프로세스 제어하기
6.4.1 GDB 명령행에서 프로그램 실행하기
6.4.2 GDB에 실행 중인 프로세스를 붙이기
6.4.3 core 파일 사용하기
6.5 데이터, 메모리, 레지스터 확인하기
6.5.1 메모리 맵
6.5.2 스택
6.5.3 메모리와 변수 확인하기
6.5.4 레지스터 덤프
6.6 실행
6.6.1 기본 명령
6.6.2 실행 제어 명령을 위한 환경설정
6.6.3 정지점
6.6.4 감시점
6.6.5 정지 시 표현식 출력
6.6.6 공유 라이브러리로 작업하기
6.7 원시 코드
6.8 어셈블리 언어
6.9 팁과 기교
6.9.1 프로세스를 붙이기: 다시 한번 돌아보기
6.9.2 변수와 함수의 주소 찾기
6.9.3 디버그 심볼이 없는 프로그램에서 구조체 보기
6.9.4 엔디언 방식 이해하고 다루기
6.10 C++를 디버깅하기
6.10.1 전역 생성자와 소멸자
6.10.2 인라인 함수
6.10.3 예외
6.11 스레드
6.11.1 스택 공간 부족
6.12 DDD (DATA DISPLAY DEBUGGER)
6.12.1 데이터 표시 윈도우
6.12.2 원시 코드 윈도우
6.12.3 기계어 윈도우
6.12.4 GDB 콘솔 윈도우
6.13 결론

7장 리눅스 시스템 비정상 종료와 정지
7.1 소개
7.2 정보 수집
7.2.1 syslog 설명
7.2.2 직렬 콘솔 준비하기
7.2.3 직렬 널 모뎀 케이블 연결하기
7.2.4 컴퓨터 시작 과정에서 직렬 콘솔 활성화하기
7.2.5 SysRq 커널 마법 키 활용하기
7.2.6 웁스 보고서
7.2.7 수동 커널 트랩 추가하기
7.2.8 웁스 보고서 검사하기
7.2.9 실패한 코드 행 찾아내기
7.2.10 커널 웁스와 하드웨어
7.2.11 cscope로 커널 원시 코드 색인하기
7.3 결론

8장 KDB를 사용한 커널 디버깅
8.1 소개
8.2 KDB 활성화하기
8.3 KDB 활용하기
8.3.1 KDB 시작하기
8.3.2 일반 동작으로 복귀하기
8.3.3 기본적인 명령어
8.4 결론

9장 ELF
9.1 소개
9.2 개념과 정의
9.2.1 심볼
9.2.2 목적 파일, 공유 라이브러리, 실행 파일, 코어 파일
9.2.3 링킹
9.2.4 런타임 링킹
9.2.5 프로그램 인터프리터/런타임 링커
9.3 ELF 헤더
9.4 세그먼트와 섹션 개괄
9.5 세그먼트와 프로그램 헤더 테이블
9.5.1 텍스트와 데이터 세그먼트
9.6 섹션과 섹션 헤더 테이블
9.6.1 문자열 테이블 형식
9.6.2 심볼 테이블 형식
9.6.3 섹션 이름과 유형
9.7 재배치와 위치 독립 코드
9.7.1 PIC와 PIC가 아닌 경우 비교
9.7.2 재배치와 위치 독립 코드
9.7.3 재배치와 링킹
9.8 ELF 목적파일에서 디버깅 정보 제거하기
9.9 프로그램 해석기
9.10 심볼 결정
9.11 문제 분석을 위한 약한 심볼 활용
9.12 GOT를 활용한 고급 가로채기
9.13 원시 파일
9.14 ELF API
9.15 다른 정보
9.16 결론

부록 A 디버깅 도구 상자
A.1 소개
A.2 프로세스 정보와 디버깅
A.2.1 도구: GDB
A.2.2 도구: ps
A.2.3 도구: strace (system call tracer)
A.2.4 도구: /proc 파일시스템
A.2.5 도구: DDD (Data Display Debugger)
A.2.6 도구: lsof (List Open Files)
A.2.7 도구: ltrace (library call tracer)
A.2.8 도구: time
A.2.9 도구: top
A.2.10 도구: pstree
A.3 네트워크
A.3.1 도구: traceroute
A.3.2 File: /etc/hosts
A.3.3 File: /etc/services
A.3.4 도구: netstat
A.3.5 도구: ping
A.3.6 도구: telnet
A.3.7 도구: host/nslookup
A.3.8 도구: ethtool
A.3.9 도구: ethereal
A.3.10 File: /etc/nsswitch.conf
A.3.11 File: /etc/resolv.conf
A.4 시스템 정보
A.4.1 도구: vmstat
A.4.2 도구: iostat
A.4.3 도구: nfsstat
A.4.4 도구: sar
A.4.5 도구: syslogd
A.4.6 도구: dmesg
A.4.7 도구: mpstat
A.4.8 도구: procinfo
A.4.9 도구: xosview
A.5 파일과 목적 파일
A.5.1 도구: file
A.5.2 도구: ldd
A.5.3 도구: nm
A.5.4 도구: objdump
A.5.5 도구: od
A.5.6 도구: stat
A.5.7 도구: readelf
A.5.8 도구: strings
A.6 커널
A.6.1 도구: KDB
A.6.2 도구: KGDB
A.6.3 도구: ksymoops
A.7 기타
A.7.1 도구: VMWare 워크스테이션
A.7.2 도구: VNC 서버
A.7.3 도구: VNC 뷰어

부록 B 자료 수집 스크립트
B.1 개괄
B.1.1 -thorough
B.1.2 -perf, -hang , -trap, -error
B.2 스크립트 돌리기
B.3 스크립트 소스 코드
B.4 면책 조항

Mark Wilding
마크 윌딩은 현재 유닉스와 리눅스 편의성 기술을 전문적으로 연구하는 선임 개발자로 IBM에서 근무하고 있다. 15년 이상 소프트웨어 개발 경험을 토대로, 운영체제, 네트워크, C/C++ 개발, 편의성, 품질 공학, 컴퓨터 하드웨어 부문에서 다양한 경험을 쌓아왔다.

Dan Behman
댄 버만은 토론토 IBM 소프트웨어 연구실에서 리눅스 플랫폼 개발을 위한 DB2 UDB 개발팀 일원으로 근무하고 있다. 리눅스 10년 이상 경력을 자랑하며, x86-64, z시리즈, 파워 플랫폼을 포함한 리눅스가 지원하는 최신 아키텍처에 DB2 UDB를 이식하고 동작하는 작업에 참여했다.

[역자 소개]

박재호
포항공과대학교 컴퓨터공학과 학부와 포항공과대학교 컴퓨터공학과 대학원을 졸업했다. 회사에서 임베디드 리눅스 관련 디바이스 드라이버와 커널 프로그래밍을 맡고 있다. 종종 컴퓨터와 책에 대한 재미있는 글을 블로그(http://jhrogue.blogspot.com)에 올리고 있다. 지은 책으로 “IT EXPERT, 임베디드 리눅스”(한빛미디어), 옮긴 책으로 “조엘 온 소프트웨어”(에이콘), “리눅스 디버깅과 성능 튜닝”(에이콘) 등이 있다.

이해영
포항공과대학교 컴퓨터공학과 학부와 퍼듀대학교 전자계산학과 대학원을 졸업했다. 오랫동안 소프트웨어 개발에 종사하다가, 2006년 현재 미국에 있는 소프트웨어 개발 회사에서 지역화 전문가로 일하고 있다. 옮긴 책으로 “조엘 온 소프트웨어”(에이콘), “리눅스 디버깅과 성능 튜닝”(에이콘) 등이 있다.

[저자 서문]

리눅스는 일반 가정과 사무실에서 사용하기에 최적인 운영체제이다. 강력하며, 여느 상용 운영체제 못지 않게 안정적이고, 보안이 뛰어나며, 무엇보다도 오픈 소스이다. 하지만 가정이나 사무실에서 리눅스를 사용할지 말지를 결정하는 가장 큰 요인 중 하나는 서비스와 지원이다. 리눅스는 세계 도처에 있는 자원 봉사자 수천 명이 개발하기 때문에 문제 발생 시 누구에게 도움을 청해야 할지가 분명하지 않다.

진정한 리눅스 정신에 의거하여, 리눅스는 상용 운영체제와는 다소 상이한 지원 방식을 채택하고 있다. 전대 미문의 전문가 커뮤니티가 존재하며, 최첨단 문제 진단 분석과 해결 도구를 제공할 뿐만 아니라, 당연히 제품 자체에도 소스 코드가 들어 있다. 이러한 자원 외에도 IBM과 같은 회사에서 내놓은 전문 리눅스 지원 서비스와 레드햇이나 노벨/수세와 같은 리눅스 판매업체가 여럿 존재한다. 하지만 전문 서비스나 판매업체를 거치지 않고 리눅스에서 제공하는 자원을 최대한 “스스로 활용하는” 방법을 이 책에서 주요 주제로 다룬다.

리눅스를 “스스로 활용한다”라는 의미는 사람마다 다르다. 가정에서 리눅스를 사용하는 사람에게는 리눅스 사용이 한층 즐거워진다는 뜻이다. 사무실에서 리눅스를 사용하는 사람에게는 리눅스 관련 문제를 신속하고 효과적으로 진단함으로써 조직 내 자신의 가치와 시장성을 높일 수 있다는 뜻이다. 기업 전략의 일부로 리눅스를 채택해야 할지를 고민하는 기업에게는 리눅스 채택 전략에 따른 운영 경비 감소와 투자 수익(ROI, Return of Investment) 증가를 뜻한다. 어느 유형에 속하는 사용자이든, 리눅스 사용 경험과 투자로부터 최대한 많은 이익을 얻어내야 한다는 점이 중요하다.

[역자 서문]

전문적인 개발자라면 이구동성으로 코드를 쓰는 작업보다 읽는 작업에 더 많은 시간을 투입한다고 이야기한다. 다시 말해서, 코드 작성보다 작성 후 개선/검토/디버깅에 훨씬 많은 노력이 들어가며 이런 과정은 취미 생활이나 학교 과제로 프로그램을 작성하지 않는 이상 상용 제품을 만드는 과정에서 필수라고 보여진다. 하지만 유감스럽게도 대학교나 컴퓨터 학원에서 디버깅을 전문적으로 가르친다는 말은 한번도 들어보지 못했다. 가장 시간을 많이 쏟는 분야에 대한 체계적인 지식 습득 경로가 없다는 사실은 사뭇 충격적이기까지 하다.

과거 유닉스 시절에는 모든 시스템 프로그래머가 바로 시스템 관리자였고 시스템 관리자가 바로 시스템 프로그래머였는데, 요즘 들어와서 명확한 선이 그어지면서 갈수록 시스템 관리자와 프로그래머 업무가 분리되면서, 좀더 전문적으로 자신이 맡은 작업을 진행할 수 있다는 장점이 있는 반면에 학제간 연구를 통한 통합적인 문제 분석이 어렵다는 단점이 나타나고 있다. 시스템 관리자는 과연 스크립트 언어를 벗어난 본격적인 프로그램 분석 실력이 필요 없을까? 프로그래머는 기초적인 명령어 사용법 이외에 시스템 관리자의 전유물이라고 여기던 프로세스나 목적 파일에 대한 정보 확인 명령에 숨겨진 의미를 파악할 필요가 없을까?

이렇게 모순적이고 어려운 현실에 직면한 개발자들에게 도움을 주기 위해 올해 초에 에이콘 출판사를 통해 『리눅스 디버깅과 성능 튜닝』이라는 제목을 붙인 번역서를 출간했었다. 『리눅스 디버깅과 성능 튜닝』은 현장에서 바로 써먹을 수 있도록 리눅스에서 제공하는 다양한 도구 사용법과 활용 방안을 예를 통해 설명하고 있다. 하지만 『리눅스 디버깅과 성능 튜닝』은 방대한 도구를 한정된 지면에 다루고 있기에 아무래도 폭에 비해 깊이가 얕다는 문제점이 있었으며, 이런 단점을 보완할만한 다른 책에 대한 요구가 커지고 있다.

이와 같은 상황에서 마침 프렌티스 홀에서 출간한 『Self-Service Linux』를 접하게 되었고, 책 내용을 검토한 결과 『리눅스 디버깅과 성능 튜닝』과 비교해서 다루는 도구의 폭은 좁지만 아무도 가르쳐주지 않았던 비밀스러운 활용 방안을 충분한 깊이로 다루고 있다는 결론을 내려서 번역 작업을 서두르게 되었다.

이 책은 단순한 옵션 나열이나 피상적인 명령어 사용법을 다루는 책이 아니다. 마치 고급 시스템 관리자를 위한 문제 해결 서적이라고 착각하기 쉽지만, 실제로 리눅스 전문 개발자들이 반드시 알고 넘어가야 하는 핵심적인 지식을 담고 있는 알짜 서적이다.

하나같이 유익한 내용들이지만, 특히 1장, 5장, 6장, 9장을 눈여겨보기 바란다. 다른 책에서 쉽게 접하지 못하는 전반적인 문제 해결 전략을 1장에서 다루고 있으며, 스택에 대한 명쾌한 설명이 5장에서 전개된다. 심지어 원시 코드가 없을 경우에도 문제 원인을 gdb로 추적하는 방법을 6장에서 실제 예를 들고 있으며, 마지막으로 중요한 정보를 담고 있음에도 불구하고 개발자 사이에서 외면 받고 있는 ELF에 대한 설명이 9장에 나온다. 커널 단으로 내려가지 않고서도 리눅스 내부 구조를 이렇게 명쾌하게 그릴 수 있다는 사실이 놀라울 따름이다.
- 박재호

이 책에서 가장 감동적이고 핵심적인 장을 꼽으라면 1장 “우수 문제 해결 기법과 초반 조사”이다. 리눅스 환경에서 개발하는 사람이라면, 반드시 읽어야 할 장이다. 1장 내용만 충분히 숙지하여 머리와 가슴에 넣어도, 이 책 값어치 중에서 80%는 얻어냈다고 생각한다.

흔히 “실력 있는 사람”과 “사실을 많이 습득한 사람”을 혼동한다. 특히나 개발 분야에서는 더욱 그렇다. API를 좔좔 외우고 명령 옵션을 쫙 꿰고 있는 사람을 실력이 있다고 여긴다. 하지만 습득한 사실만으로 해결할 수 있는 문제에는 한계가 있다. 문제를 해결하는 능력, 즉 실력은 단순한 지식 이상이 필요하다. (참고로, 반드시 자신의 힘으로 문제를 해결해야 한다는 뜻은 아니다. 올바른 사람을 찾아서 원하는 답을 얻어내는 기술도 능력이고 실력이다.)

제목 그대로, 이 책은 리눅스 시스템을 스스로 운영하는 방법, 즉 리눅스 시스템이라는 영역에서 문제를 해결하는 능력을 키우는 방법을 소개한다. strace(2장)에서 GDB(6장)을 짚고, ELF(9장)에 이르기까지, 이 책에서 다루는 지식은 방대하다. 자칫하면, 여기에 묻혀 중요한 줄기를 놓칠 수 있다. 예를 들면, 이 책은 GDB 최적화 옵션도 설명하지만, 동시에 어떤 문제와 어떤 상황에서 GDB를 사용하는지도 설명한다. 리눅스 상에서 문제를 디버깅하려는 개발자라면, 어떤 도구가 어떤 상황에 적합한지 이해해야 한다. 하지만 최적화 옵션을 일부러 하나하나 암기할 필요는 없다고 생각한다. 최적화 옵션이 무엇인지 그리고 어떤 문제를 일으킬 수 있는지만 이해한다면, 각 옵션마다 내재된 있는 정확한 의미는 필요할 때 찾아보면 된다.

도서관에 있는 책 내용을 몽땅 암기하는 능력보다는 원하는 책과 정보를 빠르고 신속하고 정확하게 찾아낼 수 있는 능력이 더 유용하다. 책을 읽으면서 이런 점을 염두에 두었으면 한다. 그리고 가능하다면 서문과 1장에 충분한 시간을 할애하기 바란다. 좀 딱딱하다 싶을 내용이지만, 의외로 재미있고 활기차다. 이왕이면 독자 여러분이 즐겁게 읽었으면 좋겠다.
- 이해영