Upon restart some stacks never start #647
Comments
I am not sure I understand: the docker socket is provided by docker (and the OS) and Traefik just makes use of it. |
|
Might be the wrong status bug, which I still don't know how to 100% reproduce it. They maybe actually up. |
|
The apps themselves are NOT up. Take the arr's stack above where some say started and some are not. The overseerr app is up however sonarr / radarr is not and returns a 404 when i attempt to access. I wish i could stack rank or priority order start the compose files at a minimum (assuming i couldn't depend on another app in a diff stack) to buy time for the picky stacks such as my arr's stack. With respect to the docker sock. from a security perspective, the docker sock is not directly exposed and instead is exposed through the socket-proxy service seen in the traefik stack. I tried making other stacks depend on the status of another however that doesn't work because you can't make one compose depend on another (from what i gathered) |
|
I'm having the same issue , but I am new to docker so it may be that. |
|
same for me in that if i restart it manually it works. It just never fully loads on a server restart. |
|
I created a new ProxMox LXC , installed Docker - just the command line version this time. |
|
Glad your issue is resolved however, mine is not and i have no indication why those containers won't start without manual intervention |
|
I pretty much have the same issue, some containers don't start after a reboot, but only about 20% of the time. |
|
I'm having the same issue as @liquidfrollo. Any containers within Dockge don't automatically start when my server is rebooted. They're all in individual stacks as well, with ARR apps pointing back to Gluetun for VPN/Network. (Understand that this is probably not the ideal configuration) |
|
I'm wondering if it is quietly failing because there is no health check / dependency ability between stacks? Just speculating as i'm unsure why it wouldn't just come up as healthy. Also curious if we could set a priority of compose start order if it would resolve it. For instance if i start / wait for traefik stack and authentik stack (reverse proxy + socket security service, and authentication service) would everything else start without issue? |
Yeah, it seemed to me that when the container was destroyed and then recreated, it was given another ID or something. I also had this when certain stacks were updated through Dockge. I had the issue before and couldn't fix it that time and has to recreate the stack again and it worked no problem. I fixed my issues by putting all of GlueTun and the *arr's into a single stack and using the Depends_on and healthcheck commands to make all of the *arrs wait until the Gluetun service was healthy before starting. |
|
curiously enough gluetun / qbit is also a stack that doesn't start! Same
with plex which doesn't have a dependency on any of them.
…On Wed, Jan 15, 2025 at 1:08 PM N0rga ***@***.***> wrote:
I'm wondering if it is quietly failing because there is no health check /
dependency ability between stacks? Just speculating as i'm unsure why it
wouldn't just come up as healthy. Also curious if we could set a priority
of compose start order if it would resolve it. For instance if i start /
wait for traefik stack and authentik stack (reverse proxy + socket security
service, and authentication service) would everything else start without
issue?
Yeah, it seemed to me that when the container was destroyed and then
recreated, it was given another ID or something. I also had this when
certain stacks were updated through Dockge.
As they were using the Gluetun stack as the network mode, they for some
reason couldn't find it any more, and each time trying to start said
container "*whole string of numbers and letter*" could not be found or
doesn't exist.
I had the issue before and couldn't fix it that time and has to recreate
the stack again and it worked no problem.
I fixed my issues by putting all of GlueTun and the *arr's into a single
stack and using the Depends_on and healthcheck commands to make all of the
*arrs wait until the Gluetun service was healthy before starting.
—
Reply to this email directly, view it on GitHub
<#647 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADNDGOUNS3FYLS35ZWI4IYT2K253XAVCNFSM6AAAAABQPGVBBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTHAZTKMJTGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
and others
🛡️ Security Policy
Description
When the host is restarted (Truenas scale running jlmkr / dockge) some stacks start but others show exited or not up completely. If i go into the stacks manually and click start they start without issue.
👟 Reproduction steps
Restart the host
👀 Expected behavior
all stacks should start without issue
😓 Actual Behavior
some stacks do not start. Speculation that the docker sock exposed by traefik is not available and is required by other stacks, no way to do "depends on" between stacks.
Dockge Version
1.4.2
💻 Operating System and Arch
Truenas Scale (24.0.4.2.3) / Jlmkr running - Debian release 12 codename bookworm
🌐 Browser
Firefox - most current
🐋 Docker Version
20.10.24+dfsg1
🟩 NodeJS Version
No response
📝 Relevant log output
No response
The text was updated successfully, but these errors were encountered: