Shutdowns and dumps

Submitted by javelin on Thu, 2004-03-18 13:33

What's a dump?

A database dump is the process of making a copy of the MUSH's database (which is mostly in memory when the MUSH is running) on the machine's disk. This is absolutely necessary when the MUSH is shut down, so that it can be restarted in the same state it was in when it was shut down. In addition, "checkpoint dumps" are performed by the MUSH at regular intervals (e.g. every hour, every 3 hours, every day, or however you configure it in mush.cnf). If the MUSH should crash, it can be restarted from a checkpoint dump, and data loss will be restricted to changes made in the last interval. Finally, a dump can be performed by a wizard using the @dump command.

What's a forking dump?

In mush.cnf, you can decide if your MUSH should fork when it dumps. "Forking" means that the MUSH makes an identical copy of itself in memory, and that copy runs the dump and then exits, while the original copy continues doing MUSH things. This means that players won't even notice when your MUSH dumps, which is nice. Forking doesn't work on Win32.

There's a downside, however. When the MUSH forks, there are basically two MUSH processes running. That means durnig the dump, your MUSH is using twice the CPU (roughly) and twice the memory that it normally would. If your machine is low on memory, this can cause the MUSH to swap, and lag everyone badly.

The alternative is to dump without forking. While the MUSH is dumping, it can do nothing else in this case, so the game will pause until the dump is complete. It gives the players a message to let them know that there will be a pause.

What happens on a shutdown dump?

A shutdown dump is just like any other dump, but it occurs at shutdown. :)

What's a paranoid dump?

A paranoid dump is performed by a Wizard typing @dump/paranoid. A paranoid dump differs from a normal dump in that it automatically corrects certain kinds of database corruption, writing out a non-corrupt database to disk. This is often useful when your database is corrupted in such a way that normal dumps crash (if you're forking, a dump crash only crashes the dump process). You can @dump/paranoid, kill -9 the MUSH process (DON'T @shutdown, which will overwrite the paranoid dump with a corrupt one), and then restart from the paranoid dump.

What exactly does a paranoid dump try to fix?

  • Bad attribute names: Unprintable characters or spaces in names of attributes will be replaced with a '!' character.
  • Bad attribute owners: If the attribute is owned by an invalid db#, its owner will be set to God.
  • Bad attribute text: If the attribute's text contains unprintable characters or hard newlines (\r's and \n's), they will be replaced with '!' characters. The fixing of hard newlines used to be important, but is actually now more of a hassle since MUSH can now deal with \r\n's in dbs.

What's a debug dump?

A debug dump is performed by a Wizard typing @dump/debug. It's a paranoid dump that also tries to repair some of the problems it finds on the in-memory (running) copy of the database, as well as writing out a clean database. It only corrects bad attribute owners (but these are the most common corruptions that cause crashing on dump).

What's a panic dump?

A panic dump occurs when the MUSH process is terminated with a signal 15 (SIGTERM) (there may one day be a @dump/panic command as well). This is a pretty unusual thing, but if someone accidentally kills your MUSH process somehow, it'll attempt to save a copy of the database, together with the mail and chat databases (if any) before it dies. The copy will be stored in game/data/PANIC.db, will be uncompressed, and will contain all of the dumped databases in one file. You can tell if the dump was successful by examining the last line of that file. If it's ***END OF DUMP***, it was successful. The restart script knows about panic dumps, and will try to restart from a panic dump if it can find a successful one.