v2.8.3 — a failed dependent says why, and shutdown timeouts follow your setting
Both of these come from @famewolf, who lost ten days to the first one.
A failed dependent now says why, and says it first
One of the ten containers behind his Gluetun sidecar failed to be recreated on 6 August, and every time after. His whole arr stack depends on it for searches, so it sat broken for ten days while the notification said:
🔁 gluetun dependents: 9 ok (booksarr, easynewsindexer, flaresolverr,
lidarr, prowlarr, qbittorrent, radarr, readarr, sonarr), failed 1
(gluetun-nzbhydra2)
Two failures of ours in that one line.
The reason was thrown away. The recreate returns one; the caller printed it to the container's own log and put only the name in the message. So it could tell him something was wrong and never what, and the single line that would have let him fix it sat in a place he had no reason to look. That is why this took ten days rather than ten minutes.
And the failure was a suffix on good news. Nine ticks, then the bad news at the end of the same sentence. He missed it repeatedly and asked for it "in bold and in red". He is right. It now looks like this:
❌ gluetun dependents: 1 FAILED
• gluetun-nzbhydra2: name in use by container 0e1f2a
🔁 9 ok (booksarr, easynewsindexer, …)
Failures lead, on their own lines, each carrying its reason. Successes follow. A run where nothing failed is unchanged.
Shutdown timeouts follow your setting instead of a constant
docker kill, docker rm -f and rename were fixed at 15 seconds, which is not enough for a container that is slow to die. He hit it repeatedly on ollama with a model loaded in VRAM, and on byparr and metube.
They follow DOCKER_STOP_TIMEOUT now — max(30, that) — so raising the one value somebody with slow containers has already raised covers the whole shutdown path, rather than only its first step. The default rises from 15 to 60 seconds.
Nothing to do on upgrade. If you have containers that take a while to stop, DOCKER_STOP_TIMEOUT is the knob.
