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: Thu, 01 Nov 2012 14:26:13 -0400 [thread overview]
Message-ID: <BA515C96-1260-4699-A58E-A2FC42884572@mac.com> (raw)
In-Reply-To: <121028100739.ZM1724@torch.brasslantern.com>
Ok, I just went through all of this and reproduced the experiment on zsh 4.3.11 and 5.0.0 (Macports). I got the same results with both shell versions.
# start 2 ssh sessions in zsh 5.0.0 from macports, one from ZLE/CLI and one via a function...
TIME PID PGID PPID COMMAND
0:00.02 12084 12084 10729 /usr/bin/ssh imac -t screen -xRS MainScreen && echo FROM FUNCTION
0:00.02 12131 12131 10903 /usr/bin/ssh imac -t screen -xRS MainScreen
To show you the process stack via pstree:
# from function
-+= 00001 root /sbin/launchd
\-+= 00214 apinstein /sbin/launchd
\-+= 00229 apinstein /Applications/iTerm.app/Contents/MacOS/iTerm -psn_0_24582
\-+= 10659 root login -fp apinstein
\-+= 10660 apinstein -zsh
\-+= 10729 apinstein zsh
\--= 12084 apinstein /usr/bin/ssh imac -t screen -xRS MainScreen && echo FROM FUNCTION
# ZLE
-+= 00001 root /sbin/launchd
\-+= 00214 apinstein /sbin/launchd
\-+= 00229 apinstein /Applications/iTerm.app/Contents/MacOS/iTerm -psn_0_24582
\-+= 10820 root login -fp apinstein
\-+= 10821 apinstein -zsh
\-+= 10903 apinstein zsh
\--= 12131 apinstein /usr/bin/ssh imac -t screen -xRS MainScreen
Now, go "close" both terminals... and re-run PS:
TIME PID PGID PPID COMMAND
0:00.02 12084 12084 1 /usr/bin/ssh imac -t screen -xRS MainScreen && echo FROM FUNCTION
So, as far as I can tell, both processes look *identical* in terms of their process group IDs, parents, etc, and only act different when closed.
I would think according to your notes about how the OS/Process Groups work, that the HUP signal would get sent to both setups the exact same way, no?
Anything else I should be looking at?
Alan
On Oct 28, 2012, at 1:07 PM, Bart Schaefer wrote:
> On Oct 27, 9:33pm, Alan Pinstein wrote:
> }
> } Oh, duh yes I was HUP'ing the php process. Well of course that's what
> } would happen...
>
> You didn't answer the question about which zsh version is involved.
>
> } 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.
>
> I think you're missing the point I've been trying to make. Regardless
> of whether the child is started from a function or not, closing the
> terminal sends a HUP signal only to the foreground job. This is what
> is supposed to happen:
>
> When zsh starts a job in the foreground, it makes that job the process
> group leader for the terminal. After that, until zsh itself exits, the
> signals are all generated by the OS / terminal driver.
>
> If you are at the ZLE prompt, then zsh is the foreground job. It gets
> the signal and/or EOF from the terminal, and (assuming NO_HUP is not
> set) it explicitly sends HUP to all background children.
>
> If you are not at the ZLE prompt -- e.g., your PHP program is running --
> then the terminal wil HUP the PHP program, but will not HUP zsh. *After*
> that, it's possible that the behavior is different depending on whether
> a function is involved, but it should be the case that only the "process
> group leader" of the foreground process gets HUP'd. This is an operating
> system thing, not a zsh thing.
>
> If the foreground job exits, then zsh will wake up and at some point
> attempt to read from the terminal. At that point it will get EOF, and
> therefore (once again depending on NO_HUP) send HUP to all of its
> background children. In the case of your willnotdie function, the main
> zsh loop is not re-entered until the function finishes, so zsh won't
> see an EOF right away.
>
> Now, I say that's what's supposed to happen, because there do seem to
> be some cases on MacOS where it doesn't work that way. In particular
> with the stock 4.3.11 I see everything exit with no output from traps
> ever written to the file; but with 5.0 compiled under macports, I get
> output from the HUP trap.
>
> } So I just re-did the test with a custom PHP script that logs signals
> } (except for KILL and STOP, it can't).
> }
> } [...]
>
> I can't test this because on my Mountain Lion iMac I get:
>
> Fatal error: Call to undefined function pcntl_signal() in /private/tmp/trap.php
> on line 5
>
> which is very strange because php -v says
>
> PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)
>
> } 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?
>
> No, zsh won't do that. It never sends KILL or STOP. Note, though, that
> this is similar to the behavior of "willnotdie" that I observed on MacOS
> with the stock 4.3.11. Repeat my version question.
>
> } 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
>
> Note here that PHP still did not log a HUP signal, so it appears that
> there is not a HUP being sent.
>
> } *and* the PPID of the php process is 1 after the window closes...
>
> Which means that zsh has already exited -- so either something external
> is killing it (repeat my question about whether you're running ssh in a
> terminal, or running a terminal in ssh), or the wait()-family system
> call that zsh makes [to go dormant while PHP is in the foreground] has
> returned so zsh was fooled into believing PHP had also exited.
>
> Neither of these *ought* to happen.
>
> --
> Barton E. Schaefer
next prev parent reply other threads:[~2012-11-01 19:26 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
2012-10-28 17:07 ` Bart Schaefer
2012-11-01 18:26 ` Alan Pinstein [this message]
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=BA515C96-1260-4699-A58E-A2FC42884572@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).