s6-linux-init: warning: parent wrote to fd 3!

[frankgreco]

Before trying to minimally repro, I want to just see if there's anything I'm missing. I'm seeing s6-linux-init: warning: parent wrote to fd 3! at the very startup. I'm using s6-rc with this structure

❯ tree s6-rc.d
s6-rc.d
├── orchestrator
│   ├── dependencies.d
│   │   └── base
│   ├── finish
│   ├── run
│   └── type
├── user
│   └── contents.d
│       ├── orchestrator
│       ├── workergo
│       ├── workerjs
│       └── workerpy
├── workergo
│   ├── dependencies.d
│   │   └── base
│   ├── finish
│   ├── run
│   └── type
├── workerjs
│   ├── dependencies.d
│   │   └── base
│   ├── finish
│   ├── run
│   └── type
└── workerpy
    ├── dependencies.d
    │   └── base
    ├── finish
    ├── run
    └── type

11 directories, 20 files

I'm not sure if it's related but I am performing an echo in every run script 👇🏼

#!/command/with-contenv sh

echo "{\"level\":\"info\",\"ts\":$(date +%s),\"msg\":\"starting component orchestrator\",\"component\":\"s6\"}"
/app/orchestrator/bin

[skarnet]

It has nothing to do with your echo lines in run scripts.

What is happening is that your container manager is starting your container not only with stdin, stdout and stderr open, but also file descriptor 3, and is writing to descriptor 3 for some reason. This is weird, so s6-linux-init warns about it.

Some container managers (Docker) start their container with a pipe open to fd 3 as a synchronization mechanism: the pipe gets closed when Docker is actually ready to provide the container with what it needs (filesystems, etc.), so when you're starting a container, if fd 3 is open, it's good practice to wait until you read EOF on it before continuing, this ensures there will be no race condition when acquiring resources. That's what s6-linux-init does. But the container manager isn't supposed to write anything to fd 3, it's only supposed to close its end of the pipe when it's ready. Here, your container manager is writing. It should not.

Check your container manager's configuration, its documentation, find out why it's writing to fd 3 of the container it launches, and what that's supposed to mean. If there's new stuff, if it transmits information via fd 3, I might have to add support for it in s6-linux-init, or at least remove that pesky warning.

[frankgreco]

@skarnet Thank you for the detailed response. I am using Docker as my container manager. I think what you're suggesting is that I create some new oneshot service that waits for fd3 to close and make my other s6-rc services dependent on it so that it waits until it starts.

[skarnet]

I'm not suggesting that at all: the waiting is done by s6-linux-init automatically, you have nothing to do on that front.

What I would like you to do, however, is help me understand what's going on. Why is Docker writing to the container init's fd 3, and what is it writing? A cursory search isn't turning up anything.

If you don't want to do this, that's fine; as long as your container is working properly, you can safely ignore the warning, there's nothing to fix on your side. The work to do here is for me, because if it's something Docker is going to keep doing in the future, I'd rather not stress other users with a constant warning.

[komapa]

I do see the same problem and I am using colima on macOS.

❯ docker info
Client: Docker Engine - Community
 Version:    25.0.2
 Context:    colima
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2-desktop.5
    Path:     /usr/local/lib/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.23.0-desktop.1
    Path:     /usr/local/lib/docker/cli-plugins/docker-compose
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.20
    Path:     /usr/local/lib/docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v0.1.0-beta.9
    Path:     /usr/local/lib/docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-sbom
  scan: Docker Scan (Docker Inc.)
    Version:  v0.26.0
    Path:     /usr/local/lib/docker/cli-plugins/docker-scan
  scout: Docker Scout (Docker Inc.)
    Version:  v1.0.9
    Path:     /usr/local/lib/docker/cli-plugins/docker-scout

Server:
 Containers: 105
  Running: 5
  Paused: 0
  Stopped: 100
 Images: 100
 Server Version: 24.0.7
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
 runc version: v1.1.10-0-g18a0cb0
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.5.0-15-generic
 Operating System: Ubuntu 23.10
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 7.739GiB
 Name: colima
 ID: d57e8a02-11fe-480b-96dd-918a706c3ad2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

❯ colima list
PROFILE    STATUS     ARCH       CPUS    MEMORY    DISK      RUNTIME    ADDRESS
default    Running    aarch64    10      8GiB      100GiB    docker

❯ colima status
INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/kirilangov/.colima/default/docker.sock

I can provide more information if needed.

[skarnet]

Thank you. It looks like a change made in a recent version of Docker. I'll have a look.

[komapa]

Also, I thought changing S6_VERBOSITY=0 will silence this because it shows up as warning in the logs but it did not.

[skarnet]

S6_VERBOSITY has no impact on things that happen that early. Don't try to silence that warning, it is valid.

[frankgreco]

@skarnet Were you able to verify that this happens in the base Docker case? I believe that's the case. If so, would we be able to hide that log?

[skarnet]

Not yet, sorry. I'll keep you informed. For now, please just ignore the warning, if everything is working as intended.

[Anghille]

I can confirm that I got the same warning here: running docker on macOs m1 (local dev before deploying on linux), base file Fedora:40, using the latest (3.2.0.2) s6-overlays, with multiple services (oneshot and longrun).