Re: I discovered a minor issue with `git fetch`.

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 25, 2026, 00:45 UTC
Message-ID: <ahObpiF9WvL-EfsB@fruit.crustytoothpaste.net>
In-Reply-To: <CAD6AYr9YmcnkdW=Nx=HUKcuaNbv1ukrAbXRnKyGibCQDy8N3hQ@mail.gmail.com>

On 2026-05-22 at 07:45:25, SURA wrote:

Show 20 quoted lines

> Hello everyone
> 
> The child processes spawned by `git fetch` can become zombie processes.
> In most scenarios, these zombie processes are reaped by Process 1, so
> this typically doesn't cause any problems.
> 
> However, within a Docker container, the application service itself is
> sometimes designated as Process 1 (for instance, a service written in
> Go). Since these application services lack the capability to reap
> zombie processes, the zombies will gradually exhaust the available PID
> resources.
> This issue was discovered within a legacy service. A few days after
>
> upgrading to Git 2.53.0, the system's PID resources were exhausted by
> zombie processes. This is likely the result of recent changes, as this
> problem did not exist in earlier versions (2.4x).
> 
> To be honest, this is not an urgent matter; I have already deployed
> `tini` as the init process (PID 1) to prevent the service from
> becoming unavailable.

While there has been some discussion about this on the list in the recent past, using something like tini is the right move in the general case. There are a variety of programs which might daemonize a background process for whatever reason and those will necessarily require an init process to reap children. It's considered a standard requirement that PID 1 has that ability and Git doesn't provide it.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA