lost signals

Xanatax has asked for the wisdom of the Perl Monks concerning the following question:

i have a server, which forks children to deal with connections, but when i send INT signals to the server the children do not always get them.

my server, which forks and deals with each incoming connection. when i send the server an INT (ie i hit ^C on the console) it is supposed to stop doing everything, but i found the children continue... i altered the parent's responce to a SIGINT to send all the children a SIGINT as well. to do this i set

    $SIG{INT} = 'IGNORE';
[download]

then send the INT back to the whole process group with

    kill -2, $$;
[download]

i don't know that this is the most elegant way, but after doing this i find that i send an INT to the server both it and it's children all do down.

this is what i want, except, if the child is in the middle of a command, it completely misses getting the signal. the command fails, and the child keeps on running. and will continue to respond to more commands.

i am guessing this has to do with the child being in a system() call when it gets the INT...

the next trick is, if i change the above code to

    local $SIG{INT} = 'IGNORE';
[download]

the children get teh signal no matter what, but the parent doesn't ignore it, gets it twice and seg faults...

so i would like input on remedies to this problem, or alternatives means of interrupting the server that do not have this problem...


                                   TIA,
                                      xanatax.
[download]

Comment on lost signals Select or Download Code

Replies are listed 'Best First'.
Re: lost signals by Malkavian (Friar) on Jul 20, 2001 at 17:25 UTC
How about having two different subs for handling interrupts, one being the default (handled by the server process), and one which redefines the sub when you fork to the child. The server process handler (to keep things short) sets a flag variable to indicate it should go into shutdown mode as soon as it can (next check point). At the check point, it enters a pre-die routine that sig INTs the children, then polls them at intervals (I've had SIGCHLDs disappear 'cos they happened while the server was already servicing a SIGCHLD) to see how they're doing. If they haven't been killed within a particular amount of time, perhaps try a nastier kill (SIGTERM), unless you really need to keep the return value at shutdown time. Retry as needed, until final time out, at which point you abort even trying to kill the thing, as it's gone beyond all reasonable point of recovery. That last bit shouldn't happen, but it's better to shut down as much as you can cleanly, than have the whole thing hang. I hope some of this helps... Cheers, Malk	[reply]
Re: lost signals by Xanatax (Scribe) on Jul 20, 2001 at 18:16 UTC
hrm, yeah, i quite like the idea of cleaning up the children, making sure they quit and all. and i think the while process will be easier to deal with if i have a list of active children, and use, instead of just directing signals at the whole process group... seems cleaner anyhow. i did manage to get the INT to work, as a force quit, but my QUIT sig doesn't yet... i think at least part of it can be cleared up by actually paying attention to the child procs... `Xan.` [download]	[reply] [d/l]
Re: lost signals by merlyn (Sage) on Jul 20, 2001 at 19:12 UTC
If there's a 1-in-20 chance that the signal would actually end up killing the kid instead of just nudging it, would you still be using it? No? Then don't use it. {grin} You should use some other form of IPC, one that doesn't have a chance of corrupting the kids. -- Randal L. Schwartz, Perl hacker	[reply]
Re: another form of IPC by Xanatax (Scribe) on Jul 21, 2001 at 13:16 UTC
well, for everything except the force quit polling a handle would work while the process is active... each time it finishes a command it checks if it has been asked to quit... problem is the child may spend a long time waiting... i've got the handle to the socket on NS, and i am processing commands in a `while( <NS> ){ ... }` [download] so if the user isn't sending anything the process waits until they do before it continues processing... that said, i think i have to use some means of interrupt, like a signal... if there are any alternatives, again, i'm open to suggestions, but all the perl documentation on IPC generally focuses on signals... `Xan.` [download]	[reply] [d/l] [select]