Skip to content

Update container entrypoint to use `dumb-init` to avoid zombie processes

What does this MR do?

This PR fixes the issue of this Helm chart where the container's entrypoint is not properly overridden. This results in zombie processes. The problem is already addressed in the image itself by installing dumb-init. As this chart overrides the entrypoint, we should and actually must use dumb-init; otherwise, one will see more of

...
 114435 ?        Ssl   11:48  \_ gitlab-runner run --user=gitlab-runner --working-directory=/home/gitlab-runner
1424583 ?        Z      0:00      \_ [pgrep] <defunct>
 146334 ?        Z      0:00      \_ [pgrep] <defunct>
1140323 ?        Z      0:00      \_ [pgrep] <defunct>
1275732 ?        Z      0:00      \_ [pgrep] <defunct>
3578414 ?        Z      0:00      \_ [pgrep] <defunct>
3595662 ?        Z      0:00      \_ [pgrep] <defunct>
3811437 ?        Z      0:00      \_ [pgrep] <defunct>
1575551 ?        Z      0:00      \_ [pgrep] <defunct>
1065715 ?        Z      0:00      \_ [pgrep] <defunct>
 754596 ?        Z      0:00      \_ [pgrep] <defunct>
...

when executing ps afx.

Why was this MR needed?

Zombie processes should be awaited properly. Otherwise, this problem is not solved.

What's the best way to test this MR?

Testing is not needed as this makes use of the container's actual defaults, which are tested in the original repository of the runner.

What are the relevant issue numbers?

  1. gitlab-org/gitlab-runner!180 (merged)
  2. gitlab-org/gitlab-runner#1366 (closed)

I didn't open an additional issue, but there already is a PR about this, but this PR has stalled. I figured I'd do it myself then.

Closes !201 (closed)

Edited by Georg Lauterbach

Merge request reports