[PATCH] run-command.c: ensure signaled hook scripts are waited upon

[PATCH] run-command.c: ensure signaled hook scripts are waited upon

[Anthony Sottile]

In the event of a `^C` while hook scripts are running, ensure that the
hook processes are cleaned up and do not become zombies.  This also ensures
that upon `^C` execution is not handed back to the terminal until the
processes have been waited upon.

Signed-off-by: Anthony Sottile <asottile@umich.edu>
---
 run-command.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/run-command.c b/run-command.c
index f5e1149..75d3b73 100644
--- a/run-command.c
+++ b/run-command.c
@@ -1358,6 +1358,8 @@ int run_hook_ve(const char *const *env, const char *name, va_list args)
 	hook.no_stdin = 1;
 	hook.stdout_to_stderr = 1;
 	hook.trace2_hook_name = name;
+	hook.clean_on_exit = 1;
+	hook.wait_after_clean = 1;
 
 	return run_command(&hook);
 }
-- 
2.25.GIT

Re: [PATCH] run-command.c: ensure signaled hook scripts are waited upon

[Jeff King]

On Thu, Feb 20, 2020 at 10:06:36PM -0800, Anthony Sottile wrote:

> In the event of a `^C` while hook scripts are running, ensure that the
> hook processes are cleaned up and do not become zombies.  This also ensures
> that upon `^C` execution is not handed back to the terminal until the
> processes have been waited upon.

If we assume that most people would prefer this "wait until the hook has
died" behavior, I think this shouldn't have any unwanted secondary
effects. I'm on the fence on whether it's what most people would want or
not (I guess most people don't care either way, because their scripts
don't ignore SIGINT).

(Earlier in the thread, we discussed possibly swapping the order of the
cleanup code and dropping the signal handler, which could have more
unexpected effects, but that part isn't in this patch).

-Peff

Re: [PATCH] run-command.c: ensure signaled hook scripts are waited upon

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> If we assume that most people would prefer this "wait until the hook has
> died" behavior, I think this shouldn't have any unwanted secondary
> effects. I'm on the fence on whether it's what most people would want or
> not (I guess most people don't care either way, because their scripts
> don't ignore SIGINT).

Yeah, and imagining why they deliberately ignore INT (i.e. "because
I want this hook not be interrupted and run to its completion") does
not help guess if they want git to wait for hook's completion or
just go ahead and die of its own signal death.  We could timeout the
waiting and kill such a child forcibly, and that may avoid these
hook script that ignore INT to hang around, but I do not know if
that is desirable.