I remember seeing a snippet somewhere about changing the MUD automatic reboot to just do a MUD hotboot.(Talking about a modified SMAUG codebase just to clarify.) While I do understand that sometimes a reboot is necessary would implementing something like this be bad?
IIRC, Smaug's auto reboot was only because Smaug was riddled with memory leaks. My MUD no longer does auto reboots because it doesn't have any of those stock memory leaks.
Ok, I have a few things to say on this for what it's worth.
I don't really know why SMAUG put in an auto reboot. But at least as of 1.4a, there really are not any memory leaks that would likely cause problems for an extended MUD run (there are a few small stock memory leaks, but they are mostly in rarely used immortal and OLC commands). There are some comments mentioning fixed leaks, one in the player log on if I remember right, so maybe this was an issue in older SMAUGs though. I should also point out that a lot of other codebases are much worse then SMAUG as far as memory issues. I was always under the impression that the reboot came from how memory was used in the early bases that really needed to be cleaned up now and then.
In the SMAUG derivative I work in, there is a cset option to turn auto reboots on or off. The code has been run with no reboot for months without any problems, even before the memory leaks were fixed (the cset option was done very early in the development). You can in affect turn off auto reboots in stock by using the setboot command to set the reboot for a long time in the future (a year or so should cover most cases).
One other issue I wanted to make is your use of the terms reboot and hotboot. I know of only one MUD with a true hotboot (there might be more, but I know for sure about only one). In almost all the MUDs I have seen, hotboot (and a few other names) are used to mean what is called more accurately copyover. A copyover is really a full reboot with the connections just saved and restored. Also, other then two bases (The same SMAUG I have talked about before and empireMUD), all the hotboot, copyover etc code I have seen seems to be based on the same snippet. And that snippet really does not handle it the best, as it does a preemptive program bailout in the middle of a MUD update cycle. SMAUG actually has a nice synchronous reboot system stock. In the code I work with, there are six reboot modes, the first 3 are true softboots, 4 is basically a copyover and 6 is the stock shutdown reboot that needs the startup script to restart. They all use the reboot command and trigger synchronous reboots. The auto reboot (if it is on) uses the copyover type reboot, as does the stock syntax of 'reboot mud now'. I have always found it strange how so many add a new command for doing something there already is a command for.
One other issue I wanted to make is your use of the terms reboot and hotboot. I know of only one MUD with a true hotboot (there might be more, but I know for sure about only one). In almost all the MUDs I have seen, hotboot (and a few other names) are used to mean what is called more accurately copyover. A copyover is really a full reboot with the connections just saved and restored.
I've never heard the term "copyover" used outside of muds, and I'm not sure that the term "reboot" is entirely appropriate for a software application anyway. But as a close approximation, the exec() approach is pretty much the equivalent of a hot/warm reboot, while the regular reboot command is more like a cold reboot.
But at least as of 1.4a, there really are not any memory leaks that would likely cause problems for an extended MUD run (there are a few small stock memory leaks, but they are mostly in rarely used immortal and OLC commands).
11 Mar, 2009, David Haley wrote in the 11th comment:
Votes: 0
I looked at the links you gave, and they all fall under the category Sharmair was talking about. :wink: Memory leaks at boot won't be fixed by rebooting. And he did say that the leaks are in imm/OLC commands, e.g. delete_room.
Desc: A memory leak occurs when one prog sets off another prog of the same type (mob -> mob). The problem lies in the fact that the head of the singly linked list *_act_list is changed twice within the execution. The fix appends to the list rather than prepending. Luckily the list is small so appending isn't a loss, perhaps someone has a better idea?
Quote
Desc: Memory Leak (sort of) when new player created due to double alocation
etc
11 Mar, 2009, quixadhal wrote in the 13th comment:
Votes: 0
Disable any automated rebooting of your game and track its memory use over time. If you notice no slowdowns in performance, and memory use only grows with the amount of activity, then there's no reason to reboot – unless you have code which only runs at boot time to respawn quests/unique mobs/etc…
If you do notice memory use growing over time, run it inside valgrind for a few days and see if it turns anything up.
11 Mar, 2009, Hades_Kane wrote in the 14th comment:
Votes: 0
Igabod said:
what does IIRC mean? I may not be old, but it's hard keeping up with all these new acronyms on the web.
I remember people using that one about 6-7 years ago on my MUD…
11 Mar, 2009, David Haley wrote in the 15th comment:
Votes: 0
I found an occurrence of it in 1995 on Google's usenet archives. (groups.google.com, advanced search, play with the dates.) It was probably around before then.
I'd say if you're looking at the auto-reboot code and wondering "why" then it's probably time to drop it. Smaug was indeed a bug-ridden leak rittled mess back in the day. 1.4a didn't solve everything, and using the smaugmuds.org fix lists to find *ALL* of the leaks is silly since there were probably a bunch of those plugged before we even took on the project. There's no sane reason a MUD needs to restart itself every 24hrs these days. Especially a Smaug that's using SmaugFUSS as a base.
As far as hot vs cold restart, AFKMud, SmaugFUSS, and any other base using some form of my modified copyover code makes some effort to preserve more than just the descriptors. There is code in there to save current states of mobs that have already been reset and objects which are lying about on the ground outside of their normal locations. It may not be perfect but it's a far cry from the illusionary results of an unmodified copyover.
warmboot, hotboot, coldboot, softboot, hardboot, copyover, reboot, restart, auto reboot, synchronous reboot, true hotboot, true softboot, one true hotboot, fake boot, false boot, left boot, right boot it's just all so confusing.