-
Notifications
You must be signed in to change notification settings - Fork 854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Container is depending on at least one other container. This is not compatible with rolling restarts #1786
Comments
Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏 |
EDIT: This issue does NOT exist on containrrr/watchtower:1.5.3, but it does on containrrr/watchtower:latest. |
Interesting! The problem users had before 1.6.0 were that they could not update containers that depended on gluetun for networking. In v1.6.0, support for updating such containers was added and we now also detect such relationships and treat them as dependencies. I have no idea why this would have worked for you earlier, but the problem right now is that you have rolling updates enabled, which cannot be combined with containers with dependencies (as the proividing containers need to be stopped after, and started before the consuming containers). I think the easiest solution is to just turn off rolling restarts, as it shouldn't be possible to do proper rolling restarts with your configuration (this is why watchtower refuses to do them). |
Hi, |
@Al4ndil it never worked correctly with rolling restarts and dependent containers. What probably worked for you before was ignoring the dependency and hoping it wouldn't break whenever it was updated. |
Same issue here... I've got 200 mails from Watchtower... and continioun do get it every day. Watchtower in restart mode. |
I just noticed that my docker containers hadn't been updated for quite a while. Watchtower is scheduled to run every 24 hours. I noticed in the logs the same error: "containerX is depending on at least one other container. This is not compatible with rolling restarts." |
Same issue... watchtower does not start because it identifies linked containers . How to solve? Does 1.5.3 ignore dependencies? |
BUMP, Im suffering with the same issue |
This just happened to me overnight as well. Over 1,000 emails were sent to me. EDIT: As stated previously, I have disabled rolling restarts to mitigate the issue. Would be nice if it could be left as enabled, and watchtower could go ahead and exclude rolling restarts from occurring on containers that don't support it. |
Describe the bug
As of yesterday, Watchtower is throwing an endless loop of errors about container dependencies related to my media management compose. Nothing has materially changed in this recently - this just started happening randomly. The name of the container in question changes randomly, depending on which ones are running and their start order.
EDIT: This issue does NOT exist on containrrr/watchtower:1.5.3, but it does on containrrr/watchtower:latest.
Steps to reproduce
Here is my WT compose:
Here is my WT .env
Here are snippets of the relevant section of the related compose.
TLDR, each of the media downloaders uses the Gluetun VPN tunnel, to mask traffic.
Note: I have down'd and up'd the container several times. There are no volumes at all, so nothing should be stuck.
Expected behavior
This has always worked before, and is documented to do so, here.
Screenshots
No response
Environment
Your logs
After stopping the SABnzbd container, it just starts complaining about the next one in that stack:
Additional context
No response
The text was updated successfully, but these errors were encountered: