As normal, shell companies are living by the existence of eggdrops. In the past, I had a shell provider that was mass killing the processes before rebooting (bot quits with reason: Remote closed the connection). My new provider just reboots and my bots eventually ping timeout. Too bad, if they only could throw a command so my bot could save userfile before dying...
On this thought, I was reffering to "die on SIGHUP" and "die on SIGTERM". I ain't good in unix commands, I have no idea what both of these commands means, but I would like to know if any one of them should be turned to 1 or 0 for commercial shells, to ease things up on the admin, while keeping it safe.
I have thought of the idea on a command where admins could throw a command so the bots on the shell could quit IRC with reason "shell reboot" or something similar, but this would mean a security problem too... ah well.
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
admins rebooting machine
as default, all versions of unix send SIGHUP to every process on the system as part as their shutdown routine. its a unix convention for processes to save their state, or shutdown gracefully on receiving a SIGHUP. eggdrop does do this (defaultly it rehashes on a hup, which saves the user/chan files, or it can be set to shutdown, which also saves the chan/user files).
If your bot is not saving properly when the shell reboots, there are 2 reasons for this. Firstly, there is not enough time between the system sending the SIGHUP and actually terminating the process forcefully (ie SIGKILL) for it to save its userfile (this could be also caused by having a lot of processes all trying to save out at the same time, and lagging the hard drives enough that your processes never complete the save before they're killed). If this is the case, get the admin to increase the hup wait time on controlled shutdowns.
The other reason is that the machine is not going through a graceful shutdown (ie, its being turned of instantly from the power switch, or its just sending SIGKILLs with no hups before). There is nothing eggdrop can do in this situation (because its instantly terminal - the process is no longer running to do anything like saving the instant they happen). All you can do about that is ask your shell admin not to do it
If your bot is not saving properly when the shell reboots, there are 2 reasons for this. Firstly, there is not enough time between the system sending the SIGHUP and actually terminating the process forcefully (ie SIGKILL) for it to save its userfile (this could be also caused by having a lot of processes all trying to save out at the same time, and lagging the hard drives enough that your processes never complete the save before they're killed). If this is the case, get the admin to increase the hup wait time on controlled shutdowns.
The other reason is that the machine is not going through a graceful shutdown (ie, its being turned of instantly from the power switch, or its just sending SIGKILLs with no hups before). There is nothing eggdrop can do in this situation (because its instantly terminal - the process is no longer running to do anything like saving the instant they happen). All you can do about that is ask your shell admin not to do it
that should be SIGTERM...On 2002-03-13 05:14, Petersen wrote:
as default, all versions of unix send SIGHUP to every process on the system as part as their shutdown routine.
But indeed, when an eggdrop receives either a SIGHUP or a SIGTERM, it will save its userfile immediately, regardless of the die-on-sighup and die-on-sigterm settings. On the other hand, when a process is killed with SIGKILL, all of its file descriptors are closed, causing its TCP connections to abort (resulting in the EOF from client / Remote closed the connection, that you mentioned).
As neither of these events seem to occur in your situation, then either the network connection of the shellserver is suffering from severe packet loss, or the admin is abusing the power switch... either of which is a good reason to find another shell provider
As Petersen said, there's not much you can do except talking to the admin...maybe you'll want to force the eggdrop to save its userfile a bit more often (but I wouldn't know the best way to do that - maybe by modifying botchk to send a SIGHUP to alive eggdrops?).
Btw, on "normal" shells, you could bind a proc to the "sigterm" TCL event and terminate the IRC connection with a quit text like "shell reboot" (instead of the standard "Remote closed the connection")...but of course you shouldn't kill the bot with a SIGTERM yourself anymore, then.
<font size=-1>[ This Message was edited by: RedAlert on 2002-03-14 09:55 ]</font>