Designed as an introduction to UNIX system crash dump analysis, this is the first book to discuss in detail UNIX system panics, crashes and hangs, their causes, what to do when they occur, how to collect information about them, how to analyze that information, and how to get the problem resolved. KEY TOPICS: Part One covers theory and tools. Part Two looks inside UNIX, from the header files to hardware tape drives. Part Three provides actual case studies of software, hardware, data, and system fault problems. For systems and network administrators and technical support engineers responsible for maintaining UNIX computer systems and networks.
"synopsis" may belong to another edition of this title.
A first aid guide for UNIX system and network administrators, this book provides quick solutions to a variety of UNIX system problems. It discusses in detail UNIX system panics, crashes and hangs, their causes, what to do when they occur, how to collect information about them, how to analyze that information, and how to get the problem resolved.From the Inside Flap:
You've spent hours pouring over UNIX¨ vendor specifications and benchmarks. Managers, system administrators and accountants have gone over the various vendors' specs and weighed them against your company's needs and the costs. Finally, everyone agreed and selected the right computer for the right price.
You attended System Administration training courses prior to the system's delivery, giving you time to brush up on your skills, possibly learning some of the intricacies of a newer release of the operating system.
The vendor delivered the system, provided installation assistance, and gave you some additional hints on how to get the most from your system.
Since going online, you have been monitoring the system's performance and following advice from a good performance tuning book. You have fine-tuned your system for optimum performance during the periods of heaviest use and have even found some wins during lighter use.
Combining your programming skills and your system administration experience, you have utilized the cron daemon well. Backups are fully automated, system log files are regularly rotated and trimmed, and /etc/syslog.conf has been modified to suit your needs. You've programmed your system to nearly maintain itself, while letting you know when it needs your help, thus limiting the amount of time you have to babysit it.
The system has become a well-oiled machine, thanks to all of your time and effort. You've done well and the machine has been running like a champ for quite some time now. The users are happy and management is happy. You can put your feet up on the desk and rest now or move onto your next major project.
The phone rings and you answer. A user says his terminal is dead. As soon as you hang up, you receive another call and another complaint about no response from the computer. Ignoring the next call, you get to the computer console just in time to see the word "Panic" scroll off the top of the screen. Another message says something about "dumping," and now the system appears to be rebooting itself.
Computers crash. It's just a fact of life. Depending on the hardware and software involved, some computer systems crash rather frequently, some once in a blue moon, some never. When the computer system in question is running the UNIX operating sys tem, we often refer to the crash as a "panic."
What causes panics? What is happening when you see the "dumping" messages? How can you find the source of these and get the system back online and into working condition? This book answers those questions and many, many more.
What will Panic! teach you?
Ever since UNIX existed, there have been a slowly growing number of people who specialize in the black art of UNIX system crash dump analysis. These folks are able to analyze the postmortem files created when a UNIX system crashes and glean some ide a of the cause. System crash dump analysis is normally something only the gurus handle. Analysis of dumps is usually a trade secret passed on from the senior gurus to the juniors. Few, if any, courses or books exist on the topic. However, as UNIX continues to mak e its way deeper and deeper into the commercial world, we believe it's time to share some of the tricks of the trade.
Some UNIX gurus will tell you that a book can't be written about this subject. UNIX system crash dump analysis is simply too technical and requires access to the highly coveted and rather expensive UNIX source code. Another argument against a book on this topic is that the kernel, the heart of the UNIX operating system, continues to evolve. How can someone write a book that aims at a moving target?
While we understand these valid points of view, we also see the necessity and desire for general knowledge in this subject area in the UNIX user world as well as in UNIX service and support organizations. True, due to licensing agreements, we cannot show you yesterday's or today's UNIX source code in a compilable format; however, we certainly can get you started in the right direction when it comes to figuring out why your computer decided to suddenly keel over.
How will we do this? Well, for starters, together we will explore some of the files in the /usr/include directories. These files, known as "header files," provide great insights into UNIX and are actually the only part of the source tree that is normally provided to users on UNIX systems. We will show you how to interpret the valuable information tucked away in these files and how to use the data there. In some cases, the demonstrations in this book will quite clearly point you to your system's problem and a solution. When a solution is not immediately obvious, usually due to a need to dive into the source code itself, we show you how to collect the most useful information available, which in turn you can forward to your system vendor. The more detail of the problem you can provide up front, the sooner your vendor can find a solution for you.
In the case of some vendors, once you've collected some system crash dump information, you may find your problem and the solution provided in a customer service newsletter, technical bulletins, or other post- sales support media provided by your vendor. For example, Sun customers may arrange to receive SunSolve, the SunServices information databases provided on CD-ROM, which provides this type of problem-and-resolution information along with much more technical data.
So many flavors of UNIX
Since both of us work for Sun Microsystems, this book is based on Sun's Solarisª 1 and Solaris 2 operating environments. Solaris 1 is based on the implementation of UNIX known as BSD, which was done by the University of California at Berkeley (aka U CB). Solaris 2 is based on AT&T's SVR4 (System V Release 4) implementation. Both of the Solaris operating environments contain much more than just different flavors of the UNIX operating system. They also include OpenWindows and many other useful tools.
Even though Solaris is our working base, we both have experience with other flavors of UNIX, and we know that our audience is also working with a wide mix of UNIX, XENIX¨, and other UNIX-like operating systems. So, with that in mind, as well as our limitations about not disclosing source, we endeavor to keep this book as generalized as possible while guiding you toward the goal of problem resolution.
If you are already a UNIX guru, this book might show you a few things you didn't already know, but not much more. Conversely, if you have never heard of UNIX before, you'll probably run into trouble beyond the first few chapters. However, if you ha ve a good working knowledge of UNIX, maybe a couple years as a system administrator or support engineer, this book is for you.
Since we'll be working with SPARC¨ assembly language and the C programming language, any programming skills you have will be useful while you read this book. However, we understand that not every system administrator is an experienced programmer. W e have done our best to help those of you who have yet to gain those skills.
Purely for simplicity, we use the male gender throughout this book. We know that the UNIX world includes people from more than one sex, so please don't take this limitation personally.
When discussing UNIX commands, we use boldface type, for example, when talking about the adb command or the vi editor. When discussing kernel variables or symbols, such as msgbuf or panicstr, or other program variables, we use italics. When referring to routines by name, we use () (parenthesis) after their name and italics again. As an example, we will talk a lot about the panic() routine.
When we refer to a directory, filename, or macro filename, such as /usr/include/sys/vnode.h, we again use the boldface. It will be quite obvious when we are discussing file names or commands, so we expect you won't get confused.
When referring to assembly instructions such as sethi or SPARC processor register such as %g0, we use courier font.
When demonstrating commands, we show them in a box, using courier font. User input is shown in bold. For example:
Sun Jan 8 19:12:30 GMT 1995
Hiya... last head
Fri Jan 6 16:29 - 16:31
Fri Jan 6 16:06 - 16:29
Thu Jan 5 14:36 - 14:36
Thu Jan 5 10:23 - 10:25
Wed Jan 4 22:24 - 22:24
Wed Jan 4 21:42 - 21:58
Mon Jan 2 21:51 - 22:07
Sat Dec 31 23:01 - 21:51
Sat Dec 31 22:49 - 22:58
Sat Dec 31 22:43 - 22:47
Also, since we include actual screen dialogs, as shown above, you will see a couple of different shell prompts being used. In the above example, "Hiya..." is the shell prompt.
Occasionally, to make things a bit more obvious, we underline key data in screen output. When we to do this, we point it out to you. Finally, you'll find that throughout this book, we, the two authors, talk directly to you, our UNIX-guru-in-training. When we refer to the customer who sent us the crash dump, he will be referred to as a third person.
Contacting the authors
If you wish to contact the authors (good news is always welcome!) for any reason, feel free to email:
Welcome to Panic!
This is the first book of its kind that we know of. While we would love to see every system administrator, software engineer, and support specialist who reads it become a system crash dump hacker, we also sincerely hope, and expect, that you'll rarely make practical use of this book and that it will collect dust on your bookshelf. After all, system crashes, no matter how much you know about them, can ruin a perfectly good day!
Ready? Let's get started!
"About this title" may belong to another edition of this title.
Book Description Prentice Hall PTR, 1995. Paperback. Book Condition: New. Bookseller Inventory # DADAX0131493868
Book Description Prentice Hall PTR, 1995. Paperback. Book Condition: New. book. Bookseller Inventory # 0131493868
Book Description Book Condition: Brand New. Book Condition: Brand New. Bookseller Inventory # 97801314938651.0