fix(geo-logcursor): set geo_log_cursor to PID 1
What does this MR do?
What
- Update the
CMD
to be inexec form
- Use
exec
inside of theprocess-wrapper
so thatgeo_log_cursor
is not a child process and takes the PID of theprocess-wrapper
which is PID 1 to recive the termination signals.
Process tree before:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
git 10 0.0 0.0 8592 3184 ? Rs 06:51 0:00 ps faux
git 1 1.0 0.0 2420 520 ? Ss 06:51 0:00 /bin/sh -c /scripts/process-wrapper
git 8 0.0 0.0 5728 3192 ? S 06:51 0:00 /bin/bash /scripts/process-wrapper
git 9 100 0.7 109964 28220 ? R 06:51 0:03 \_ ruby /srv/gitlab/ee/bin/geo_log_cursor --stdout-logging
Process tree after:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
git 9 0.0 0.0 8592 3160 ? Rs 06:50 0:00 ps faux
git 1 55.5 0.5 104784 23692 ? Rs 06:50 0:01 ruby /srv/gitlab/ee/bin/geo_log_cursor --stdout-logging
Why
When we use CMD command param1 param2
(shell form) PID 1 is /bin/sh -c
so termination signals are sent to the container such as SIGTERM it is sent
to /bin/sh
. This could lead to ungraceful termination of the process because
it never gets the signal it expects to start graceful termination. Using
CMD ["executable","param1","param2"]
(exec form, this is the preferred
form) will set the executable of CMD
as PID 1 which will in turn
make signal handling work as expected.
Related issues
gitlab-org/charts/gitlab#3249 (closed)
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Integration tests added to GitLab QA -
The impact any change in container size has should be evaluated
Edited by Jason Plum