Re: PATCH: (2) Re: FreeBSD compatability feature request

[Vincent Stemen <zsh@xxxxxxxxxxx>]

On Wed, Apr 21, 2004 at 12:05:00PM +0100, Peter Stephenson wrote:
> OK, plan B.
> 
> I am now frightened about what happens when any signals are blocked
> while we are waiting for a child.  So instead of doing that, I propose
> queuing traps separately from signals.  This can't cause any races,
> since no extra signal or process handling is involved.  The code is a
> bit more verbose, but should be much safer.  This patches on top of the
> other one.
> 
> Again, this should be exactly equivalent to 4.2.0 unless TRAPS_ASYNC is
> unset (POSIX compatibility mode).
> 
> This ought to fix the hang.

Hi Peter.

I applied the patch.  It definitely fixed the hanging problem.  I can
now plug it in place of /bin/sh on FreeBSD and all the init scripts
seem to run properly without errors when booting the system.

However, I actually tested the signal handling this time and, unless I
am not understanding the trapsasync mode enough to test properly, I
don't think it is working.  If I understand it correctly, with "set -T"
shouldn't the parent process immediately get any signals it has trapped
even if a child process it is waiting on has disabled the signals?

With that in mind, I tested it with two scripts, sigtrap and sigblock.

quark # cat sigtrap

echo "sigtrap: trapping SIGINT and calling sigblock"
set -T
trap 'echo Got signal. Exiting.; exit' 2
./sigblock
echo "sigtrap: Exiting normally"


quark # cat sigblock

echo "sigblock: blocking SIGINT and sleeping"
trap '' 2
sleep 5


quark # ./sh sigtrap
sigtrap: trapping SIGINT and calling sigblock
sigblock: blocking SIGINT and sleeping
^C^Csigblock: exiting
Got signal. Exiting.
quark #


After hitting <cntl>c, it completed the 5 second delay before printing
"sigblock: exiting".  It behaved the same whether I had the "set -T" in
the script or not.  I was expecting sigtrap to immediately print "Got
signal. Exiting." when I hit <cntl>c with trapsasync set.

Be aware if you test this under Linux that Linux, at least as of the
2.4.x kernels about a year ago the last time I tested it, does not pass
signals on to the parent process like FreeBSD does.  So you may not see
the "Got signal" message from the parent sigtrap process.  In the past,
I always had to check for a 130 return code from every child process
(which was a pain) to know if the user hit <cntl>c so I can call my
signal handling routine.  I was not able to have dependable signal traps
in my scripts because you could not always depend on the child returning
130 when it got interrupted.

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
Read how Network Solutions (NSI) was involved in stealing our domain name.
http://www.InetAddresses.net