View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000274||LDMud 3.5||Implementation||public||2004-11-27 00:26||2011-02-13 22:38|
|Target Version||3.5.0||Fixed in Version||3.5.0|
|Summary||0000274: Reaction to signals|
|Description||Short: Signal handling|
Date: Fri, 21 Dec 2001 16:16:21 -0700
From: Daniel Podlejski <email@example.com>
> Lars Duening wrote:
> : > : Neat idea! But I'll modify it a bit: the signal handler will reset
> : > : the SIGTERM to the default behaviour, so if the driver is really
> : > : wedged, the second SIGTERM will just abort the program.
> : >
> : > Fine.
> : > But on most unices durning halt/reboot scripts send SIGTERM and after
> : > few secounds - SIGKILL.
> : *nod* I mean that more for more convenient commandline use than
> : anything else.
> Right. So you also should add SIGINT handling, similar to your SIGTERM
Currently, the shutdown handling is defined for SIGHUP.
Look up the meanings of SIGINT, SIGQUIT and SIGTERM and add
appropriate handlers. Maybe SIGINT should still break immediately.
Date: Mon, 17 Dec 2001 13:14:58 -0700
Lars Duening wrote:
: > : Neat idea! But I'll modify it a bit: the signal handler will
: > : the SIGTERM to the default behaviour, so if the driver is
: > : wedged, the second SIGTERM will just abort the program.
: > Fine.
: > But on most unices durning halt/reboot scripts send SIGTERM and
: > few secounds - SIGKILL.
: *nod* I mean that more for more convenient commandline use than
: anything else.
Right. So you also should add SIGINT handling, similar to your
Daniel Podlejski <firstname.lastname@example.org>
... Promised myself I wouldn't weep
One more promise I couldn't keep ...
------- End of forwarded message -------
|Tags||No tags attached.|
||I will second this ... On my home machine I use SIGINT quite a lot and it would be nice if the mudlib could respond to it.|
||Ah, what was the idea, or let me rephrase: What should the driver do upon receiving SIGINT?|
||Call a driver hook?|
Im anyway working on the signal handling right now, so I will take this one.
SIGKILL can't be handled/caught. On SIGTERM I would argue to handle it just like SIGHUP (controlled shutdown), because in most cases there will be a SIGKILL a few seconds later.
We should make a list which other signals we would like to receive in the mudlib.
Concerning SIGHUP, SIGUSR2 and SIGUSR2 we might call the driver hook and fall back to our current behaviour if it returns 0 or is not defined.
I reworked the signal handling between r2872 - r2882 (3.5) and included this.
SIGHUP, SIGINT, SIGUSR1 and SIGUSR2 are now deferred to the mudlib master. If it handles them (by returning !=0 in handle_external_signal()), the driver takes not further action, otherwise falls back to the current reaction.
SIGTERM is deferred to the mudlib, but can't be handled. After handle_external_signal() returns, the driver begins with a graceful shutdown.
||Ok, improved the handling of SIGTERM+SIGINT in r2922 a bit. I consider this then resolved if noone objects.|
|2009-11-20 06:38||_xtian_||Note Added: 0001637|
|2009-12-22 11:13||zesstra||Note Added: 0001667|
|2009-12-22 11:27||Gnomi||Note Added: 0001668|
|2010-02-17 19:18||zesstra||Note Added: 0001741|
|2010-02-17 19:18||zesstra||Assigned To||=> zesstra|
|2010-02-17 19:18||zesstra||Status||new => assigned|
|2010-02-19 16:42||zesstra||Note Added: 0001742|
|2010-07-13 17:05||zesstra||Project||LDMud => LDMud 3.5|
|2010-07-13 17:06||zesstra||Note Added: 0001874|
|2010-07-13 17:06||zesstra||Status||assigned => resolved|
|2010-07-13 17:06||zesstra||Fixed in Version||=> 3.5.0|
|2010-07-13 17:06||zesstra||Resolution||open => fixed|
|2011-02-13 22:38||zesstra||Target Version||=> 3.5.0|