-
-
Notifications
You must be signed in to change notification settings - Fork 76
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
S6 v3 broke some of linuxserver.io's images #114
Comments
How can this issue be corrected in baseimage-alpine? Or must it be addressed in the images built from baseimage-alpine? In case it can help, here's why I think this is an issue with linuxserver/docker-baseimage-alpine... linuxserver.io's syslog-ng:3.30.1-r4-ls38 from 08 July works ok and its syslog-ng:3.30.1-r4-ls39 from 22 July fails to start:
In linuxserver/docker-bazarr#94 (comment) @Avamander noted several other places where a common change seems to have caused unexpected errors. @aptalca explained:
Comparing 3.30.1-r4-ls38 to 3.30.1-r4-ls39 in linuxserver/docker-syslog-ng, I did not see changes that should introduce this issue, or a new S6 version: That image's Dockerfile builds from ghcr.io/linuxserver/baseimage-alpine:3.15 where In linuxserver/docker-openssh-server#60 this same impact was addressed by making the root/etc/services.d/SERVICE/log/run file executable. From ☝️ that I gather any linuxserver.io service image built from baseimage-alpine:3.15-f3c1af80-ls17 or later must ensure their root/etc/services.d/SERVICE/log/run are executable. How can this issue be corrected in baseimage-alpine? Or must it be addressed in the images built from baseimage-alpine? /cc #92 |
We're considering adding a recursive chmod. We're not positive that there won't be any negative effects from this. |
linuxserver/docker-syslog-ng#6 should make the image work again. It's not the universal fix at the base image level, but it does solve the problem. We're still contemplating the permanent fix. |
Thank you @nemchik 🙇 Do you mean, like, a recursive chmod that'd run when the container first starts? I think it would be simpler to address this issue in the base image, rather than in each service image. At the same time, I imagine there are benefits to pushing, or asking the community to push, solutions into the service images. The risks of each approach are different, too. |
could be chmod -R +x \ and it would make all downstream images work, but we're debating if this is a safety concern (adding executable bit to everything, as opposed to being more specific about what gets it). |
Any progress on this issue? Most the latest linuxserver Docker images I use are broken because of this. This includes:
|
The issue mentioned here is specific to usage of s6-log. None of the 4 images you listed make use of s6-log, and all 4 are working. |
|
|
ah, whoops. ignore me :) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
bit late but why not use |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
this is now resolved |
Expected Behavior
Running a fresh pull of syslog-ng:3.30.1 should continue running syslog-ng as it had before.
Current Behavior
After moving from syslog-ng:3.30.1-r4-ls38 to syslog-ng:3.30.1-r4-ls39, syslog-ng is unable to run.
Steps to Reproduce
Environment
OS: macOS, Raspberry Pi OS
CPU architecture: x86_64 and arm64
How docker service was installed:
Docker Desktop on macOS; from the repository on Linux
Command used to create docker container (run/create/compose/screenshot)
Docker logs
The text was updated successfully, but these errors were encountered: