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

[Alan Pinstein <apinstein@xxxxxxx>]

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