i’ve spent a good deal of time searching the web, posting in the Unraid discord server, and so on… and i haven’t found any conclusive answers so far. i’ve come across two forum topics that seem to be somewhat related but not exactly:

https://forums.unraid.net/topic/171402-docker-updates-fail/

https://forums.unraid.net/topic/146853-docker-containers-not-updating/

i have one container, Booklore (the official Unraid package, from the CA repository), that will not stop cleanly. not when using the Stop button in the web GUI (either explicitly/manually or by updating the container), and not when issuing a docker stop command in the terminal. when i stop it via the web GUI, the container’s status icon animates the spinning “stopping” icon, and then eventually i get a modal that just says “Execution error” and gives me an OK button:

i see no relevant errors or other messages in docker logs or in /var/log/syslog.

i’ve tried upping the docker stop timeout from the default 30 seconds to 90 seconds, all the way up to 300 seconds, but no matter what, that timeout is eventually exceeded and the system winds up sending a SIGKILL to the container. i’ve deleted the container, the image, the appdata directory and then subsequently reinstalled (i’ve done this a few times) but the issue persists.

the other day, i added --init to the container’s Extra Parameters field after reading it as a possible solution to other issues, but now when i issue a stop to it, it shuts down almost instantaneously — like... too fast, in under a second, where every other container on this server seems to shut down more gracefully, taking a few seconds to exit and clean up.

something seems really wrong here but i have not been able to figure it out. i can test and provide logs.

Best bet is to look for the support thread for that container

17 hours ago, JorgeB said:

Best bet is to look for the support thread for that container

in effect, i’ve already done so — i posted a comment explaining this issue in the github issue where the unraid template was created (https://github.com/booklore-app/booklore/issues/299#issuecomment-3294623660), and the author (and several other users) replied that they do not have this same issue. one of my goals with this post is to ask for assistance in troubleshooting the issue, because i’ve run out of ideas.

Edited January 18Jan 18 by almighty7lurch

Did you try with a new Docker image, or even using a new trial flash drive with a new install to rule out any other config issues?

yeah, several times now i’ve entirely deleted the container and the image, along with the appdata directory, then subsequently reinstalled it from scratch. i haven’t done a full, truly “fresh install” on a new flash drive because i think that would be far too many variables (containers, drives, etc) changing at once for it to be enlightening.

one of the things that i’m struggling with is that i can’t seem to find good docker logs in unraid. using docker system events, i don’t get much beyond the stop request, and the eventual kill signal (attached as booklore-log.txt). in the webui, Tools > Log Viewer (New) > docker.log is always empty, and i’ve never been able to find it on the filesystem.

i do intend to replace the flash drive this weekend with a brand-new one, just for giggles… but i’ve installed, removed, and replaced numerous other containers since i first started experiencing this issue and it’s consistently only ever booklore. i would expect that if the flash drive is truly corrupted, i would be seeing far more widespread and “consistently inconsistent” issues than simply trying to stop one particular container. so it feels like something’s up with the unraid dockerman system.

i think if it was an issue with booklore itself, reports of this issue would be more widespread on the booklore github page, etc. it’s been consistently a problem for like the past 20 versions i’ve updated through… it makes no sense to me. at this point, there’s just not enough data to point the finger at either some unraid or booklore, so i feel like i really want to keep troubleshooting and working on diagnostics.

booklore-log.txt

My suggestion would still be to try a new install. You can try a different flash drive with a trial just to confirm the container actually installs on your server with a clean install; that would confirm if it's a config/settings issue with the current one.

the problem isn't container installation -- this container installs with no issue on my existing flash drive. it's just that Unraid docker subsystem (dockerman, i think it's called?) can't stop the running container properly. however, i did perform a completely fresh, brand-new installation of Unraid 7.2.3 on a completely fresh, brand-new samsung flash drive, and then restored my current Unraid install from a backup. this would rule out some freak NAND issue with the old flash drive. with the new flash drive, the issue still occurs. then, i decided to completely delete the docker.img file and recreate it, reinstalling all my docker containers. the issue still persists.

considering that i've repeatedly deleted/purged/reinstalled both the mariadb and booklore containers, images, and appdata dirs, and performed a new Unraid install, and recreated my docker.img file... what "config/settings issue" could remain? i still don't know where Unraid stores its docker logs -- not container logs, which are obvious and easy to find, but docker logs -- because the Log Viewer only ever shows a 0-byte file. what else should i be looking for or deleting or recreating?

Edited February 1Feb 1 by almighty7lurch
add specificity to troubleshooting steps

Attach Diagnostics ZIP to your NEXT post in this thread.

10 hours ago, almighty7lurch said:

i think it's called?) can't stop the running container properly

If that is happening with a single container, it suggests a problem with that specific container; there should be a support thread for it:

diagnostic bundle attached:

exai-diagnostics-20260201-1821.zip

i’ve already asked the unraid container maintainer, who says they do not have the issue i’m having. other users also chimed in to say that they also have not run into this issue. i would just like to be pointed in the right direction for further actionable troubleshooting steps. are there system-level docker logs i can be looking at?

Does it still happen if you boot in SAFE mode?

yes — in safe mode, this container still fails to stop gracefully. if i set the docker stop timeout to (say) 52 seconds, the container will be terminated 52 seconds after hitting “stop” in the web ui. interestingly, the “execution error” modal i provided a screenshot of in my original post no longer appears. i have updated Unraid since the original post. but the SIGKILL still occurs. i’m now also noticing that once the container has been killed, the web ui gives a status of "Exited (137)” which, for docker, seems to indicate an out-of-memory error. problem with that idea is that the server has 32GB of memory, and i’ve never noticed the server’s memory usage going above even 25%. also, doing docker inspect BookLore i get the following State information:

        "State": {
            "Status": "exited",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 0,
            "ExitCode": 137,
            "Error": "",
            "StartedAt": "2026-02-02T23:21:51.011608134Z",
            "FinishedAt": "2026-02-02T23:24:28.129274308Z"
        },

so, it wasn’t actually oom killed. so i think in this case, “137” is actually from the shell. from the bash manpage:

The return value of a simple command is its exit status, or 128+n if the command is terminated by signal n.

137=128+9

i’m super aware this is just one bizarre edge case, from (apparently only) one user… it’s not some widespread, critical bug that demands a ton of urgent attention. but i do believe in being a good internet citizen, and to me part of that is documenting these weird edge cases so that somebody who comes after me may find a fix to their own confusing problem.

i’ll keep trying to track down this issue and will report back any info that seems useful, and i would definitely appreciate further help and ideas on what to try next.

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 ps

and from the docker documentation (https://docs.docker.com/reference/cli/docker/container/run/#init):

You can use the --init flag to indicate that an init process should be used as the PID 1 in the container. Specifying an init process ensures the usual responsibilities of an init system, such as reaping zombie processes, are performed inside the created container.

The default init process used is the first docker-init executable found in the system path of the Docker daemon process. This docker-init binary, included in the default installation, is backed by tini.

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.

Edited February 3Feb 3 by almighty7lurch
expand upon solution, for clarity and posterity