From: Paul Sopka <psopka@sopka.ch>
To: supervision@list.skarnet.org,
Laurent Bercot <ska-supervision@skarnet.org>
Subject: Re: Scripting Stage 3 and 4
Date: Sat, 11 Jan 2025 16:15:42 +0100 [thread overview]
Message-ID: <261837cb-6c20-4dc7-b3f0-c9423229447d@sopka.ch> (raw)
In-Reply-To: <em803907af-6a1d-45cc-a86d-76a32a10bfb8@7cd22256.com>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 4200 bytes --]
> 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
[-- Attachment #1.1.1.2: Type: text/html, Size: 6875 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2025-01-11 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 20:25 Paul Sopka
2025-01-09 23:19 ` Laurent Bercot
2025-01-11 8:30 ` Paul Sopka
2025-01-11 12:21 ` Re[2]: " Laurent Bercot
2025-01-11 15:15 ` Paul Sopka [this message]
2025-01-11 13:22 ` Guillermo
2025-01-11 15:29 ` Paul Sopka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=261837cb-6c20-4dc7-b3f0-c9423229447d@sopka.ch \
--to=psopka@sopka.ch \
--cc=ska-supervision@skarnet.org \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).