almighty7lurch

i think i’m onto something. i’ve posted an update in the support thread for the container template: https://forums.unraid.net/topic/190366-booklore-template-support-thread/page/2/#findComment-1606049

basically... the upstream application’s dockerfile invokes a wrapper script (https://github.com/booklore-app/booklore/blob/master/Dockerfile#L64), which runs as PID 1 inside the container. such a wrapper script -- if not written properly -- can completely prevent the container from processing signals sent to it from the kernel. here’s one of the several blogs and forum posts i wound up on while trying to diagnose this issue: https://petermalmgren.com/signal-handling-docker/

its author suggested adding --init to the container’s startup parameters. i had tried this earlier on in my troubleshooting, and i’m guess it was “fixed” then but for some reason, i didn’t realize at the time that it was the solution, so i mistakenly moved past it and kept troubleshooting. after rediscovering the info about docker PID 1 signal handling, i tried adding --init again and am now quite confident that the issue is solved (at least, for me). ps run from inside the container supports this:

PID USER TIME COMMAND 1 root 0:00 /sbin/docker-init -- /__cacert_entrypoint.sh /start.sh 7 root 0:00 {start.sh} /bin/sh /start.sh 11 root 0:00 nginx: master process nginx -g daemon off; 12 root 0:15 java -jar /app/app.jar 13 nginx 0:00 nginx: worker process 51 root 0:00 sh 58 root 0:00 psand from the docker documentation (https://docs.docker.com/reference/cli/docker/container/run/#init):
anyway, i’ve marked this as the solution to this post, and i hope this information helps others who may encounter a container that’s misbehaving. the real solution is to get an application maintainer to fix their wrapper script, if they’re using one. for booklore, i’ve opened an issue on the project’s github repo.