11 Mar, 2009, Trepko wrote in the 1st comment:
Votes: 0
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?
11 Mar, 2009, Zeno wrote in the 2nd comment:
Votes: 0
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.
11 Mar, 2009, Trepko wrote in the 3rd comment:
Votes: 0
So if I have no memory leaks I could just do without the reboot (Big IF there)? Stick a hotboot in there instead? Or just totally do without?
11 Mar, 2009, Zeno wrote in the 4th comment:
Votes: 0
Do without.
11 Mar, 2009, Igabod wrote in the 5th comment:
Votes: 0
what does IIRC mean? I may not be old, but it's hard keeping up with all these new acronyms on the web.
11 Mar, 2009, Tyche wrote in the 6th 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.


It's a way of expressing a possible human memory leak. :-)
11 Mar, 2009, Igabod wrote in the 7th comment:
Votes: 0
ah, so If I Remember Correctly I'm guessing.
11 Mar, 2009, Sharmair wrote in the 8th comment:
Votes: 0
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.
11 Mar, 2009, KaVir wrote in the 9th comment:
Votes: 0
Sharmair said:
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.
11 Mar, 2009, Zeno wrote in the 10th comment:
Votes: 0
Quote
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).

Er, pretty sure that's incorrect.
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
etc
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.
11 Mar, 2009, Zeno wrote in the 12th comment:
Votes: 0
Which is why I said etc. :P
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...
http://www.smaugmuds.org/index.php?a=top...

Then there's the bugfix lists before FUSS.
Quote
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.
11 Mar, 2009, Guest wrote in the 16th comment:
Votes: 0
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.
11 Mar, 2009, Tyche wrote in the 17th comment:
Votes: 0
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.
11 Mar, 2009, Zeno wrote in the 18th comment:
Votes: 0
sexyboot.
11 Mar, 2009, Tyche wrote in the 19th comment:
Votes: 0


Testing the you tube linky thing, but with important on-topic info. ;-)
12 Mar, 2009, Igabod wrote in the 20th comment:
Votes: 0
is it bad that I found myself singing along to that?
0.0/23