For systems and network administrators and technical support engineers responsible for maintaining UNIX computer systems and networks. 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.
Book Description
Editorial Reviews
From the Publisher
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.
What happened?
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.
The audience
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.
Conventions used
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:
Hiya... date
Sun Jan 8 19:12:30 GMT 1995
Hiya... last head
root
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.
What happened?
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.
The audience
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.
Conventions used
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:
Hiya... date
Sun Jan 8 19:12:30 GMT 1995
Hiya... last head
root
pts/4
s4c-ods
Fri Jan 6 16:29 - 16:31
(00:02)
peterd
pts/4
s4c-ods
Fri Jan 6 16:06 - 16:29
(00:23)
peterd
pts/7
greener
Thu Jan 5 14:36 - 14:36
(00:00)
peterd
pts/4
greener
Thu Jan 5 10:23 - 10:25
(00:02)
kbrown
ftp
zatch.Corp
Wed Jan 4 22:24 - 22:24
(00:00)
kbrown
ftp
zatch.Corp
Wed Jan 4 21:42 - 21:58
(00:15)
kbrown
pts/1
ulysses.East
Mon Jan 2 21:51 - 22:07
(00:15)
kbrown
pts/1
sunryse.East
Sat Dec 31 23:01 - 21:51
(1+22:49)
kbrown
ftp
pasta.UK
Sat Dec 31 22:49 - 22:58
(00:08)
kbrown
ftp
sunryse.East
Sat Dec 31 22:43 - 22:47
(00:04)
Hiya...
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:
chris.drake@sun
kimberley.brown@sun
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!
Product Details
Would you like to update product info or give feedback on images?
|
More About the Author
Discover books, learn about writers, read author blogs, and more.
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
9 of 9 people found the following review helpful:
5.0 out of 5 stars
Exelent book for the kernel module programmer,
By A Customer
This review is from: PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM) (Paperback)
A very good text with three parts. The first is about using adb, and it's full of examples and exercises. After reading it you will see the reason this old tool is still heavily used and will be able to use it yourself.The second is an overview of the internal structure of UNIX in general with many details on Solaris, that you won't find anywhere else. It's an enlightning view of the inner design of Solaris. The third part is a case history of some crash dumps analysis and what was done to discover the problems that caused it. It's almost as good as a good spying book ! . In my opinion it's the best part of the book, but you'll need to read the first two to understand it. All in all, an unavoidable book for the writers-to-be of device drivers and other kernel modules, maybe the best one. But I won't use it as a reference book.
4 of 4 people found the following review helpful:
5.0 out of 5 stars
Great book!,
By
This review is from: PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM) (Paperback)
I believe this book is not only an exceptional tutorial on crash dump debugging techniques but also a good review of the Solaris kernel architecture and data structures. The authors have done a great job explaining such highly technical and complicated topics like processor architecuture, stacks, file system data structures, adb, assembly code, etc. Not exactly bed-time reading!Although some of the examples are a little bit out of date (Sparc V9 and Solaris 8 are the industry norm more or less) and a second edition is becoming more and more a necessity, I will still give this book 5+ stars. The excellent presentation and exemplary technical make Crash! (relatively) very easy to read but several years of strong Solaris experience, a good understanding of computer architecure, OS fundamentals, data structures, and some knowledge of C are still required for full comprehension of the content. Before diving into this book I would strongly encourage the potential reader to at least review "UNIX Internals: The New Frontiers" by Uresh Vahalia, "Design of the Unix Operating System" by Marice J. Bach, Maurice Bach or "Solaris Internals: Core Kernel Architecture" by Jim Mauro, Richard McDougall.
4 of 4 people found the following review helpful:
4.0 out of 5 stars
A Book This Good Should Be Kept Up-To-Date,
By
This review is from: PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM) (Paperback)
What the other reviewers have said in consensus, I'll just stipulate: this book is a gentle but comprehensive introduction to core file analysis; it's also an excellent reference on kernel architecture. For its clarity of technical writing, it deserve some kind of award, considering how deathly-dull the subject matter can be. I couldn't stay awake through one pass of the assembly code illustrations, but I don't think the writers could have helped that. This book is a nonetheless a triumph, albeit a dated one.Now, c'mon, Prentice-Hall, help the audience out! This book was written in 1995. It uses Solaris 2.3 and sun4d architecture as its latest and greatest. Solaris (2.)8 has been out for a while and 9 is on the way; sparcv9/64-bit architecture is here; mdb, the modular debugger, is going to replace adb; the book *must* be updated. It would be a crime to let it die now -- there's still no competitive title on the market. The book is non-technical enough that I couldn't make all the changes needed to get the older examples to work. If I ever do, though, maybe I'll be good enough to write a competitive title myself... That said, even if the next edition were to out in three months, I'd still buy this one now to get started; it's that good.
Share your thoughts with other customers: Create your own review
|
|
Tags Customers Associate with This Product(What's this?)Click on a tag to find related items, discussions, and people.
|
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
Customer Discussions
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|
Listmania!
|
|
