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

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

[Bart Schaefer]

(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.

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

[Alan Pinstein]

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.

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

[Bart Schaefer]

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

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

[Alan Pinstein]

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

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

[Bart Schaefer]

On Nov 1,  2:26pm, Alan Pinstein wrote:
}
} # start 2 ssh sessions in zsh 5.0.0 from macports, one from ZLE/CLI
} and one via a function...

OK, obviously I haven't been understanding what you're doing.

I thought you meant
    ssh -> zsh -> function -> function runs command -> HUP ssh

But now I think you mean
    zsh -> function -> function runs ssh -> ssh runs command -> HUP zsh

So can you please describe EXACTLY what you're doing, step by step?

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

[Alan Pinstein]

> But now I think you mean
>   zsh -> function -> function runs ssh -> ssh runs command -> HUP zsh

Yes.

I am on a Mac, using iTerm. I start a new window in iTerm. It loads my zshrc which includes a function definition that wraps ssh.

If I run "/usr/bin/ssh somewhere" (skipping the function) and then CLOSE the terminal window, the ssh call exits as expected and everything is great.

If I run "ssh somewhere" (which ssh's from inside a function) and then CLOSE the terminal window, the ssh command does not exit, it gets orphaned (ppid=1) and never exits. This causes issues b/c I think the command loses its TTY and it ends up hosing my screen session on the other end of the ssh session. If I kill the orphaned process, screen starts working immediately again.

I was able to reproduce the orphaning behavior with a PHP command so I know that it isn't some weird SSH bug.

Does that help?

Alan