Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Commands run from functions don't exit cleanly on terminal close (SIGHUP)?



Oh, duh yes I was HUP'ing the php process. Well of course that's what would happen...

In any case I think that's kind of a digression; the simple truth is still that when the shell gets the SIGHUP from the Terminal program, it isn't propagating that to its children *if* the children are started in a function.

So I just re-did the test with a custom PHP script that logs signals (except for KILL and STOP, it can't).

> <?php
> 
> declare(ticks = 1);
> foreach (range(1,16) as $signo) {
>     $ok = pcntl_signal($signo, 'sighupH', false);
>     if (!$ok)
>         print "ERR INSTALLING TRAP $signo\n";
> }
> function sighupH($signo)
> {
>     echo "PHP TRAPPED: {$signo}\n";
> 
>     `(date && echo "PHP TRAPPED {$signo}") >> sig`; 
> 
>     if ($signo === SIGINT) exit(128+SIGINT);
> }
> 
> $pid = getmypid();
> print `echo PHP START $pid`;
> print `(date && echo PHP START) > sig`;
> $i = time() + 10;
> while (true) { if (time() > $i) break; }
> print `(date && echo "PHP DONE") >> sig`;

When run directly (php trap.php) and closing the terminal window, cat sig yields:

> Sat Oct 27 21:20:41 EDT 2012
> PHP START

So it looks like zsh sends KILL or STOP to all processes when ZSH itself gets the HUP from the Terminal?

And when run in a zsh function:

> function p() { php trap.php }

cat sig yields:

Sat Oct 27 21:20:03 EDT 2012
PHP START
Sat Oct 27 21:20:14 EDT 2012
PHP DONE

*and* the PPID of the php process is 1 after the window closes...

So, still I have the same problem. It seems that processes started from PHP functions don't receive the same signal as one started from the CLI when the Terminal closes a window...

Is it possible this isn't a ZSH bug in propagating signals? Clearly ZSH is getting the HUP from the terminal because it exists, but it seems that no HUP/INT/KILL is sent to all of zsh's children. So if ZSH doens't send HUP/INT/KILL to its children when zsh is killed, is it possible that maybe the Terminal somehow knows which shell process is foreground and only sends the HUP/INT/KILL to that process? And it just gets confused when there is a zsh function running?

Does anyone know how the terminal and shell coordinate to kill children on window exit?

Alan

On Oct 27, 2012, at 2:07 PM, Bart Schaefer wrote:

> (Alan, your previous message went only to me, not to zsh-users.  I'm using
> the list for this response.)
> 
> On Oct 25, 11:10pm, Alan Pinstein wrote:
> }
> } # on CentOS
> } Interestingly if I "kill -HUP <pid>" while it's running, I get this output:
> } 
> } Thu Oct 25 22:09:26 CDT 2012
> } START
> } Thu Oct 25 22:09:34 CDT 2012
> } DONE
> } 
> } It doesn't log the HUP for some reason.
> 
> Which PID are you hupping?  The php job, or zsh?  On MacOS, I get the above
> if I HUP php.  If I HUP zsh, I get
> 
> Sat Oct 27 10:47:42 PDT 2012
> START
> Sat Oct 27 10:47:46 PDT 2012
> HUP
> Sat Oct 27 10:47:54 PDT 2012
> DONE
> 
> which is what I'd expect because zsh won't pass the trapped HUP along to
> it's child processes.  If zsh actually exited, it would HUP the children
> (assuming NO_HUP is not set), but it did not exit, because of the trap.
> 
> In the case of the window closing, php should get the HUP, because it is
> the foreground job.
> 
> Here's a question we haven't asked yet:  What version of zsh are you
> trying this with, in each case (MacOS/CentOS)?  I've been testing 5.0,
> but if I try closing ssh with ~. when using 4.3.11 as shipped with
> Mountain Lion, I get entirely different behavior; neither HUP nor DONE
> is written to the file, only START -- but both php and zsh have exited.



Messages sorted by: Reverse Date, Date, Thread, Author