For the normal case you are absolutly right. But with stage 2 as a service you have a race condition between stage 2 and s6-svscan-log. The usual trick for stage 2 solves this problem.
Ah, now I get it: stage 2 must not start before the catch-all logger is ready, so you open the fifo for writing with the intent to block until the reader has started. Yes, that makes sense and is needed. However, I will list it as another drawback of your approach :P The internal sauce is visible in your stage 2 script. Ideally, stage 2 would only run once everything is already in place and wouldn't have to bother with any mechanism details. (s6-linux-init achieves this.)
Well, running once is a part of supervise from the start on, by djb. It's invented for oneshots.
I disagree. svc -o was made for short-lived processes that you may want to run again. Or for testing a crashing daemon without having to deal with automatic restarts and failure loops. Anything that you potentially run more than once. It's "run once", but still in the context of supervision; you would only use it on services that have at least the potential to make use of supervision. For things that you will only ever run once, why even supervise them in the first place? Supervision is a wonderful tool, but like any tool, it should only be used when appropriate, and I don't think the one-time initialization script is the place for it.
Well, s6-rc is using ./down, too. The shutdown is a very special case for supervision.
There is an important difference. s6-rc is using ./down files for services that it wants down, independently from the machine's lifetime. Typically it's using them at boot time, in order to have the supervisors start, but not the services themselves (they'll be brought up later on according to the dependency graph). s6-rc *wants* the services to be supervised, even if it's not starting them at the same time as the supervisors. You're only using a ./down file at shutdown time because you have a service that you know must not restart when the supervisor is killed, and will never restart, and has not been restarted for the entire machine lifetime. The presence of the supervisor here is not a feature, it brings you no value, on the contrary - it's only making your life more difficult.
Stage 2 as a service allows us to restart it, if - accidentally - it is necessary. Obviously, that should be really seldom the case.
Honestly, I can't think of a single case where you'd need to restart the initialization sequence of your machine. Anything you'd want to restart once the system has booted should be handled by the service manager.
I'm still migrating from systemd to s6{,-rc} with /fs/* step by step. Therfore, I need more flexibility than s6-linux-init.
The migration from systemd's service manager (to s6-rc or anything else) is totally independent from the init system change. You can make a systemd oneshot that launches s6-rc-init then s6-rc, and convert all your systemd services one by one to s6-rc services; then, once you don't depend on systemd for anything else than the early boot and the s6-rc service, you can switch inits, and then you should be able to use s6-linux-init. I generally recommend doing the opposite: switching to s6-linux-init first then converting services to s6-rc, because the latter is a lot more work: for instance Adélie uses s6-linux-init but still has OpenRC as its service manager, because I haven't done the conversion work yet. However, it's different with systemd, because systemd cannot be run as not-pid-1 - its service manager cannot be separated from its early boot functionality. So you have to keep it as init until it's not needed for anything else. They call it modular software ;) -- Laurent