zombie process found on docker container.

[12019]

to make this tool better , that per my test for the docker container.

latest: Pulled from ncarlier/webhookd

1, put the "long.sh" which collected in issue#36 into scripts directory
"
#!/bin/bash

echo "Starting long script..."
for i in {1..20}; do
sleep 1
echo "running ${i} ..."
done
echo "Long script end"
exit 0
"

2,run the docker command,

docker run -d --name=webhookd
-v ${PWD}/scripts:/var/opt/webhookd/scripts
-p 63008:8080
ncarlier/webhookd
webhookd --scripts=/var/opt/webhookd/scripts

3, curl it at docker host
webhookd$ curl localhost:63008/long
data: Starting long script...
data: running 1 ...
data: running 2 ...
data: running 3 ...
data: running 4 ...
data: running 5 ...
data: running 6 ...
data: running 7 ...
data: running 8 ...
data: running 9 ...
data: error: signal: killed <<<< this should expect that killed by timeout default 10s.
4,login into container at docker host.
webhookd$ docker exec -it webhookd bash
bash-5.1# ps
PID USER TIME COMMAND
1 root 0:00 webhookd --scripts=/var/opt/webhookd/scripts
22 root 0:00 [sleep] <<<< this is zombie process.
23 root 0:00 bash
27 root 0:00 ps

[12019]

it seems that run webhookd as pid 1 in container will cause these zombie process when shell scripts killed by timeout.

hope this can help.

[12019]

the issue fixed by running the container by add "--init"

docker run -d --init --name=webhookd
-v ${PWD}/scripts:/var/opt/webhookd/scripts
-p 8080:8080
ncarlier/webhookd
webhookd --scripts=/var/opt/webhookd/scripts

https://docs.docker.com/config/containers/multi-service_container/

"The container’s main process is responsible for managing all processes that it starts. In some cases, the main process isn’t well-designed, and doesn’t handle “reaping” (stopping) child processes gracefully when the container exits. If your process falls into this category, you can use the --init option when you run the container. The --init flag inserts a tiny init-process into the container as the main process, and handles reaping of all processes when the container exits. Handling such processes this way is superior to using a full-fledged init process such as sysvinit, upstart, or systemd to handle process lifecycle within your container."

[ncarlier]

Hi, thanks a lot for this issue and the tips. I don't see any other way to handle this properly. Perhaps use a process control system like supervisord to avoid this.