docker-baseimage-alpine
docker-baseimage-alpine copied to clipboard
linuxserver
S6 v3 broke some of linuxserver.io's images
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
- Start a container from an affected linuxserver.io image built after https://github.com/linuxserver/docker-baseimage-alpine/pull/93 shipped, for example syslog-ng.
docker run --rm \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Etc/UTC \ lscr.io/linuxserver/syslog-ng:3.30.1-r4-ls39 - Check its logs.
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 run -d --name syslog-ng --rm \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Etc/UTC \
lscr.io/linuxserver/syslog-ng:3.30.1-r4-ls39
Docker logs
% docker logs syslog-ng
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service 00-legacy: starting
s6-rc: info: service 00-legacy successfully started
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/01-envfile
cont-init: info: /etc/cont-init.d/01-envfile exited 0
cont-init: info: running /etc/cont-init.d/01-migrations
[migrations] started
[migrations] no migrations found
cont-init: info: /etc/cont-init.d/01-migrations exited 0
cont-init: info: running /etc/cont-init.d/02-tamper-check
cont-init: info: /etc/cont-init.d/02-tamper-check exited 0
cont-init: info: running /etc/cont-init.d/10-adduser
-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/
Brought to you by linuxserver.io
-------------------------------------
To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid: 1000
User gid: 1000
-------------------------------------
cont-init: info: /etc/cont-init.d/10-adduser exited 0
cont-init: info: running /etc/cont-init.d/50-config
cont-init: info: /etc/cont-init.d/50-config exited 0
cont-init: info: running /etc/cont-init.d/90-custom-folders
cont-init: info: /etc/cont-init.d/90-custom-folders exited 0
cont-init: info: running /etc/cont-init.d/99-custom-files
[custom-init] no custom files found exiting...
cont-init: info: /etc/cont-init.d/99-custom-files exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun syslog-ng (no readiness notification)
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-rc: info: service legacy-services successfully started
s6-rc: info: service 99-ci-service-check: starting
[ls.io-init] done.
s6-rc: info: service 99-ci-service-check successfully started
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
solvaholic@solvaholics-MacBook-Pro-3 pihole % docker logs syslog-ng | pbcopy
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service 00-legacy: starting
s6-rc: info: service 00-legacy successfully started
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/01-envfile
cont-init: info: /etc/cont-init.d/01-envfile exited 0
cont-init: info: running /etc/cont-init.d/01-migrations
cont-init: info: /etc/cont-init.d/01-migrations exited 0
cont-init: info: running /etc/cont-init.d/02-tamper-check
cont-init: info: /etc/cont-init.d/02-tamper-check exited 0
cont-init: info: running /etc/cont-init.d/10-adduser
cont-init: info: /etc/cont-init.d/10-adduser exited 0
cont-init: info: running /etc/cont-init.d/50-config
cont-init: info: /etc/cont-init.d/50-config exited 0
cont-init: info: running /etc/cont-init.d/90-custom-folders
cont-init: info: /etc/cont-init.d/90-custom-folders exited 0
cont-init: info: running /etc/cont-init.d/99-custom-files
cont-init: info: /etc/cont-init.d/99-custom-files exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun syslog-ng (no readiness notification)
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-rc: info: service legacy-services successfully started
s6-rc: info: service 99-ci-service-check: starting
s6-rc: info: service 99-ci-service-check successfully started
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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:
s6-supervise syslog-ng/log (child): fatal: unable to exec run: Permission denied
s6-supervise syslog-ng/log: warning: unable to spawn ./run - waiting 10 seconds
In https://github.com/linuxserver/docker-bazarr/issues/94#issue-1309415342 @Avamander noted several other places where a common change seems to have caused unexpected errors. @aptalca explained:
S6 v2 handled them correctly. S6 v3 expects them marked executable, which our baseimage corrects during init.
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: https://github.com/linuxserver/docker-syslog-ng/compare/3.30.1-r4-ls38...3.30.1-r4-ls39
That image's Dockerfile builds from ghcr.io/linuxserver/baseimage-alpine:3.15 where https://github.com/linuxserver/docker-baseimage-alpine/pull/93 upgraded S6 from v2 to v3 on 10 July.
In https://github.com/linuxserver/docker-openssh-server/pull/60 this same impact was addressed by making the root/etc/services.d/SERVICE/log/run file executable.
From :point_up: 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 https://github.com/linuxserver/docker-baseimage-alpine/issues/92
We're considering adding a recursive chmod. We're not positive that there won't be any negative effects from this.
https://github.com/linuxserver/docker-syslog-ng/pull/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.
We're considering adding a recursive chmod. We're not positive that there won't be any negative effects from this.
Thank you @nemchik :bow: 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.
https://github.com/linuxserver/docker-baseimage-alpine/blob/5f3a505a50dc9ded570f191f042f2ade1b47904e/root/docker-mods#L6 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:
- Sonarr
- Radarr
- sabnzbd
- Heimdall
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.
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/
Brought to you by linuxserver.io
-------------------------------------
To support the app dev(s) visit:
Sonarr: https://sonarr.tv/donate
To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid: 65534
User gid: 65534
-------------------------------------
cont-init: info: /etc/cont-init.d/10-adduser exited 0
cont-init: info: running /etc/cont-init.d/30-config
cont-init: info: /etc/cont-init.d/30-config exited 0
cont-init: info: running /etc/cont-init.d/90-custom-folders
chown: changing ownership of '/config/custom-cont-init.d': Operation not permitted
chown: changing ownership of '/config/custom-services.d': Operation not permitted
cont-init: info: /etc/cont-init.d/90-custom-folders exited 1
cont-init: info: running /etc/cont-init.d/99-custom-scripts
[custom-init] no custom files found exiting...
cont-init: info: /etc/cont-init.d/99-custom-scripts exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-mods: starting
s6-rc: info: service init-mods successfully started
s6-rc: info: service init-mods-package-install: starting
s6-rc: info: service init-mods-package-install successfully started
s6-rc: info: service init-mods-end: starting
s6-rc: info: service init-mods-end successfully started
s6-rc: info: service init-services: starting
s6-rc: info: service init-services successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun sonarr (no readiness notification)
s6-rc: info: service legacy-services successfully started
s6-rc: info: service 99-ci-service-check: starting
[ls.io-init] done.
s6-rc: info: service 99-ci-service-check successfully started
[Info] Bootstrap: Starting Sonarr - /app/sonarr/bin/Sonarr.exe - Version 3.0.9.1549
[Info] AppFolderInfo: Data directory is being overridden to [/config]
[Info] Router: Application mode: Interactive
[Info] MigrationLogger: *** Checking database for required migrations data source=/config/sonarr.db;cache size=-10000;datetimekind=Utc;journal mode=Wal;pooling=True;version=3 ***```
Sonarr is using s6 for me
s6-log, not s6. All our images use s6 for init, a small number also use s6-log for logging and those were impacted by the permissions issue referred to the in original report.
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.
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).
bit late but why not use find /etc/(cont-init.d,services.d...) -name run -exec chmod +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).
bit late but why not use
find /etc/(cont-init.d,services.d...) -name run -exec chmod +x {} \;?
run is not the only filename we need to consider.
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.
