r-Techsupport / hyde

A web editor and CMS for Jekyll/git static sites.
GNU General Public License v3.0
4 stars 2 forks source link

Container does not respond to SIGTERM #27

Closed PipeItToDevNull closed 1 month ago

PipeItToDevNull commented 1 month ago
podman rm -f cms 
WARN[0010] StopSignal SIGTERM failed to stop container cms in 10 seconds, resorting to SIGKILL 
cms
PipeItToDevNull commented 1 month ago

https://github.com/rustdesk/rustdesk-server/issues/36

PipeItToDevNull commented 1 month ago

https://stackoverflow.com/questions/60733727/unable-to-stop-my-docker-container-with-ctrl-c

zleyyij commented 1 month ago

Processes with PID 1 in linux are a little different when it comes to signals - They don't have the default SIGINT/SIGTERM handlers and are immune to SIGKILL (from inside the same namespace/container - yeah, I forgot to mention that hbbr/hbbs in their current containers are immune to SIGKILL from inside, so you can't kill them at all) That's why when a bash script is the PID 1 process, everything works as intended - bash implements it's own, proper signal handlers. I see 2 solutions here, with the first one being the best.  Implement signal handlers for SIGINT and SIGTERM for hbbr and hbbs. You can do the proper cleanup here (call any cleanup functions of dependencies, close used sockets & files, release used resources, etc.) and then exit the program with the exit code of 0. Add an entrypoint script to the container image.  While the second option may be quicker to implement, (since I've basically described the whole solution including the code in this comment) I urge you to implement your own, proper signal handlers, since those should prevent further issues with clean exits.

It looks like this just entails implementing manual SIGINT, SIGTERM, and SIGKILL handlers.

zleyyij commented 1 month ago

Closed with commit 9157241