Customer Reviews

Self-Service Linux®: Mastering the Art of Problem Determination

5 star:		(4)
4 star:		(2)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

I'm not sure I've ever given a book 5 stars, but this hits me where I live. The only complaint I have is that the title is misleading: it should have been "Learn how to troubleshoot any Linux problem you ever see" or something like that.

I once thought I'd like to write a book on trouble shooting and problem diagnosis. I'm glad I didn't, because this would make me feel like I had wasted my time.

This is truly excellent. I have already learned more here than I have anywhere in the past year, and look forward to spending a lot more time with this.

(long review)

I have just finished reading through the book Self service Linux from Wilding & Behman.
Let me point out, that when I read the description first I thought that it would be a troubleshooting & performance tweak guide.
However when I read through the first chapters I believed hat the title should say "Troubleshooting (GNU) Linux using Compiler and Debugger".
Finally after I read the whole book I decided the book deserves a different title something like

"The high art of problem investigation and software debugging". - I explain why below.

O.k the title issue out of the way lets focus on the contents of the book.

Table of Contents
Preface.
1. Best Practices and Initial Investigation. - (40p)
2. strace and System Call Tracing Explained. - (50p)
3. The /proc Filesystem. - (30p)
4. Compiling. - (30p)
5. The Stack. - (40p)
6. The GNU Debugger (GDB). - (80p)
7. Linux System Crashes and Hangs. - (20p)
8.: Kernel Debugging with KDB. - (10p)
9.: ELF: Executable and Linking Format. - (85p)
Appendix A: The Toolbox. - (13p)
Appendix B: Data Collection Script. - (12p)
Index. - (10p)


You can already conclude just by looking at the TOC that most is compiling and debugging related stuff.
So to make it clear, this book is NOT for the faint hearted neither is it for beginners. It is for the professionals class room, Power users,
Sysadmins, engineers etc. which either have 3-5 years Linux experience, are in need of a thorough understanding or are looking into developing software.

This is also backed up by the fact that Wilding has 15 years experience writing software and Behman 10 years
experience with (GNU) Linux alone.

Now, if you think 10 years back (1996) you will probably remember that GNU Linux was not that major yet.
So you can assume that Wilding and Behman carry "some" pioneer spirit which is reflected in their book all the way by
the rich details in every single chapter.

The book doesnt loose a lot of time and explains in Chapter 1 (The Intro) an overview of the investigation methods
and also spends an extra 10 pages for the symptoms versus cause explanations with its possible solutions.
That described experience alone can be an invaluable and a BIG timesaver.
If I may make a recommmendation: Make sure you read Chapter 1 thoroughly and DONT SKIM OVER IT !!
I made the mistake and skimmed over it. Almost at the end of the book I realised that many of the questions that
came up for me where caused by not having read the first Chapter thoroughly enough.

Having never done an strace before I found the strace chapter to be very detailed *almost a bit overwhelming for a second chapter.
Developers and senior IT professionals might feel here right at home. I found that the book is overall very detailed and contains so much information that I have
to admit I did not crasp all on the first read ;-). Especially the chapters about Compiling, the GDB and ELF are incredible detailed
and very thoroughly describe many steps which are absolutely necessary investigating software issues.
It is this thoroughly prepared "learned lessons" which the authors describe which makes the book so valuable.

Many people out there may have some experience with debugging and compiling and the typical three commands
"configure or make config, make and install", may have read the one or the other howto.
It is this book which takes those bits and puzzle peaces and allows you to put it together to see the whole picture
of how the software stuff works on the inside of your box.

Instructors and Teachers might use the book for prepareing tutorials and howto*s for classrooms or study courses.
There is enough info inside to make lots of them. It is also a very nice self study book.
The book is very readable, which is especially surprising considering the complex topics Wilding and Behman
are takling.

I personally enjoyed most the chapters about the /proc filesystem and the ELF. However I have to admit that ELF
(the default format for shared libraries and executables) is by no way a simple topic and I had to take a break several times in
order to be able to stay focused and remind me where I am. f.e. In the ELF chapter Wilding and Behman describe 17 of 29
Section names and types * which is a lot *.
They do not only describe their functions, but also their correlations and their importance in the debugging process. A this isnt enough,
Wilding and Behman step you through several debugging process and documented almost each single step I could think of - a gesture
which is very helpful, not only for beginners. They also explain the symbol resolution thats going on internal of the ELF files.
Finally they even explain 2 interception methods, including one showing you how to attach to a running process and debugging it !!

I could feel that this book is written with a lot of passion for a great topic. This is not only a compliment for the authors but also for the team behind the book.
The book is a VERY VALUABLE CONTRIBUTION - not only but - especially for junior members in the open source community.
I also believe that it is a very nice text for the classroom or selve study courses.

If you read until here, chances are high that you will like the book.


Summary:

Its nice to see such a thoroughly prepared text about compiling and debugging which is so readable.
The book allows anybody who has read a few howto's and was wondering how this all relates to each other, to finally get the big picture.
On top of it, Wildman and Behman put a lot of "best practices" tips and advices in the book.

Soo, to sum it up in one sentence:

FINALLY an easy understandable and very readable book about debugging and compiling. If you want to get only one book about compiling and debugging, this is it !


Note: This review was edited to remove some mispellings, however you may still find some typos in the text.

Wilding and Behman take us deep into diagnosing problems that can arise under linux. It seems best suited for an experienced developer or sysadmin. The issues it deals with tend to require this. For example, in many instances, the text gives example assembler code, for the x86 architecture. Most programmers, even when debugging, simply do not need to know the assembler version of their code. Or how the stack works.

However, for those of you who do, the text can be very useful in explaining what really happens under the bonnet, when you compile and run a program.

The book's cover suggests that it can also be useful to power users. I'm somewhat dubious of this. The most that a latter user might do or can do is to hand over a core dump or a screen capture of some diagnostics, to a programmer. Where the latter is the one who avails herself of this book.

The book devotes an entire chapter to the GNU debugger, gdb. More readable than the official GNU documentation on gdb. Given gdb's widespread use across of linux, and indeed over most versions of unix, this chapter may be the most helpful in the book, to some readers. It's a usage exposition that is distinct from a reference manual. Also, given the wealth of user interfaces these days, the text shows how to use a UI front end to gdb, called the Data Display Debugger. While some gdb purists might scorn this, and revert to their trusty command lines, others will welcome the DDD.

If you have been looking for help on gdb, the book is a good answer.

Whether you are a power user or a Linux system administrator if you like to work through and resolve problems yourself then you will want a copy of this book. The purpose of the book is to provide the reader with a best practices manual and guideline for how to approach and resolve problems in Linux. The first chapter is an introduction that includes the four phases of investigation and determining the difference between a symptom and a cause. From there the author leads the reader through how to use various tools to locate exactly what is happening. The rest of the book examines the details of the Linux system and includes items like using strace to trace system calls, using the information in the /proc filesystem to troubleshoot a problem, compiling the Linux kernel and how to deal with various compilation problems, the GNU debugger (a particularly good chapter), dealing with Linux crashes and hangs, using KDB to debug kernel problems, and the executable and linking format. Appendix A is a listing of common utilities for resolving problems, when to use them, and where to find them. This is a very good resource to keep handy when you are looking for the right tool but really don't know what it is. Self-Service Linux is highly recommended for all Linux power-users and administrators.

I started dabbling with linux last year after a problem installing software caused my Windows XP system to crash, requiring a rather time consuming re-install. Coupled with the numerous security concerns and performance issues, as well as an interest in learning how to program, I decided to switch over to linux.

Switching from linux is not an easy process, but if you want to learn about the ins and outs of that machine on your desk, running Linux will help.

That is where this book comes in. This book is less about troubleshooting/recipe book per se, but a book that integrates often separated areas from a good computer science curriculum--operating system concepts, hw/OS interaction, software engineering, and the lost art of debugging.

The author goes into extensive detail about the linux system, how to use built in tools such as the GCC compilers, the GDB (GNU debugger), and even how to read C source code, and how that C source gets translated into assembly. He also describes how different assembly optimizations can make debugging difficult.

Further detail is discussed in the chapters devoted to the memory heap and the memory stack, where high level programming constructs are mapped into the actual hardware registries, and the host of things that can go wrong.

If you are a serious C hacker/hobbiest like me, or a paranoid security professional, then this book is a must.

If you build software targeted for the Linux operating system, odds are you're going to run into a sticky problem now and then. You'll need to know how to debug either your program or the Linux kernel to see what's going on. This book can help you with that chore... Self-Service Linux - Mastering the Art of Problem Determination by Mark Wilding and Dan Behman.

Contents: Best Practices and Initial Investigation; strace and System Call Tracing Explained; The /proc Filesystem; Compiling; The Stack; The GNU Debugger (GDB); Linux System Crashes and Hangs; Kernel Debugging with KDB; ELF: Executable and Linking Format; The Toolbox; Data Collection Script; Index

This book has some pretty heavy-duty stuff it covers. It starts out with a well-thought-out methodology for debugging a system problem. These first 40 pages are like gold, and they'd be well-applied by *any* system developer, not just a Linux programmer. You'd think that developers would already know this stuff, but sadly it seems like a lost art all too often. From that point, things get deep into the different techniques for debugging problems specific to different areas of Linux. You many not need all the different sections, in that it may just be *your* program, not a problem with the kernel. But having all the information on debugging techniques in one place should cut down on a lot of research time, and will lead to much quicker system resolutions.

As Linux continues to grow in the market, I see the need for solid debugging skills to also be on the rise. This book will likely have a long shelf-life...