Re: stage4 of shutdown

>After reading through the source of s6-linux-init again,
>I realised that it can only work if s6-linux-init-hpr is on the root parti=
tion,
>since all other partitions are umounted before its execution.
>
>Although this is surely fine in most cases
>(and my current implementation has the same limitation),
>I was thinking about ways to avoid this limitation.

  And after that, you're going to try booting with the s6-linux-init
binary on another partition as well? =F0=9F=98=9B

  By definition, the s6-linux-init binaries have to reside on the root
partition. That includes s6-linux-init-hpr. There is no reason to
move that binary away.
  The only s6-linux-init binary that would make sense to have on a
different partition is s6-linux-init-maker, because it's not used at
boot or shutdown time. You can package it that way if you want.
  But s6-linux-init-hpr has to stay on the root partition. You *might*
manage to make it work otherwise, but I think you'll find the trade-offs
are just not worth it.


>a)	Assumption: everything is directly or indirectly started by s6-supervis=
e.
>
>b)	Users are instructed to write umount (or remount read-only) down script=
s for s6-rc,

  These won't work.

  The thing to remember is that _boot and shutdown are not symmetrical_.
And it's okay. They don't need to be.

  One of the differences between boot and shutdown is that when booting,
you know exactly what state your machine is in, and what processes are
running on it. But when shutting down, you don't. Even if (a) is true
in the beginning, users can launch backgrounded nohup scripts that=20
detach
from their login session and evade control by any instance of
s6-supervise. That is an entirely legitimate use of the machine's
resources, you cannot forbid it. So you cannot rely on (a).

  And so, when shutting down, there may be processes running and holding
file descriptors open on various filesystems, and that will not die=20
while
you're orderly stopping all the services via s6-rc. You don't know, and
you have no control over this. That is why you cannot unmount=20
filesystems
before killing all processes. That is one of the main reasons why boot
and shutdown are not symmetrical, and why unmounting filesystems in=20
s6-rc
symmetrically from mounting them is generally a bad idea.

  The only exception is when you're managing an embedded device or
something similar where there is no user shell ever, and no possible=20
code
path leading to any lingering long-running process holding a descriptor
on any non-root filesystem. Can you guarantee that? I certainly cannot.
Even if you tried, it would be very brittle; the smallest bug could
potentially cascade through your unmounts failing into filesystem
corruption.

  Again, not a good trade-off.

  Stage 4 in s6-linux-init exists because it's the simplest way to safely
shut a machine down in all cases. I don't think you can escape the
SIGTERM+SIGKILL+unmount dance; nobody can. If you are very confident
that there is no stray process at the end of stage 3, then just use a
grace time of 0, or 1 millisecond: your shutdown will be as quick as
it can possibly be.

  As is, a s6-linux-init shutdown, even with a normal grace period, is
*much* faster than an OpenRC shutdown, and to my knowledge, a little
faster than a systemd shutdown. I see no benefit in trying to make it
even faster at the price of reliability.

--
  Laurent