can't change an owner of /dev/stdin: chown /dev/stdin: operation not permitted #8921
Assignees
Comments
|
probably it has been broken by d1f3b45. |
|
@blechschmidt, pls take a look at this. |
|
I am sorry in case my commit introduced this. @fishy, does this issue still occur and could you please provide some more instructions on how to reproduce this? It looks like the log is missing the debug messages (because the I tried to reproduce this, but I was not able to so far. The following works fine for me with multiple versions: # Create the wrapper script
sudo sh -c "echo -e \#\!/bin/bash\\\n\\\n/usr/local/bin/runsc --network host --ignore-cgroups --debug --debug-log \\'/tmp/runsc/runsc.log.%TEST%.%TIMESTAMP%.%COMMAND%\\' \\\"\\\$@\\\" > /usr/local/bin/runsc-podman"
# Make the wrapper executable
sudo chmod +x /usr/local/bin/runsc-podman
# Run podman without root
podman --runtime /usr/local/bin/runsc-podman run --security-opt=label=disable docker.io/library/busybox echo Hello, WorldThis outputs version `20230417.0`version `20230320.0`version `20230214.0`Note that changing gvisor/runsc/sandbox/sandbox.go Lines 1406 to 1426 in 153f021 Thus, failure to change ownership should not result in abnormal termination, which is why I think that the error is not necessarily related to that warning. Notably, the warning is also printed in my run with version 20230214.0.
The log hints at the sandbox process being terminated unexpectedly for some other reason. |
|
from: with: `cat /home/fishy/bin/runsc-podman.sh`#!/bin/bash
exec $(which runsc) --network host --ignore-cgroups --debug --debug-log '/tmp/runsc/runsc.log.%TEST%.%TIMESTAMP%.%COMMAND%' "$@"`cat /tmp/runsc/runsc.log..20230505-101307.162163.create``dpkg -s runsc``dpkg -s podman` |
|
The dockerfile is: https://github.com/reddit/thrift-compiler/blob/main/Dockerfile |
|
I can reproduce this symptom now, but I am not entirely sure whether this is the issue that you are experiencing as well, since I experience it for older versions, too. Depending on what version I am running, the error messages in the boot log differ. Two more questions:
|
`cat /tmp/runsc/runsc.log..20230505-101307.174388.boot`So I'm sure it was broken on And also I no longer have a version that works so I don't have the debug logs. When it works I remove the debug logs from the wrapper because I don't really need all those logs laying around. When it's broken, I just switch to use |
|
Thank you. So this is what causes the boot process to fail: So it does not look to me like this is related to the error while chowning Sorry for having to ask you for logs again, @fishy, but could you please also post the I tried to reproduce the same issue on a Debian machine (Vagrant and DigitalOcean VPS) to be as close as possible to your execution environment, but I am still failing. I observe a different error: Vagrantfile`dpkg -s podman``dpkg -s runsc`OutputLogs |
no
no runsc.log..20230505-101307.171257.gofer |
|
Interestingly, remounting |
|
|
I have a suspicion what the reason might be. Otherwise, if that's not it, I am completely clueless and would first need to figure out why the execution differs on your machine vs. on my machine. Do you have any local podman configuration that might cause a different behavior compared to my fresh machine (as I am on the same kernel)? |
|
ok yes removing But for my use case that arg is essential, and runsc worked before with |
|
I've run into this error message as well. To reproduce:
This then comes up in the log: Unlike @fishy, adding |
|
Any new infos here?
|
For me, a bisection indicates that 6b31775 introduced this error. Adding I am not sure if this is the same issue that @fishy is experiencing though (which I still cannot reproduce), since that commit has been published after the initial issue. |
|
Regarding breakage due to directfs: Maybe there was a Linux bug related to userns that was fixed? |
|
@blechschmidt Could you try out the next patch? |
|
With this patch it works for me on |
|
The problem here is that such flags can't be cleared and it doesn't depend on the kernel version. This behavior was introduced a long time ago. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
so I think there's a regression in a recent change?
Originally posted by @fishy in #311 (comment)
The text was updated successfully, but these errors were encountered: