[PATCH] ci(dockerized): reduce the PID limit for private repositories

Johannes Schindelin via GitGitGadget

author

2026-07-01 07:04 UTC #0 lore raw

PATCH 1/1 ci(dockerized): reduce the PID limit for private repositories

From: Johannes Schindelin <[email protected]>

Every once in a while I need to verify that Microsoft Git's test suite passes for changes that are not yet meant for public consumption, and since it was (made) too difficult to keep up a working Azure Pipeline definition, I have to use GitHub Actions in a private GitHub repository for that purpose.

In these tests, basically all Dockerized CI jobs fail consistently. The symptom is something like:

error: cannot create async thread: Resource temporarily unavailable

in the middle of a test, typically in the t5xxx-t6xxx range. The first such error is immediately followed by plenty more of these errors, and not a single test succeeds afterwards.

At first, I thought that maybe the massive parallelism I enjoy there is the problem, and I thought that the cgroups limits might be shared between the many containers that run on essentially the same physical machine. But even reducing the matrix to just a single of those Dockerized jobs runs into the very same problems.

The underlying reason seems to be a substantial difference in the hosted runners that execute these Dockerized jobs: forcing the PID limit of the container to a high number lets the jobs pass, even when running the complete matrix of all 13 Dockerized jobs concurrently. But that's not the only difference: The jobs seem to take a lot longer in these containers than, say, in the containers made available to
https://github.com/git/git.

When forcing a PID limit of 64k in that private repository, the jobs completed successfully, but they also took a lot longer, between 2x to 2.5x longer, i.e. painfully much longer. Reducing the PID limit to 16k, the CI jobs still passed, but took an equally long amount of time. Reducing the PID limit to 8k caused the errors to reappear.

Here are the numbers from three example runs, the first one forcing the PID and nproc limit to 65536, the second one to 16384, the third run is from the public git/git repository:

Job                           | 64k     | 16k     | reference
------------------------------|---------|---------|---------
almalinux-8                   | 19m 3s  | 16m 0s  | 9m 36s
debian-11                     | 20m 31s | 20m 3s  | 8m 5s
fedora-breaking-changes-meson | 16m 29s | 19m 19s | 9m 40s
linux-asan-ubsan              | 1h 10m  | 1h 11m  | 34m 36s
linux-breaking-changes        | 25m 39s | 25m 58s | 13m 15s
linux-leaks                   | 1h 9m   | 1h 10m  | 33m 30s
linux-meson                   | 28m 9s  | 27m 4s  | 13m 45s
linux-musl-meson              | 16m 32s | 13m 39s | 8m 6s
linux-reftable-leaks          | 1h 13m  | 1h 13m  | 34m 34s
linux-reftable                | 26m 2s  | 25m 48s | 13m 31s
linux-sha256                  | 26m 12s | 26m 3s  | 12m 36s
linux-TEST-vars               | 26m 5s  | 25m 21s | 13m 25s
linux32                       | 21m 16s | 19m 57s | 10m 44s

It does not look as if the PID limit is the reason for the longer runtime, seeing as the 64k vs 16k timings deviate no more than as is usual with GitHub workflows. So let's go for 16k.

Signed-off-by Johannes Schindelin <[email protected]>

---
ci(dockerized): reduce the PID limit for private repositories

I needed to craft this patch while developing fixes for vulnerabilities which eventually were published as Git for Windows v2.53.0(3).

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2164%2Fdscho%2Fraise-pid-limit-in-private-repositories-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2164/dscho/raise-pid-limit-in-private-repositories-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2164

 .github/workflows/main.yml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

.github/workflows/main.yml +3 -1

index cf341d74db..85cfedf5b0 100644
@@ -420,7 +420,9 @@ jobs:
       CI_JOB_IMAGE: ${{matrix.vector.image}}
       CUSTOM_PATH: /custom
     runs-on: ubuntu-latest
-    container: ${{matrix.vector.image}}
+    container:
+      image: ${{ matrix.vector.image }}
+      options: ${{ github.repository_visibility == 'private' && '--pids-limit 16384 --ulimit nproc=16384:16384 --ulimit nofile=32768:32768' || '' }}
     steps:
     - name: prepare libc6 for actions
       if: matrix.vector.jobname == 'linux32'

base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc

Signature · 1 line

gitgitgadget

Junio C Hamano

2026-07-01 16:55 UTC #1 lore raw

"Johannes Schindelin via GitGitGadget" <[email protected]>

Quoted 4 lines · writes:

The underlying reason seems to be a substantial difference in the hosted runners that execute these Dockerized jobs: forcing the PID limit of the container to a high number lets the jobs pass, even when running the complete matrix of all 13 Dockerized jobs concurrently.

Is the "reduce" in the title accurate? The above description tells me that what you did was to "raise" the PID limit (i.e., forcing the PID limit to a high number), presumably because the default PID limit is way too low for the tests to pass?

And that fix turns constant failures into success (albeit the tests run very slowly, which is a separate topic that you discuss next).

Quoted 5 lines

But that's not
the only difference: The jobs seem to take a lot longer in these containers than, say, in the containers made available to
https://github.com/git/git.

Quoted 9 lines

When forcing a PID limit of 64k in that private repository, the jobs completed successfully, but they also took a lot longer, between 2x to 2.5x longer, i.e. painfully much longer. Reducing the PID limit to 16k, the CI jobs still passed, but took an equally long amount of time. Reducing the PID limit to 8k caused the errors to reappear.
...
It does not look as if the PID limit is the reason for the longer runtime, seeing as the 64k vs 16k timings deviate no more than as is usual with GitHub workflows. So let's go for 16k.

So 8k is too low to make them pass, just like the default setting (whatever it is), but 16k is sufficient, so this patch settles at that number, which makes sense.

Quoted 17 lines

.github/workflows/main.yml +3 -1

index cf341d74db..85cfedf5b0 100644
@@ -420,7 +420,9 @@ jobs:
       CI_JOB_IMAGE: ${{matrix.vector.image}}
       CUSTOM_PATH: /custom
     runs-on: ubuntu-latest
-    container: ${{matrix.vector.image}}
+    container:
+      image: ${{ matrix.vector.image }}
+      options: ${{ github.repository_visibility == 'private' && '--pids-limit 16384 --ulimit nproc=16384:16384 --ulimit nofile=32768:32768' || '' }}
     steps:
     - name: prepare libc6 for actions
       if: matrix.vector.jobname == 'linux32'

base-commit: e9019fcafe0040228b8631c30f97ae1adb61bcdc

Johannes Schindelin

2026-07-04 08:47 UTC #2 lore raw

Hi Junio,

Quoted 8 lines · Junio C Hamano

"Johannes Schindelin via GitGitGadget" <[email protected]>
Quoted 4 lines · writes:
The underlying reason seems to be a substantial difference in the hosted runners that execute these Dockerized jobs: forcing the PID limit of the container to a high number lets the jobs pass, even when running the complete matrix of all 13 Dockerized jobs concurrently.

Quoted 4 lines

Is the "reduce" in the title accurate? The above description tells me that what you did was to "raise" the PID limit (i.e., forcing the PID limit to a high number), presumably because the default PID limit is way too low for the tests to pass?

You are right; The subject is wrong. The patch raises the limit from the hosted-runner default to 16384. The subject is a left-over from a hypothesis that my experiments refuted.

v2 will retitle to "ci(dockerized): raise the PID limit for private repositories". No code change: 16k remains the sweet spot between the failures we saw at 8k and the slow runs at 64k.

Ciao,
Johannes

Johannes Schindelin via GitGitGadget

author

2026-07-04 08:52 UTC #3 lore raw

PATCH v2 1/1 ci(dockerized): raise the PID limit for private repositories

In reply to Johannes Schindelin via GitGitGadget