On 2023-09-22 15:56:05 +0200, Vincent Lefevre wrote:
> A summary of the issue: I'm using a wrapper to ssh in order to
> call ssh-add before the real ssh, when needed. When I run unison
> and type Ctrl-C when a passphrase is asked by ssh-add, this kills
> unison and my wrapper, but not ssh-add.
[...]
After thinking more about this... The current status is that unison
does not create its own process group. This is not an issue when it
is run directly from a shell, because the shell itself creates a
process group for the command (e.g. unison). But, like in my case,
if unison is started by a process that also deals with the terminal,
one may have problems.
The whole process group normally receives the SIGINT due to the
Ctrl-C, which may kill an ancestor of unison. But ssh and its
descendants do not receive it because unison has set it to be
ignored. And unison has trapped it for the cleanup.
In the case
Shell → command → unison
the command and unison both receive the SIGINT. If the command
traps the SIGINT to wait for unison, no problems. But if it is
killed by SIGINT, the shell will start again to read from the
terminal. The following case is similar:
Shell → A → B → unison
where B is killed by the SIGINT and A traps it and starts again
to read from the terminal. As an example, in my case:
... → Mutt → wrapper → unison
Now, the issue with the above situation is if unison or one of its
descendants reads from the terminal after the SIGINT, so that there
will be a fight between this process and the ancestor. It appears
that unison does not read from the terminal, but ssh or one of its
descendants (in my case, ssh-add via a wrapper) might do so.
Currently, there isn't any issue with ssh alone, but I'm wondering
whether this will always be the case in the future.
I had suggested "when receiving a SIGINT, unison should send it to
the process group, not just to ssh", but now, I do not think that
this will necessarily solve the problem (it could just mitigate the
issue, and perhaps not in all cases). One point is that the signal
is not sent to ssh until unison has completed the cleanup. So there
will be at least a race condition.
So I can see 2 solutions:
1. Fix outside of unison: Every command involved must trap the signals
and wait for their child to terminate.
2. Fixes in unison:
A. Make unison create its own process group (but is this OK?),
so that the Ctrl-C doesn't affect the ancestors.
B. Make unison send the signal to the process group, just as if
SIGINT were not ignored.
--
Vincent Lefèvre <vinc...@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)
