From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: SURA <surak8806@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: I discovered a minor issue with `git fetch`.
Date: Mon, 25 May 2026 00:45:26 +0000 [thread overview]
Message-ID: <ahObpiF9WvL-EfsB@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAD6AYr9YmcnkdW=Nx=HUKcuaNbv1ukrAbXRnKyGibCQDy8N3hQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]
On 2026-05-22 at 07:45:25, SURA wrote:
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]
prev parent reply other threads:[~2026-05-25 0:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-22 7:45 I discovered a minor issue with `git fetch` SURA
2026-05-22 17:46 ` Ben Knoble
2026-05-25 0:45 ` brian m. carlson [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=ahObpiF9WvL-EfsB@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=surak8806@gmail.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