While having some issues with "re-"binding sockets when restarting Simutrans (Posix via shell script, see more: http://forum.simutrans.com/index.php?topic=13911.0 (http://forum.simutrans.com/index.php?topic=13911.0)) I found out that the POSIX backend of Simutrans doesn't handle SIGTERM. The attached patch adds support for a graceful shutdown of POSIX version.
The patch consists of...
#ifndef _WIN32
void posix_sigterm(int signum)
{
dbg->important("Received SIGTERM, exiting...");
sigterm_received = 1;
}
#endif
int main(int argc, char **argv)
{
#ifndef _WIN32
// Setup a handler for SIGTERM:
struct sigaction action;
memset(&action, 0, sizeof(struct sigaction));
action.sa_handler = posix_sigterm;
sigaction(SIGTERM, &action, NULL);
#endif
gettimeofday(&first,NULL);
return sysmain(argc, argv);
}
... which will setup the handler, which will just set the static volatile int sigterm_received...
void GetEvents() // and: void GetEventsNoWait()
{
if (sigterm_received) {
sys_event.type = SIM_SYSTEM;
sys_event.code = SYSTEM_QUIT;
}
}
... and GetEvents() will return the SYSTEM_QUIT event once static volatile int sigterm_received is set.
I will have to check windows, because there is already some handling of quit. But in principle why not. (The error you want to fix is an OS error though.)
Quote from: prissi on September 01, 2014, 02:53:53 PM
I will have to check windows, because there is already some handling of quit.
That must be well hidden, because I can't find it. simsys_w.cc appears to be GUI or GUI+console, not console only like simsys_posix.cc. simsys_posix.cc doesn't generate any kind of event.
Ah, my fault. Yes indeed. I think SDL has also a handler, so it makes much sense to have one in Posix too.
Quote from: prissi on September 03, 2014, 10:44:29 AM
Ah, my fault. Yes indeed. I think SDL has also a handler, so it makes much sense to have one in Posix too.
Yes it does. That's were I've looked for on how to implement a graceful shutdown.
Quote from: prissi on September 01, 2014, 02:53:53 PM
The error you want to fix is an OS error though.
Don't think so, since it occurs on every OS (Windows, Debian and Mac OS X tested) and yes, this patch doesn't fix it. But I still think it would be a good idea to add this code.
Quote from: Michael 'Cruzer' on September 12, 2014, 01:59:14 PM
[...] yes, this patch doesn't fix it. But I still think it would be a good idea to add this code.
Yes. This is about adding support for the typical POSIX(?) way of shutting down a server process, or console processes in general.
INcorporated. One could also modify the server to save this game state before under a recovery-portner.sve so it can be recovered under loading.
That would be a really helpful feature for server administrators.
OK, setting server_save_game_on_quit=1 in simuconf.tab in the next nightly will create a file network13353-restore.sve upon exit. Renaming this to network13353-network.sve will load then latest state it upon reload.
Quote from: prissi on September 15, 2014, 09:49:34 PM
OK, setting server_save_game_on_quit=1 in simuconf.tab in the next nightly will create a file network13353-restore.sve upon exit. Renaming this to network13353-network.sve will load then latest state it upon reload.
Is there any reason why it is not stored to server13353-network.sve immediately? Wouldn't this be much easier for the users? There is already an optional setting "server_save_game_on_quit", why asking the user for an additional optional action?
Because if this saving is due to a crashed game, you could recover the last game when somebody joined too.