Re: How to propagate SIGTERM to the foreground job, if any?

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2024-04-21 14:25:31 -0700, Bart Schaefer wrote:
> On Sun, Apr 21, 2024 at 10:44 AM Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> >
> > > xterm was just a very simple example. In practice, several commands
> > > are involved, and among them, there are zsh functions that may need
> > > to affect the environment.
> 
> This seems to work:
> 
> trap 'kill -TERM -$$ ; exit' TERM

No, this was basically one of the first things I had tried. But
this assumes that the shell script is the process group leader,
and in my case, it isn't (see below).

> > Moreover, a Ctrl-C in the terminal doesn't seem to be handled
> > correctly
> 
> Which terminal?

The terminal where the script is running. One of the use cases
(which is causing the problem) is that I have a GNU Screen session
running Mutt, and from Mutt I execute a script, which executes
unison, which needs to execute ssh. But instead of ssh, it executes
a zsh script, which does various things before executing the real
ssh; in particular, it may execute ssh-add (via a zsh function).
The process group leader is the mutt process.

I use the same mechanism with Subversion and Git (which may need
ssh), and when I type Ctrl-C, this kills what needs to be killed,
as expected.

But here, the issue is that unison blocks SIGINT for its child
(ssh, which, in my case, is the wrapper script) so that it can do
some cleanup on the remote side before ssh is terminated. After
the cleanup, unison sends a SIGTERM to its child. But this means
that only the script is killed. If a ssh-add was running, asking
for a passphrase, then keys typed in the terminal are sent to
either Mutt or ssh-add, more or less randomly, while I would
expect ssh-add to be terminated.

I also found a few days ago that a similar issue occurred due to a
possible timeout in unison, e.g. if I wait too long before typing
the passphrase (so, even if SIGINT were not blocked, there would
still be an issue with the possible timeout).

You can see additional details in the bug I had reported several
months ago:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052451

but after some reflection and finding the issue with the timeout,
I think that the real bug is in my script, which should kill the
current job and itself when receiving SIGTERM.

> > (here, ssh-add with several files in argument is executed
> > via zsh functions, but it refuses to quit on Ctrl-C).
> 
> Does this mean you can't interrupt it while it's prompting for a
> passphrase?

I don't know what happens exactly. Normally (e.g. when run from the
command line), both SIGINT and SIGTERM terminates it.

> Can you reproduce this with something other than ssh-add ?

Your script with xterm is fine. But if I replace "xterm &" by

  ssh-add file1 file2 file3 &

I get

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory

errors. It seems that ssh-add doesn't like to be backgrounded.
ssh-add in foreground doesn't have any issue, but of course,
this script no longer works as wanted.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)