-
-
Notifications
You must be signed in to change notification settings - Fork 39
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
[BUG] "s6-rc-init: fatal: unable to supervise service directories in /run/s6-rc/servicedirs: Broken pipe" when starting container #126
Comments
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid. |
Note: I deployed the following as a test:
This container works correctly. At the end of the day it's not a huge deal, but at least I'm up and running. Seem the container hosted here is hosed maybe? |
Lscr and ghcr endpoints are exactly the same at the moment as lscr points to (forwards to) ghcr. You likely had a malformed image download the first time around. A repull probably fixed it. |
Not the case. I am able to reproduce this on two different host machines. I just tried it again, deleted the stack and images, repulled and redployed, same error. If I delete the stack and images and switch to ghcr.io, it deploys correctly. One machine has never had this deployed and experienced the issue. Either way, I'm moving forward with the ghcr.io, something is either happening in the forwarding process or somewhere else along the line. |
Lscr does not host any images. It's just a forwarding service. It currently forwards to ghcr, which is where the images are downloaded from. |
Ah well, it was just brought to my attention that the ghcr address you used is not our image. So you're comparing apples to oranges |
I'm not sure where the confusion is here lscr.io/linuxserver/tautulli:latest -- Does not work. You indicated that is is just a forwarding service from lscr.io to ghcr.io. You said this was the same above. Now it's not? Now this actually proves that lscr.io/linuxserver/tautulli:latest is the issue. This is what I am indicating is not working. I used ghcr.io/tautulli/tautulli:latest as a test in my reply above and confirmed it works. So if lscr.io/linuxserver/tautulli:latest does not work, wouldn't that indicate there is an issue with lscr.io/linuxserver/tautulli:latest ? What am I missing here? |
If you want to test our image via ghcr.io, do ghcr.io/linuxserver/tautulli:latest instead. |
You're pulling two completely different images so you can't compare them in any meaningful way. Our image is fine and works:
The suggestion is to try |
Ok thanks, this clears up the confusion. I didn't realize there were so many different images. Tested the following: ghcr.io/linuxserver/tautulli:latest = broken pipe I just wanted to bring this to someone attention as I have the same results on multiple different docker hosts, including a machine that I spun up in a VM quickly for testing. I'm not going to worry about it, ghcr.io/tautulli/tautulli:latest is working and I'll just continue to use that. And yes, I was doing new deployments and specifying a different config path each time. Something changed in the last update as everything was working fine, then the container updated and I can no longer deploy it from the three URLs above. Might as well close this if it's working for others here. Maybe something is affecting the image pull in between my host and the server, however, it just seems awfully weird it started happening for this container only... shrug Thanks! |
The image itself is definitely OK. Can you try |
Yep same broken pipe issue.
Going to get a buddy of mine to try and deploy it on his docker host this weekend and see what his results are. I'm willing to bet it'll work for him but if I see the same issue I'll update the thread. Again, if it's working for other people it's something environmental on my end most likely. Thanks again! |
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue is locked due to inactivity |
Is there an existing issue for this?
Current Behavior
I had watchtower update the container automatically and saw that it was not running. I then re-deployed as a stack and still get the same error. This has been working for months with no changes except automatically container upgrades.
I have 15 other containers running without issues with no conflicting ports.
Expected Behavior
Container should start normally.
Steps To Reproduce
Nothing special here. Just simply try to deploy the container. As a test, I deployed on a second docker host, same results.
Environment
CPU architecture
x86-64
Docker creation
Container logs
The text was updated successfully, but these errors were encountered: