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

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

[Vincent Lefevre]

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

I would have thought that the following would work:

setopt TRAPS_ASYNC
trap "trap - TERM; kill ${jobstates:+%%} $$" TERM

But it seems that $jobstates is not available in the trap.

Note: "kill %% $$" is no OK because I do not want an error message
if there are no jobs.

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Bart Schaefer]

On Fri, Apr 19, 2024 at 10:18 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> How to propagate SIGTERM to the foreground job, if any?

Hm ... if there's a foreground job, it should be the process group
leader for the terminal (so as to receive TSTP and INT), so it might
work just to do "kill 0 TERM"

> setopt TRAPS_ASYNC
> trap "trap - TERM; kill ${jobstates:+%%} $$" TERM
>
> But it seems that $jobstates is not available in the trap.

It's not that $jobstates is not available, it's that the foreground
job isn't in the table at all.

% trap 'print -aC2 -r -- "${(@kv)jobstates}"' INT
% sleep 10 & sleep 2 & sleep 5
[1] 39824
[2] 39825
^C
1  running:-:39824=running
2  running:+:39825=running
%

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

[Vincent Lefevre]

On 2024-04-19 11:30:35 -0700, Bart Schaefer wrote:
> On Fri, Apr 19, 2024 at 10:18 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > How to propagate SIGTERM to the foreground job, if any?
> 
> Hm ... if there's a foreground job, it should be the process group
> leader for the terminal (so as to receive TSTP and INT), so it might
> work just to do "kill 0 TERM"

I don't understand why you are saying that "it should be the process
group leader for the terminal". This is not true in my case (the
leader is some ancestor), and note that I do not want to kill the
whole process group.

> > setopt TRAPS_ASYNC
> > trap "trap - TERM; kill ${jobstates:+%%} $$" TERM
> >
> > But it seems that $jobstates is not available in the trap.
> 
> It's not that $jobstates is not available, it's that the foreground
> job isn't in the table at all.

But then, why does "kill %%" work?

Is there a way to know whether %% exists?

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Bart Schaefer]

On Fri, Apr 19, 2024 at 12:00 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> I don't understand why you are saying that "it should be the process
> group leader for the terminal". This is not true in my case (the
> leader is some ancestor)

I don't understand how you're determining that the leader is an ancestor.

That you have job control at all implies this is an interactive shell.
When zsh starts interactively, it attaches to the TTY and makes itself
the group leader.

Subsequently, each time a foreground job is started, zsh attaches that
to the TTY and makes it a new group leader, only reclaiming the TTY
after the foreground job exits.  If it did not do this, ^Z and ^C
would not work.

The only way for an "ancestor" of the job you want to TERM to be the
group leader is if the job zsh started has subsequently forked again,
in which case zsh doesn't have any knowledge or control of the
"grandchild".

That still doesn't mean that "kill 0" from the zsh process would kill
the desired process group, I didn't actually try it.

> On 2024-04-19 11:30:35 -0700, Bart Schaefer wrote:
> >
> > It's not that $jobstates is not available, it's that the foreground
> > job isn't in the table at all.

I was misled there by trying to use INT.  The current job is reaped
before the trap runs.

> But then, why does "kill %%" work?

It doesn't.

% setopt trapsasync
% trap 'print -raC2 -- ${(kv)jobstates}' TERM
% (sleep 2 ; kill -TERM $$) & sleep 10 & sleep 3 & sleep 5
[1] 40302
[2] 40303
[3] 40305
1  running::40302=running
2  running:-:40303=running
3  running:+:40305=running
4  running::40306=running
[1]    done       ( sleep 2; kill -TERM $$; )
[3]  + done       sleep 3
%
[2]  + done       sleep 10

So in the above, job #4 would be the foreground job, but %+
(equivalent to %%) is job #3.  The foreground job has no % shortcut.
Further evidence:

% (sleep 2 ; kill -TERM $$) &! sleep 10
1  running::40317=running
% trap 'print -- ${jobstates:+SET}' TERM
% (sleep 2 ; kill -TERM $$) &! sleep 10
SET
% trap 'trap -- TERM; kill ${jobstates:+%%}' TERM
% (sleep 2 ; kill -TERM $$) &! sleep 10
kill: no current job
%

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

[Vincent Lefevre]

On 2024-04-19 13:06:12 -0700, Bart Schaefer wrote:
> On Fri, Apr 19, 2024 at 12:00 PM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > I don't understand why you are saying that "it should be the process
> > group leader for the terminal". This is not true in my case (the
> > leader is some ancestor)
> 
> I don't understand how you're determining that the leader is an ancestor.
> 
> That you have job control at all implies this is an interactive shell.
> When zsh starts interactively, it attaches to the TTY and makes itself
> the group leader.

No, this is a script. You can test with

#!/usr/bin/env zsh
setopt TRAPS_ASYNC
echo $$
trap "trap - TERM; kill %1 $$" TERM
xterm
echo end

and type "kill <pid>" with the <pid> output by the script. This
kills both xterm and the script (no "end" output). Without the %1,
xterm isn't killed.

This shows that one can get the associated job of the foreground
command.

> > But then, why does "kill %%" work?
> 
> It doesn't.

Indeed, it doesn't, but %1 works (this was what I actually tried,
and I thought I had tried %% too, which I actually did only with
${jobstates:+%%} I think).

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Bart Schaefer]

On Fri, Apr 19, 2024 at 2:32 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On 2024-04-19 13:06:12 -0700, Bart Schaefer wrote:
> >
> > That you have job control at all implies this is an interactive shell.
>
> No, this is a script.

OK.

> > > But then, why does "kill %%" work?
> >
> > It doesn't.
>
> Indeed, it doesn't, but %1 works

Except that %1 might be the wrong job number if there are any background jobs?

Why not do it like this?

setopt TRAPS_ASYNC
echo $$
trap 'kill $xterm; exit' TERM
xterm & xterm=$!
wait $xterm
echo end

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

[Vincent Lefevre]

On 2024-04-20 21:09:46 -0700, Bart Schaefer wrote:
> > > > But then, why does "kill %%" work?
> > >
> > > It doesn't.
> >
> > Indeed, it doesn't, but %1 works
> 
> Except that %1 might be the wrong job number if there are any
> background jobs?

Yes, that's a potential issue, and that's why I would prefer %%.

> Why not do it like this?
> 
> setopt TRAPS_ASYNC
> echo $$
> trap 'kill $xterm; exit' TERM
> xterm & xterm=$!
> wait $xterm
> echo end

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.

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Vincent Lefevre]

On 2024-04-21 19:29:09 +0200, Vincent Lefevre wrote:
> On 2024-04-20 21:09:46 -0700, Bart Schaefer wrote:
> > Why not do it like this?
> > 
> > setopt TRAPS_ASYNC
> > echo $$
> > trap 'kill $xterm; exit' TERM
> > xterm & xterm=$!
> > wait $xterm
> > echo end
> 
> 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.

Moreover, a Ctrl-C in the terminal doesn't seem to be handled
correctly (here, ssh-add with several files in argument is executed
via zsh functions, but it refuses to quit on Ctrl-C).

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Bart Schaefer]

On Sun, Apr 21, 2024 at 10:44 AM Vincent Lefevre <vincent@vinc17.net> 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

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

Which terminal?

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

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

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

[Vincent Lefevre]

On 2024-04-21 14:25:31 -0700, Bart Schaefer wrote:
> On Sun, Apr 21, 2024 at 10:44 AM Vincent Lefevre <vincent@vinc17.net> 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@vinc17.net> - 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)

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

[Bart Schaefer]

On Sun, Apr 21, 2024 at 4:59 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> 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.

So really what we're searching for here is a workaround for a bug in a
different application that happens to be executing a zsh script.

Try this:
  trap 'setopt MONITOR HUP NOCHECKJOBS; exit' TERM

That won't kill an xterm process because xterm ignores SIGHUP, but it
should kill ssh-add.

>   ssh-add file1 file2 file3 &
>
> 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

That's ... interesting.  The error makes it look like ssh-askpass is
what's not being found, but it's probably choking trying to open a
terminal.  I can think of some possible ways to fake it but perhaps
with the above MONITOR tweak it isn't necessary.

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

[Vincent Lefevre]

I think that I should start to test with something simpler, with
a command like

  unison -sshcmd ~/scripts/ssh ~/testdir ssh://remote_host/testdir

For ~/scripts/ssh, the following works with I type Ctrl-C
when ssh-add asks for the passphrase:

------------------------------------------------------------
#!/usr/bin/env zsh                                                              

unset DISPLAY

setopt TRAPS_ASYNC
trap 'echo term >&2; kill %1; exit' TERM INT

ssh-add file1 file2 file3

echo end... >&2
exit
------------------------------------------------------------

But %1 might not be the right job in more complex cases.
BTW, I'm wondering why %1 works, but not %%.

Moreover "term" is output twice. Why?

The following, based on what you proposed, also works:

------------------------------------------------------------
#!/usr/bin/env zsh

unset DISPLAY

setopt TRAPS_ASYNC
trap 'echo term >&2; kill $e; exit' TERM INT

ssh-add file1 file2 file3 &
e=$!
wait $e

echo end... >&2
exit
------------------------------------------------------------

This time, "term" is output 1, 2 or 3 times.

But these solutions do not work when ssh-add is in a zsh function,
even in a simple case like:

f()
{
  ssh-add file1 file2 file3
}

and use "f" instead of "ssh-add file1 file2 file3".

Is this a bug or is there any reason?

On 2024-04-21 17:41:38 -0700, Bart Schaefer wrote:
> Try this:
>   trap 'setopt MONITOR HUP NOCHECKJOBS; exit' TERM

This doesn't work at all with the above test.

> >   ssh-add file1 file2 file3 &
> >
> > 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
> 
> That's ... interesting.  The error makes it look like ssh-askpass is
> what's not being found, but it's probably choking trying to open a
> terminal.  I can think of some possible ways to fake it but perhaps
> with the above MONITOR tweak it isn't necessary.

I don't remember what I did exactly. These errors occur if DISPLAY
is set (with my usual wrapper, I unset DISPLAY, so that there may
be another cause).

-- 
Vincent Lefèvre <vincent@vinc17.net> - 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)

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

[Bart Schaefer]

On Tue, Apr 23, 2024 at 8:17 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> I think that I should start to test with something simpler, with
> a command like
>
>   unison -sshcmd ~/scripts/ssh ~/testdir ssh://remote_host/testdir

I would wish for a test with something simpler than unison as the
driver, but ...

> For ~/scripts/ssh, the following works with I type Ctrl-C
> when ssh-add asks for the passphrase:

If you mean running scripts/ssh from an interactive shell, I'd expect
^C to work even without the trap, because the terminal driver will
deliver the INT to ssh-add before (or effectively simultaneously with)
zsh.

> But %1 might not be the right job in more complex cases.
> BTW, I'm wondering why %1 works, but not %%.

As I said before, %% is the same as %+ which is the most recent
background job.  There's no shortcut to the foreground job because zsh
assumes that a foreground process will get job control signals
directly from the terminal driver -- invoking job control from a
signal trap that bypasses the foreground process was never considered
in the design.

> Moreover "term" is output twice. Why?

I believe what's happening is this:  When you "kill %1" the job exits
with status 143, which indicates it received a TERM signal.  When zsh
gets the SIGCHLD and sees the exit status, it interprets this as
meaning it should also handle the TERM signal.

> But these solutions do not work when ssh-add is in a zsh function

I think that's because using a function wrapper causes the function
itself to be come a subshell that has its own copy of the trap.
Within the subshell, there is no $e (copied from $! only in the
parent) so the trap doesn't work.  What happens if you "exec ssh-add"
in the function instead of just calling it?

> On 2024-04-21 17:41:38 -0700, Bart Schaefer wrote:
> > Try this:
> >   trap 'setopt MONITOR HUP NOCHECKJOBS; exit' TERM
>
> This doesn't work at all with the above test.

Hm, unison may be blocking the HUP signal as well.  Try adding
  trap - HUP
to the script to restore default behavior in the children.