Re: execline's pipeline (and forbacktickx) with closed stdin

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sun, 10 May 2015 15:14:50 -0300

Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
>
> Did you really manage to umount /dev (maybe) and mount a tmpfs
> over it (for sure) with fds still open to the old /dev ? Without
> an EBUSY error ? If it's the case, and you're using Linux, then the
> kernel's behaviour changed.

Yeah, it's Linux. A Gentoo virtual machine with kernel version 3.14
(plus Gentoo patches).

It has sysvinit + OpenRC, one of the two officialy supported
configurations (the other one being systemd), and I tried to replace
it with s6 and keep OpenRC for oneshot initializations tasks, since,
well, they are already written :) Long-lived processes have an actual
servicedir in process 1 s6-svscan's scandir, OpenRC would otherwise
launch them unsupervised.

I mostly followed the example init scripts, but I did deviate, among
other things to delegate tasks to OpenRC (as a bundle of oneshot
services in s6-rc terminology, hehe). And now that you remind me they
were originally there, I don't have the fdclose 1 and fdclose 2 in
stage 1 either. I wanted the stage 2 init to have open FDs to
/dev/console, to show OpenRC's output.

The /dev handling is taken care of by an OpenRC-provided oneshot
service in its sysinit runlevel, called "devfs". It mounts a devtmpfs
(or tmpfs, depending on kernel configuration) on /dev, and creates
some essential device nodes. The rest is left to an udev daemon. So
the kernel needs either CONFIG_DEVTMPFS=y (Gentoo's default) or
CONFIG_TMPFS=y. The devfs service does the equivalent of a "mount -t
devtmps dev /dev", or a "mount -t devtmps -o remount dev /dev" if
there is a filesystem already mounted at /dev. No kernel complaints
when sysvinit is process 1 (I don't know what it does with its open
FDs), no kernel complaints with the custom stage 1 init having devfs
start with open FDs to /dev/console and /dev/null.

There is no unmounting /dev (maybe that's specifically what would
trigger an EBUSY?). The kernel has CONFIG_DEVTMPFS_MOUNT=n, so no
devtmpfs is mounted after the rootfs. And when I boot with
init=/bin/bash, "mount" shows nothing but / and a manually mounted
/proc. However, /dev is not empty. I don't know where the device nodes
came from, but they are there. I didn't create them, maybe they were
put in there during Gentoo's installation, I don't know. I fact, the
after boot /dev looks quite different (and I do see a devtmpfs
mounted). A "mount --bind / /tmp" shows me the original boot time
/dev, so I suppose the root FS has actual static device nodes.

The bottom line is, I'm not entirely sure what magic is involved, but
everyting worked :)

s6-svscan-+-VBoxClient---{SHCLIP}
          |-VBoxClient---{X11 monitor}
          |-VBoxClient---{Host events}
          |-VBoxClient-+-{HGCM-NOTIFY}
          | `-{X11-NOTIFY}
          |-dbus-daemon
          |-dbus-launch
          |-2*[s6-supervise]
          |-8*[s6-supervise---s6-log]
          |-s6-supervise---systemd-udevd
          |-5*[s6-supervise---agetty]
          |-s6-supervise---login---bash---startx---xinit-+-X
          | `-sh---openbox
          |-s6-supervise---VBoxService-+-{automount}
          | |-{control}
          | |-{cpuhotplug}
          | |-{memballoon}
          | |-{timesync}
          | |-{vminfo}
          | `-{vmstats}
          |-s6-supervise---s6-ipcserverd---2*[ucspilogd]
          |-s6-supervise---ucspilogd
          |-s6-supervise---dbus-daemon
          |-s6-supervise---dhcpcd
          `-urxvtd---bash---pstree

Cheers,
G.
Received on Sun May 10 2015 - 18:14:50 UTC