Re: Scripting Stage 3 and 4

Paul Sopka <[email protected]> Sat, 11 Jan 2025 16:15:42 +0100
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
>  With no tty? and not even a redirection from/to /dev/console? That's
> going to be a tough recovery 😉
I took redirection from/to /dev/console for granted xD, after all what I 
wrote as only part of a larger script.

>  And sure, you could wrap all your commands in a big if block. But my
> point is that these are *things you need to think about*. I'd rather
> not have to think about new things at shutdown time when I don't have
> to. Why change something and duplicate logic when you could just do
> nothing and keep what's already working and has worked for the whole
> lifetime of the machine? 
So you mean rather than (to quote myself):
> | if -n { mount -o remount,ro / }
> | foreground { s6-svc -U /run/service/recovery } 
You would just not tear down one tty (e.g. 12) or a "minimal recovery 
ssh server listening on an unusual port"?

>  The key to understanding how to manage a shutdown, I think, is to
> realize that boot and shutdown *are not symmetrical*, and so, do not
> need to be handled in a symmetrical way. Because you set up a
> supervision tree at boot time does not mean you need to get rid of it
> at shutdown time.
>
>  When you boot, you're starting from *nothing*, and you need to build
> up to a state where the machine is functional and able to run services,
> that's why it's incremental and deliberate and elaborate. It is
> literally a bootstrap process that needs precise ordering.
>
>  When you shutdown, you're starting from a state where everything is
> already working, so you can rely on many more features, and you're not
> trying to build anything, you're just trying to ensure consistency of
> permanent state (aka disk) before you pull the plug. It's the only
> thing that matters. If you were only ever operating in RAM, starting
> from ROM / ro disk, and never had any mutable permanent state, your
> shutdown procedure could just be an immediate reboot(), or pressing
> the power off button; it is the case for some embedded devices. But
> with mutable permanent state, we need to be more careful, that's why
> we shut down services in an ordered way, and then make sure we can
> unmount the filesystems before powering off. It's the *only* reason;
> apart from that, you can do whatever you want. Who cares? the system is
> going to be down anyway. When the Armageddon comes, you want to make
> sure the time capsules are well sealed and buried for the next
> civilization to find, but you don't have to clean your room.
>
>  So the goals of boot and shutdown are very different.
>
>  I specifically designed s6-linux-init so it would not store any vital
> information in permanent mutable state, and would not hold any writing
> fd on a filesystem. That means s6 will not prevent you from unmounting
> your filesystems, parking your disks, whatever - and that the
> supervision tree can keep running until you pull the plug. It is
> designed to help you while the machine is running, and *especially*
> in delicate situations where you're killing things and want to be sure
> you can recover if something goes wrong rather than brick the system.
> That's why I'm saying it's less effort to keep it in place and work
> with disabling supervision when it needs to be disabled, than to
> dismantle the supervision tree and have to reimplement recovery logic. 
Very interesting, thank you very much for this detailed response, I 
fully agree!
I think it might be worth putting this on the page I cited in the first 
mail.

>> | if -n { mount -o remount,ro / }
>> | foreground { s6-svc -U /run/service/recovery }
>
>  You just tore down the supervision tree, and you want to start a
> recovery... service? :D 

This was meant for the approach of keeping the supervision tree,
to be ran by the shutdown service.
But now it seems to me that it would be another case of

> *things you need to think about*
So, I guess it would be better to have a recovery service right away and 
not stop it,
like I suggested at the start of this mail?

Finally, wouldn't at least one "if" be appropriate,
to be sure whether everything is unmounted properly?


Regards,

Paul
OpenPGP_0x71C7C85A2EA30F62.asc (application/pgp-keys, 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)