Re: [rfc] posix.4 signals implementation

Dean Gaudet (dgaudet-list-linux-kernel@arctic.org)
Thu, 15 May 1997 12:26:28 -0700 (PDT)

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
>