Messages in this thread | | | Date | Thu, 15 May 1997 12:26:28 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: [rfc] posix.4 signals implementation |
| |
While people are discussing posix signals I'd just like to point out again that the 2.0 -> 2.0.1 changes for signal handling broke various binaries. For example, to get a working bash (I don't think any distributions do this) you have to -DBROKEN_WAITPID while building it. Here is an example where it fails:
cat >bad <<EOF #!/bin/sh ed $* EOF chmod +x bad ./bad bad
Now ^Z and fg that repeatedly. Eventually you'll hit a race condition causing bash to exit and leave ed lying around. If you don't like ed, replace it with vi (elvis or vim).
There was a related problem in mh from debian, but it has been fixed. I've heard that xterm may have a related problem, but can't verify it.
I can reproduce this no problem on various machines built from stock redhat-4.1, or slackware 3.1. So I really don't think it's something in my config.
So if you're going to change signals again it'd be nice if it's in 2.1 only.
Dean
On Thu, 15 May 1997, Olaf Kirch wrote:
> To: linux-kernel@vger.rutgers.edu > Subject: Re: [rfc] posix.4 signals implementation > X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] > > Richard Henderson wrote: > : There are known problems building nfs, lockd, autofs, etc because > : they muck with signals in nasty ways and it is not clear to me what > : is intended, especially in the presense of queued signals. My first > : reaction is why should they have to be mucking with SIGPIPE anyway? > > Because when e.g. a mount client dies and mountd attempts to write > to the socket, it receives a SIGPIPE. Both mountd and the user-space nfsd > both re-read the exports file on SIGHUP, and unfsd also needs SIGALRM > to clean up its file handle cache occasionally. What is it exactly > that gives you headaches? > > Olaf > -- > Olaf Kirch | XmToggleButton resource set; class Set; values set/unset > okir@monad.swb.de | Motif for Quiche Eaters >
| |