On 06/01/2015 02:03, James Powell wrote:
The initial init bootscript that I'm currently drafting is in execline using the template provided by Laurent. I was going to take the advice on using /bin/sh rather than /bin/execlineb but I recanted that decision due to the fact I wanted the using the FIFO handling execline provides.
Far be it from me to discourage you from your noble quest ! But you could write it in sh and just use the 'redirfd' command from execline, which does the FIFO magic. That said, performing multiple chain loads in shell is a pain, and you'd have to write something like "... ; exec redirfd -wnb 1 fifo /bin/sh -c '...'" which quickly becomes a quoting nightmare for the second part of the script. So maybe learning execline is the right choice. ;)
If I am reading things correctly, assumingly, init-stage1 using the template, I only need to correct the paths and include any mounts of virtual kernel file systems not listed as well as get cgroups ready, and stage any core one-time services like copying core service scripts to the service scan directory on the tmpfs, correct, before passing off to init-stage2 to load drivers, start daemons, etc.?
That is correct - it's how I designed the example init-stage1 in the s6 tarball. It is not the only way to proceed, but I find it the safest way, even safer than runit, because it puts the supervision infrastructure in place extremely early on. The idea is that unlike svscan and runsvdir (that poll their scan directory every five seconds no matter what), s6-svscan can be told to scan for services immediately (with the s6-svscanctl -a command). So it's possible for a s6-based system to start s6-svscan on an empty, or nearly empty, scan directory, to have it running as early as possible; then to populate the scan directory with other services, and trigger s6-svscan so those services start immediately. So, stage 1 just becomes: a) Do what is strictly necessary to prepare the scan directory for s6-svscan b) Fork a background process that will block until s6-svscan is guaranteed running c) exec into s6-svscan, which will run as process 1 until shutdown. a) involves virtual filesystems, maybe cgroups, and setting up a few basic services in the scan directory: s6-svscan's own logger, udev, and an early getty for debugging, for instance. b) can be done in different ways, but I've found it simple to just open s6-svscan's logging FIFO for writing in the *normal* way. That operation will block until there's a reader for the FIFO, and such a reader will appear when s6-svscan's logger is up, which means that s6-svscan is up and running and has started its own logging service. At this point, the background process can unblock, and run what I call init-stage2, which can mount filesystems, populate the scan directory and call s6-svscanctl -a to start services, etc. c) needs a way to *not* block on the FIFO while there is no reader, and that's why redirfd is handy here. Note that this scheme allows exactly every service on the system to be supervised. Even udev. Even s6-svscan's own logger. I believe this is the cleanest way to use a supervision infrastructure. There is no theoretical objection to using that scheme with runit or daemontools too. There simply are two practical roadbumps: * The FIFO trick. This can be solved by using execline's redirfd even in a daemontools/runit installation, or by adding a few lines of special code to daemontools/runit. * The fact that runsvdir/svscan can wait for up to 5 seconds before launching a requested service: there is no way to trigger a scan like there is with s6. This makes it hard to populate a scan directory sequentially, because the waiting times (before runsvdir picks up the new service directory and starts the service) will add up, and the boot process will be very slow. But as a proof of concept, it could be done. -- Laurent