* How to propagate SIGTERM to the foreground job, if any? @ 2024-04-19 17:17 Vincent Lefevre 2024-04-19 18:30 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-19 17:17 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-19 17:17 How to propagate SIGTERM to the foreground job, if any? Vincent Lefevre @ 2024-04-19 18:30 ` Bart Schaefer 2024-04-19 19:00 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2024-04-19 18:30 UTC (permalink / raw) To: zsh-users 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 % ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-19 18:30 ` Bart Schaefer @ 2024-04-19 19:00 ` Vincent Lefevre 2024-04-19 20:06 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-19 19:00 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-19 19:00 ` Vincent Lefevre @ 2024-04-19 20:06 ` Bart Schaefer 2024-04-19 21:32 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2024-04-19 20:06 UTC (permalink / raw) To: zsh-users 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 % ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-19 20:06 ` Bart Schaefer @ 2024-04-19 21:32 ` Vincent Lefevre 2024-04-21 4:09 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-19 21:32 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-19 21:32 ` Vincent Lefevre @ 2024-04-21 4:09 ` Bart Schaefer 2024-04-21 17:29 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2024-04-21 4:09 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-21 4:09 ` Bart Schaefer @ 2024-04-21 17:29 ` Vincent Lefevre 2024-04-21 17:43 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-21 17:29 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-21 17:29 ` Vincent Lefevre @ 2024-04-21 17:43 ` Vincent Lefevre 2024-04-21 21:25 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-21 17:43 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-21 17:43 ` Vincent Lefevre @ 2024-04-21 21:25 ` Bart Schaefer 2024-04-21 23:59 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2024-04-21 21:25 UTC (permalink / raw) To: zsh-users 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 ? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-21 21:25 ` Bart Schaefer @ 2024-04-21 23:59 ` Vincent Lefevre 2024-04-22 0:41 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-21 23:59 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-21 23:59 ` Vincent Lefevre @ 2024-04-22 0:41 ` Bart Schaefer 2024-04-23 15:17 ` Vincent Lefevre 0 siblings, 1 reply; 13+ messages in thread From: Bart Schaefer @ 2024-04-22 0:41 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-22 0:41 ` Bart Schaefer @ 2024-04-23 15:17 ` Vincent Lefevre 2024-04-23 17:32 ` Bart Schaefer 0 siblings, 1 reply; 13+ messages in thread From: Vincent Lefevre @ 2024-04-23 15:17 UTC (permalink / raw) To: zsh-users 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) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to propagate SIGTERM to the foreground job, if any? 2024-04-23 15:17 ` Vincent Lefevre @ 2024-04-23 17:32 ` Bart Schaefer 0 siblings, 0 replies; 13+ messages in thread From: Bart Schaefer @ 2024-04-23 17:32 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2024-04-23 17:34 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-19 17:17 How to propagate SIGTERM to the foreground job, if any? Vincent Lefevre 2024-04-19 18:30 ` Bart Schaefer 2024-04-19 19:00 ` Vincent Lefevre 2024-04-19 20:06 ` Bart Schaefer 2024-04-19 21:32 ` Vincent Lefevre 2024-04-21 4:09 ` Bart Schaefer 2024-04-21 17:29 ` Vincent Lefevre 2024-04-21 17:43 ` Vincent Lefevre 2024-04-21 21:25 ` Bart Schaefer 2024-04-21 23:59 ` Vincent Lefevre 2024-04-22 0:41 ` Bart Schaefer 2024-04-23 15:17 ` Vincent Lefevre 2024-04-23 17:32 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).