On 21/06/2016 14:00, Martin "eto" Misuth wrote:
> Let's say, one mounts some tmpfs fses, containing sevicedirs, and fires up
> s6-svscan as one of first binaries (when booting from ramdisk) - what is
> expected behaviour of running instance of s6-svscan, when pivot_root happens ?
Heh, that's a good point.
I wouldn't try it. The supervision tree itself would keep working, but it
would defeat all the normal assumptions that people do about it, e.g.
"service directories can be accessed via a reliable absolute path".
s6-rc would break horribly, but you'd be insane to run anything of the kind
before pivot_rooting.
Generally speaking, you shouldn't run any long-lived process before
pivot_rooting or switch_rooting. The structure of the filesystem is too
important an assumption to be modified behind people's (or daemon's) backs.
Fortunately, there's really no need to do that: the early initialization
that happens in an initramfs is oneshot-only, and your real "init" is
always run after the pivot_root happens; that's the moment when you can
spawn long-lived processes.
There's obviously one exception: udevd. Some systems need it to coldplug
devices, in order to find the correct device to pivot_root on. The answer
here is that it's a design mistake of udevd (the n+1th one...) to not
provide a short-lived hotplug helper for this.
With a program such as mdev, it's possible to find the correct device
without running a daemon:
- register /sbin/mdev as a hotplug helper
- run mdev -s (the coldplug scanner)
- unregister the hotplug helper
- your /dev is fully populated, you can pivot_root
With udevd, the workaround is to kill it after you have performed the
coldplug, and only restart it as part of your normal boot sequence once
you have pivot_rooted. It can be supervised at this point.
--
Laurent
Received on Tue Jun 21 2016 - 12:45:59 UTC