Go to the first, previous, next, last section, table of contents.


Crash Diagnosis

Your first action after a crash will usually be to run your adrenalin level up and say a few choice words. If you act quickly while still in this phase, you can usually manage to make things much, much worse! It is often a good idea to start by taking a deep breath, getting a cup of coffee, and perhaps grabbing a friend for moral support.

After that, your next action should be to make a reasonable diagnosis of the reason for the crash. Restarting the server without doing this is very likely to just make a bad situation worse, by further corrupting the database and perhaps erasing some of your few remaining good backups (if you keep a shallow sequence of backups).

Two good checks to start with:

If you have the diskspace to spare, a good next step is to make a complete tar archive of the entire db directory. This will preserve almost all the relevant information, which may help with diagnosis later, and may also save your bacon if you screw up and wreck the db directory while attempting recovery.

If Muq crashed and you did not get a corefile, you may have them turned off: Do "limit". If it says "coredumpsize 0", you're cheating yourself of good diagnostic information. You may want to do "limit coredumpsize unlimited" before future runs.

If you got a corefile, do

script stackdump
gdb ../bin/muq ./core
bt
(You may need to hit <return> a few times here.)
quit
exit

and save the resulting 'stackdump' listing: Even if it doesn't mean anything to you, you can email it to me (via bugs@muq.org) if the problem eludes diagnosis, and perhaps I will be able to make something of it. (At the least, I may be able to tell you whether other people are reporting similar problems.) If you can afford the space, saving the 'core' file in a directory where it won't be overwritten by new coredumps can be a good idea.


Go to the first, previous, next, last section, table of contents.