At 01:00 PM 12/18/98 -0800, you wrote:
>a soft reboot of the mud?
>
>so we can reboot without dropping players connections.
>
>this would be very handy.
>
>
>i have seen a semi functional patch out there. anybody got a better
>working one?
The copyover patch works well for this; that's probably the patch
you've seen. You're probably calling it semi-functional because it
does not necessarily work well "out of the box"... I know when I
implemented it, I had some debugging time to put in.
As it turns out, my mud does have something better installed in it
now, but I'm not prepared to make a patch. If I did, the patch would
be very large and include some proprietary code. I can, however
explain what I've done and perhaps someone else will become
interested in duplicating things.
In my mud, when I do a soft reboot, players do not notice anything.
The only way to tell the mud rebooted is to look at the log file. Players
are not even lagged during the reboot, and since I catch seg faults and
have them do a soft reboot as well, crashes are also mostly invisible
to players.
To accomplish this, I rely on shared memory, a feature that Linux and
most (all?) O/S's that provide POSIX compliance have. Shared memory
is a means of allocating memory that is persistant after the application
terminated; typically it's used to share data between applications.
To prepare my mud, I first created a structure type that had elements for
every global variable in the mud with the exception of those that do not
change. I then used this structure instead of the original globals.
Next, I obtained a (proprietary) malloc() function in source code. I'm
sure the freely available one that GCC uses would have worked just
as well, if not better. I modified this source to obtain the memory it
needs from a shared region instead of the system's normal free memory
pool. The very first malloc call creates the region. Now, all allocated
memory is placed in this shared area.
On a reboot, if a "soft reboot" flag is on the command line and I can get
to the shared area, I point my global structure to the appropriate location
inside it (malloc does this, as it keeps a pointer for it in a private
header in
the area) and then I'm off and running. No world load, no muss, no fuss.
Caveat: bugs can cause memory corruption in the shared area potentially,
which will cause seg fault after seg fault, etc. I keep a reboot counter in
the globals structure which is incremented when the mud starts; if the
counter is > 5, I perform an immediate hard reboot. After a minute of uptime,
I set the counter to 0. This way, crashes do not run away.
Hope this is interesting to someone.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST