From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13170 invoked by alias); 1 Nov 2012 19:26:38 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17373 Received: (qmail 25555 invoked from network); 1 Nov 2012 19:26:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at mac.com designates 17.158.236.240 as permitted sender) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-11-01_05:2012-11-01,2012-11-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1211010184 Subject: Re: Commands run from functions don't exit cleanly on terminal close (SIGHUP)? From: Alan Pinstein In-reply-to: <121028100739.ZM1724@torch.brasslantern.com> Date: Thu, 01 Nov 2012 14:26:13 -0400 Message-id: References: <2B813FB0-0877-42BA-974C-1A142EF09BCE@mac.com> <909858C7-4B5A-4679-90B3-6BF5398BA9FC@mac.com> <20121025112222.3dfbb213@pws-pc.ntlworld.com> <121025075455.ZM3417@torch.brasslantern.com> <121027110728.ZM8440@torch.brasslantern.com> <121028100739.ZM1724@torch.brasslantern.com> To: zsh-users@zsh.org X-Mailer: Apple Mail (2.1283) 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