On Fri, Nov 17, 2006 at 09:39:39PM -0500, Gregory Stark wrote:
> "Stephen Harris" <lists@xxxxxxxxxx> writes:
> > [...variable setup...]
> > while [ ! -f $wanted_file ]
> > do
> > if [ -f $abort_file ]
> > then
> > exit 1
> > fi
> > sleep 5
> > done
> > cat $wanted_file
> > I know signals can be deferred in scripts (a signal sent to the script during
> Sure, but it might be getting delivered to, say, your "sleep" command. You
No. The sleep command keeps on running. I could see that using "ps".
To the best of my knowldge, a random child process of the script wouldn't
even get a signal. All the postmaster recovery thread knows about is the
system() - ie "sh -c". All sh knows about is the ksh process. Neither
postmaster or sh know about "sleep" and so "sleep" wouldn't receive the
signal (unless it was sent to all processes in the process group).
Here's an example from Solaris 10 demonstrating lack of signal propogation.
$ uname -sr
SunOS 5.10
$ echo $0
/bin/sh
$ cat x
#!/bin/ksh -p
sleep 10000
$ ./x &
4622
$ kill 4622
$
4622 Terminated
$ ps -ef | grep sleep
sweh 4624 4602 0 22:13:13 pts/1 0:00 grep sleep
sweh 4623 1 0 22:13:04 pts/1 0:00 sleep 10000
This is, in fact, what proper "job control" shells do. Doing the same
test with ksh as the command shell will kill the sleep :-)
$ echo $0
-ksh
$ ./x &
[1] 4632
$ kill %1
[1] + Terminated ./x &
$ ps -ef | grep sleep
sweh 4635 4582 0 22:15:17 pts/1 0:00 grep sleep
[ Aside: The only way I've been able to guarantee all processes and child
processes and everything to be killed is to run a subprocess with
setsid() to create a new process group and kill the whole process group.
It's a pain ]
If postmaster was sending a signal to the system() process then "sh -c"
might not signal the ksh script, anyway. The ksh script might terminate,
or it might defer until sleep had finished. Only if postmaster had
signalled a complete process group would sleep ever see the signal.
--
rgds
Stephen
