From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7026 invoked from network); 22 Apr 2004 09:00:06 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 22 Apr 2004 09:00:06 -0000 Received: (qmail 7189 invoked by alias); 22 Apr 2004 08:59:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19813 Received: (qmail 7164 invoked from network); 22 Apr 2004 08:59:57 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 22 Apr 2004 08:59:57 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [130.225.247.86] by sunsite.dk (MessageWall 1.0.8) with SMTP; 22 Apr 2004 8:59:57 -0000 Received: (qmail 9818 invoked from network); 22 Apr 2004 08:59:57 -0000 Received: from lakermmtao05.cox.net (68.230.240.34) by a.mx.sunsite.dk with SMTP; 22 Apr 2004 08:59:54 -0000 Received: from quark.hightek.org ([68.12.75.33]) by lakermmtao05.cox.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040422085925.MSWG18641.lakermmtao05.cox.net@quark.hightek.org> for ; Thu, 22 Apr 2004 04:59:25 -0400 Received: by quark.hightek.org (Postfix, from userid 501) id 736FD12408; Thu, 22 Apr 2004 03:59:56 -0500 (CDT) Date: Thu, 22 Apr 2004 03:59:56 -0500 From: Vincent Stemen To: Zsh hackers list Subject: Re: PATCH: (2) Re: FreeBSD compatability feature request Message-ID: <20040422085956.GA69814@quark.hightek.org> References: <20040421082151.GA61057@quark.hightek.org> <18144.1082545500@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18144.1082545500@csr.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: * X-Spam-Status: No, hits=1.5 required=6.0 tests=RCVD_IN_SORBS autolearn=no version=2.63 X-Spam-Hits: 1.5 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 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 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 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