git/list[1] front-page[2] threads[3] people[4] search[5] about
 

I discovered a minor issue with `git fetch`.

From
SSURA <surak8806@gmail.com>
Date
May 22, 2026, 07:45 UTC
Message-ID
<CAD6AYr9YmcnkdW=Nx=HUKcuaNbv1ukrAbXRnKyGibCQDy8N3hQ@mail.gmail.com>
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.

Here are the simple steps to reproduce this issue:
1. `git clone https://github.com/SURA907/pid-1.git`
2. `cd pid-1`
3. `docker build -t pid-1 .`
4. `docker run -d --name pid-1 pid-1:latest`
5. `docker exec -it pid-1 /bin/bash`
6. `mkdir repo && cd repo && git init --bare`
7. `ps -ef`
------
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 07:16 ? 00:00:00 tail -f /dev/null
root 7 0 0 07:16 pts/0 00:00:00 /bin/bash
root 13 0 0 07:16 pts/1 00:00:00 /bin/bash
root 29 7 0 07:17 pts/0 00:00:00 ps -ef
------
8. `git fetch https://github.com/git/git.git`
9. `ps -ef` (Run this command from a separate terminal session
connected to the container)
------
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 07:16 ? 00:00:00 tail -f /dev/null
root 7 0 0 07:16 pts/0 00:00:00 /bin/bash
root 13 0 0 07:16 pts/1 00:00:00 /bin/bash
root 30 13 1 07:17 pts/1 00:00:00 git fetch https://github.com/git/git.git
root 31 30 0 07:17 pts/1 00:00:00 /usr/local/libexec/git-core/git
remote-https https://github.com/git/git.git
https://github.com/git/git.git
root 32 31 2 07:17 pts/1 00:00:00
/usr/local/libexec/git-core/git-remote-https
https://github.com/git/git.git https://github.com/git/git.git
root 36 30 30 07:17 pts/1 00:00:00 /usr/local/libexec/git-core/git
index-pack --stdin -v --fix-thin --keep=fetch-pack 30 on sura-pc
--pack_header=2,399455
root 38 7 0 07:17 pts/0 00:00:00 ps -ef
------
10. ps -ef (after fetch ends)
------
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 07:16 ? 00:00:00 tail -f /dev/null
root 7 0 0 07:16 pts/0 00:00:00 /bin/bash
root 13 0 0 07:16 pts/1 00:00:00 /bin/bash
root 52 1 0 07:19 ? 00:00:00 [git] <defunct>
root 53 7 0 07:19 pts/0 00:00:00 ps -ef
------

A zombie process has appeared. It appears to originate from a `fetch` subprocess that terminates very quickly; despite several attempts, I have been unable to successfully capture it.

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.

Next: Ben Knoble
Message 1 of 4 in “I discovered a minor issue with `git fetch`.”
  1. SURAMay 22, 2026
  2. Ben KnobleMay 22, 2026
  3. brian m. carlsonMay 25, 2026
  4. git-maintenance detach timing, was Re: I discovered a minor issue with `git fetch`.Jeff King, May 27, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.