-
Notifications
You must be signed in to change notification settings - Fork 0
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-svscan/finish unable to run due to bad permissions #14
Comments
Ignore the "IP address for readsb cannot be resolved". I've fixed that locally, but what I'm reporting is the inability of the s6-svscan/crash to run.
|
What are you running this on? Are you mapping any additional volumes? |
Here's my YML for the docker service:
|
Here are the logs:
|
This is very strange. We normally allow Docker/Docker-Compose to run its own network setup, but that doesn’t appear to be the issue here. One of the tasks of s6 is to copy the run scripts from their services directory into its own runtime directory, ensure that the execution permissions are set, and then execute them. This appears to work fine for the startup processes in cont-init.d, but not for the runtime services in /etc/services.d/xxxxx/run Is there anything non-standard on the host machine you run this on? Normal, Debian based machine (Ubuntu, RaspOS, etc)? Normal host machine file system (ext4 with normal permissions, etc)? And you aren’t using selinux, are you? One thing you can try is to verify the permissions are propagated correctly. See example from my SkySquitter container, all these
|
Host is a Raspberry Pi 4B running Ubuntu Server 22.04 LTS aarch64.
|
|
Yeah this looks all perfectly normal. You’re using the same version Linux and the same hardware I’m running this on. I’ve done some googling on the error, and all I come across for your issue is that it could be related to the permissions of the process that runs Docker in Linux, for example in SeLinux. But that’s obviously not the case for you. You’re also not out of disk space. I assume you’re not out of RAM TBH I’m a bit at a loss here… |
Plenty of memory left over...
Not sure if it's related, but I came across a thread where others had similar run permission issues. There were a few suggestions for fixing it. One was to use some s6 "patches", essentially link and permission overrides that are in a tar file that can be extracted during build to fix the issue. Other suggestions were to change the name of the entrypoint file, and to change the tmpfs mount options. Maybe these will be of help? |
Can you try mounting your /run directory in tmpfs explicitly with exec permissions? For example:
(Several of the parameters are probably not needed but won’t hurt either, I copied it from my own setup) |
Before seeing your latest reply, here's what I tried, and the result:
Logs output:
This particular part from the above appears to have failed:
|
So it seems the touch command fails because the directory doesn't exist.
|
The text was updated successfully, but these errors were encountered: