From: Jeff King <peff@peff.net>
To: Jan Palus <jpalus@fastmail.com>
Cc: git@vger.kernel.org, Andrew Au <cshung@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] Revert "transport-helper, connect: use clean_on_exit to reap children on abnormal exit"
Date: Wed, 22 Apr 2026 19:00:20 -0400 [thread overview]
Message-ID: <20260422230020.GA1839627@coredump.intra.peff.net> (raw)
In-Reply-To: <20260422223542.GA110382@coredump.intra.peff.net>
On Wed, Apr 22, 2026 at 06:35:43PM -0400, Jeff King wrote:
> So I think just reverting dd3693eb08 is probably the most immediate fix.
Here it is in patch form.
-- >8 --
Subject: Revert "transport-helper, connect: use clean_on_exit to reap children on abnormal exit"
This reverts commit dd3693eb0859274d62feac8047e1d486b3beaf31.
The goal of that commit was to avoid zombie child processes hanging
around when the parent git process is killed. But it doesn't quite work
when the child command is run by the shell:
1. If there is a shell, then we kill and wait for the shell, not the
process spawned by the shell. And so the child process, even if it
eventually exits, will hang around as a zombie forever. And this is
true of most (all?) shells: bash, dash, etc.
So we are not really accomplishing our goal in the first place.
2. Not all shells will exit immediately upon receiving a signal. In
particular, mksh will wait for its children to exit (but not
actually propagate the signal to them!) leaving us with a potential
deadlock: git is wait()ing on mksh, which is wait()ing on a child
process, but that child process is waiting on git to produce more
input (or EOF) over a pipe.
You can see several examples of this deadlock in the test suite,
for example by running:
make SHELL_PATH=/bin/mksh
cd t
./t5702-protocol-v2.sh
Because this is a regression for mksh users, and because we did not
achieve our goal even with other shells, let's revert the commit for
now. If there is a more clever way of doing the same thing, we can
consider applying it separately on top (or do nothing and just accept
the zombies and rely on PID 1 to reap them).
Reported-by: Jan Palus <jpalus@fastmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
connect.c | 4 ----
transport-helper.c | 2 --
2 files changed, 6 deletions(-)
diff --git a/connect.c b/connect.c
index fcd35c5539..a02583a102 100644
--- a/connect.c
+++ b/connect.c
@@ -1054,8 +1054,6 @@ static struct child_process *git_proxy_connect(int fd[2], char *host)
strvec_push(&proxy->args, port);
proxy->in = -1;
proxy->out = -1;
- proxy->clean_on_exit = 1;
- proxy->wait_after_clean = 1;
if (start_command(proxy))
die(_("cannot start proxy %s"), git_proxy_command);
fd[0] = proxy->out; /* read from proxy stdout */
@@ -1517,8 +1515,6 @@ struct child_process *git_connect(int fd[2], const char *url,
}
strvec_push(&conn->args, cmd.buf);
- conn->clean_on_exit = 1;
- conn->wait_after_clean = 1;
if (start_command(conn))
die(_("unable to fork"));
diff --git a/transport-helper.c b/transport-helper.c
index 4e5d1d914f..4614036c99 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -154,8 +154,6 @@ static struct child_process *get_helper(struct transport *transport)
helper->trace2_child_class = helper->args.v[0]; /* "remote-<name>" */
- helper->clean_on_exit = 1;
- helper->wait_after_clean = 1;
code = start_command(helper);
if (code < 0 && errno == ENOENT)
die(_("unable to find remote helper for '%s'"), data->name);
--
2.54.0.232.gea82d9008b
prev parent reply other threads:[~2026-04-22 23:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 19:00 regression 2.54.0: test suite hangs indefinitely with mksh Jan Palus
2026-04-22 22:35 ` Jeff King
2026-04-22 23:00 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260422230020.GA1839627@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=cshung@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jpalus@fastmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox