Open glennpratt opened 4 months ago
hmmm...i was not able to reproduce this problem. here are the steps i tried:
tilt up -f custom_deploy.Tiltfile
test_update
a bunch of timesps aux wwwf
start.sh
, as i expected.when i poked around in the entr
repo, i found this issue - https://github.com/eradman/entr/pull/38 - which seems to indicate to me that it's at least expected for entr to kill the process
I'm running into a sort of similar situation where a process can be left around hanging as a zombie process.
I tried to create a reproducable testcase and came up with something which creates a zombie process. This is not supposed to be a useful or optimized usecase for anything, just commands put together to create a zombie process.
diff --git a/restart_process/test/Dockerfile.test b/restart_process/test/Dockerfile.test
index cfbeb9f..89e11d3 100644
--- a/restart_process/test/Dockerfile.test
+++ b/restart_process/test/Dockerfile.test
@@ -1,5 +1,7 @@
FROM alpine
+RUN apk add nginx
+
RUN echo 0 > restart_count.txt
ADD start.sh /
diff --git a/restart_process/test/start.sh b/restart_process/test/start.sh
index c9bc981..6277158 100755
--- a/restart_process/test/start.sh
+++ b/restart_process/test/start.sh
@@ -12,8 +12,13 @@ handle_sigterm() {
trap handle_sigterm SIGTERM
-while true
-do
- echo running
- sleep 5
+while pgrep -f nginx >/dev/null ; do
+ echo "waiting for nginx to shut down"
+ set +e
+ pkill -f nginx
+ set -e
+ sleep 3
done
+nginx
+
+tail -F /var/log/nginx/*
tilt up -f custom_deploy.Tiltfile
Going into the container and running ps faux
:
ps faux
PID USER TIME COMMAND
1 root 0:00 /tilt-restart-wrapper --watch_file=/tmp/.restart-proc sh -c /start.sh
17 root 0:00 /entr -rz sh -c /start.sh
25 root 0:00 [nginx]
62 root 0:00 {start.sh} /bin/sh /start.sh
78 root 0:00 sleep 3
79 root 0:00 sh
85 root 0:00 ps faux
The pid 25 is there as a zombie.
I assume the issue is tilt-restart-wrapper not reaping zombies, which should be a job of a process running as PID 1.
Seems like it might need a minimal init (tini, dumb-init, etc).
I noticed this because entr also doesn't reliably kill the process before starting a new one... perhaps this is because of
sh
, I'm not sure. That's a different issue.