Self-Service Linux: Mastering the Art of Problem Determination

by Dan Behman and Mark Wilding

This book should be an essential part of every company's Linux adoption plan to keep the total cost of ownership (TCO) down and improve the ROI of their Linux strategy. It is also a book that advanced... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 013147751X
• ISBN13: 9780131477513
• Release Date: September 2005
• Publisher: Prentice Hall
• Length: 431 Pages
• Weight: 1.98 lbs.
• Dimensions: 1.1" x 7.0" x 9.2"

Customer Reviews

A must for hardcore hackers

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.

The high art of problem investigation and software debugging

(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 thor

Required reference for power users and administrators

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.

nice chapter on explaining GDB

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.

I don't give 5 stars lightly

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.