Re: [PATCH v2] transport-helper, connect: add atexit handler to reap children on abnormal exit

From: Andrew Au <cshung@gmail.com>
Date: Mar 11, 2026, 18:19 UTC
Message-ID: <CAGVkMb6M2buc5zS+SFfYa6LLs7fN369MrVagETVg0U_PN7njOg@mail.gmail.com>
In-Reply-To: <xmqqsea6p7st.fsf@gitster.g>

Thank you for the feedback.

The use case is a long-running service running as PID 1 inside a container. The service continuously spawns git to detect repository changes — it is not a one-shot container where git itself is the primary process. Because the service is meant to stay alive indefinitely, any zombies git leaves behind accumulate over time rather than being cleaned up when the container exits.

In my specific case, I observed over 6,500 zombie processes before identifying this as the root cause. The blog post linked in the cover letter documents the investigation in detail.

The fix ensures git cleans up its own children on abnormal exit paths, which is the right behavior regardless of whether the parent is PID 1 or not.

On Wed, Mar 11, 2026 at 10:58 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

>
> Andrew Au <cshung@gmail.com> writes:
>
> > When git exits via exit(128) on transport errors, child processes
> > (git-remote-https, ssh, proxy) are never waited on because the normal
> > cleanup paths (disconnect_helper, finish_connect) are bypassed. When
> > git is PID 1 in a container, these un-reaped children become zombies.
>
> Could you tell me more about the real use case behind such a set-up.
>
> These children become zombies, and then what will be done to the
> container that lost the "git" process, running of which presumably
> was the primary reason why the container was brought up in the first
> place?  Wouldn't these zombies go away when the container that
> finished its sole purpose of running "git" gets dismantled?
>
> Thanks.