zsh-users
 help / color / mirror / code / Atom feed
From: Alan Pinstein <apinstein@mac.com>
To: zsh-users@zsh.org
Subject: Re: Commands run from functions don't exit cleanly on terminal close (SIGHUP)?
Date: Sat, 27 Oct 2012 21:33:06 -0400	[thread overview]
Message-ID: <BB31FBBB-48DF-4DE7-B043-8589041C1B88@mac.com> (raw)
In-Reply-To: <121027110728.ZM8440@torch.brasslantern.com>

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.


  reply	other threads:[~2012-10-28  1:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2B813FB0-0877-42BA-974C-1A142EF09BCE@mac.com>
     [not found] ` <909858C7-4B5A-4679-90B3-6BF5398BA9FC@mac.com>
     [not found]   ` <20121025112222.3dfbb213@pws-pc.ntlworld.com>
     [not found]     ` <D1AA5CA1-BB91-45D4-90D7-1596FF81F6AE@me.com>
     [not found]       ` <C6890E9F-F729-40FA-9305-055E9F165391@mac.com>
     [not found]         ` <121025075455.ZM3417@torch.brasslantern.com>
     [not found]           ` <E8AA19A7-2E79-48A4-BB2F-6F3CCF769EBC@mac.com>
2012-10-27 18:07             ` Bart Schaefer
2012-10-28  1:33               ` Alan Pinstein [this message]
2012-10-28 17:07                 ` Bart Schaefer
2012-11-01 18:26                   ` Alan Pinstein
2012-11-02  7:18                     ` Bart Schaefer
2012-11-05 19:05                       ` Alan Pinstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BB31FBBB-48DF-4DE7-B043-8589041C1B88@mac.com \
    --to=apinstein@mac.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).