Many modern codebases are set up so if the MUD crashes, it will automatically reboot without an admin having to go into the shell.  However, the same is not true of infinite loops.  When these crop up, you're sh!t out of luck until a very high admin comes along and kills it in the shell.  But there is a possible alternative.
The basic strategy is to have numerous instances of the MUD running simultaneously;  however, all except the main instance are lying low and waiting for a cue before even going into the basic bootup routine (and thus they take no significant RAM).
Meanwhile, the main mud is set up slightly differently than usual with regard to socket handling.  Rather than the master socket being told to listen once, and left there until the MUD shuts down, the master is periodically told to listen, wait briefly, accept ALL connections (which would require some looping and multiple pollings) (actually you'd want to limit the number of connections, if more than 50 connections are pending in a single instant it's probably someone trying to crash you), then after putting those connections on a different port, the master socket is unbound and turned off, to await the next polling.
Now, the other instances which have not yet been fully activated all connect to the main mud on a separate port (since it's all on the same computer you could use a firewall to prevent players from getting to that port), and merely occasionally "ping" the main mud to make sure it's still up.  As long as this is the case, all goes smoothly.  (If the connection goes down, it means the main mud merely crashed, as opposed to infinite looping.. in this case the main mud should be coming back up anyway shortly so just try to reestablish communications)
But when the main mud goes into an infinite loop, it stops responding to the lesser mud instances.  After a given period of time, the next mud instance realizes the main one is stuck, and so it sends out signals to all the others, letting them know that now IT is the main mud, and proceeds to boot itself up and begin listening for connections to the playport.  It also sends a signal to the suspiciously unresponsive instance notifying it that it is no longer in charge- so that in the rare event it's not a real infinite loop but just some massive (multiple minute long) lag, when the lag finally stops the old main mud will quietly shut itself down and let the new main mud continue being in charge.
There are, of course, alot of issues to work out, and I myself (being employed full time AND in college full time) have no time for coding myself these days.  Thus this is all untested, it was merely an idea that came to me the other day.  Once a true coder, you will thenceforth never cease to periodically recieve coding inspirations, long after retiring.