Gvisor cannot open a FIFO file that already exists in the image for reading and writing.

[xdxd1234-bit]

Description

When running GitLab https://github.com/web-arena-x/webarena/blob/main/environment_docker/README.md#gitlab-website in a container with gVisor runtime, the container startup process hangs and eventually fails.Investigation shows that GitLab processes are stuck on FIFO operations during initialization.

After running gitlab-ctl status, you can see below

by using strace , I found:

stat supervise/ok, the file type is fifo :

Steps to reproduce

1. Write a mini Dockerfile
   FROM ubuntu:20.04
RUN apt-get update && apt-get install -y strace
RUN mkfifo /test-fifo
RUN chmod 666 /test-fifo
WORKDIR /
CMD ["/bin/bash"]

2. docker build -t fifo-test .

3. mkdir -p /tmp/fifo-test

4. touch minimal-test.sh

5. write script below to minimal-test.sh:

echo "=== simple FIFO test ==="

echo  "FIFO status:"
ls -la /test-fifo

echo ""
echo "step 1: start reader（5 second timeout）"
timeout 5 cat /test-fifo &
READER_PID=$!

echo "Step 2: Waiting 1 second"
sleep 1

echo "step 3: Writing data"
echo "Test Message" > /test-fifo

echo "Step 4: Waiting for reader to complete"
wait $READER_PID
echo "Reader exit code: $?"

echo "Test completed"

6. docker run --rm --runtime=runsc -v /tmp/fifo-test:/scripts fifo-test bash /scripts/minimal-test.sh

the output is:

runsc version

runsc version release-20260112.0-19-g509480e92861
spec: 1.1.0-rc.1

docker version (if using docker)

docker version
Client: Docker Engine - Community
 Version:           26.1.3
 API version:       1.45
 Go version:        go1.21.10
 Git commit:        b72abbb
 Built:             Thu May 16 08:34:39 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.3
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.10
  Git commit:       8e96db1
  Built:            Thu May 16 08:33:34 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.32
  GitCommit:        8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

uname

No response

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

"runsc": {
            "path": "/usr/local/bin/runsc",
            "runtimeArgs": [
                "--platform=systrap",
                "--network=host",
                "--allow-flag-override=true",
                "--net-raw",
                "--allow-suid",
                "--file-access=exclusive",
                "--file-access-mounts=exclusive",
                "--debug",
                "--host-fifo=open",
                "--debug-log=/tmp/runsc-debug/"
            ]
        },

[dohaelsawy]

Hello @xdxd1234-bit , is anyone working on this issue? If not, I would love to give it a shot.

[milantracy]

@dohaelsawy let me know if you need any help, I did some experiment where I saw EOPNOTSUPP is returned from

gvisor/pkg/sentry/syscalls/linux/sys_xattr.go

Line 98 in 1bafeb9

func getxattr(t *kernel.Task, args arch.SyscallArguments, shouldFollowFinalSymlink shouldFollowFinalSymlink) (uintptr, *kernel.SyscallControl, error) {

[xdxd1234-bit]

Hello~@dohaelsawy do you have any idea about this issue?

[dohaelsawy]

Hi @xdxd1234-bit, I'm still in the exploration phase to get more familiar with the issue.