Re: stage4 of shutdown

From: Paul Sopka <psopka_at_sopka.ch>
Date: Tue, 23 Dec 2025 08:54:43 +0100

> 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.
>
This is not a request to change s6-linux-init in any way.
I understand that it must reside on root and I am convinced that this is a good solution.
I am doing an experiment here, depending on the outcome of which
I might change my own scripts (also including an init script).
Thats why I am asking whether remounting read-only over umounting
would be feasable.

> 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
> 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).
>
That was exactly what I was unsure about and the main reason
I came to ask here, thank you!

> 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.
>
I am not trying to make it faster, but to cut down on complexity,
I now understand that this specific complexity is really necessary.

Best regards,
Paul Sopka

Received on Tue Dec 23 2025 - 08:54:43 CET

This archive was generated by hypermail 2.4.0 : Tue Dec 23 2025 - 08:55:17 CET