Re: s6-linux-init: Actions after unmounting filesystems

From: Samuel Holland <samuel_at_sholland.org>
Date: Sun, 18 Aug 2019 11:18:50 -0500

On 8/18/19 1:26 AM, Laurent Bercot wrote:
>> Sorry if I read this thread too hastily, but why not just keep /proc etc
>> mounted, as was seemingly the way with s6-linux-init <=v0.4.x.x (and
>> therefore slew)?  Since the asymmetry is by nature, simply respecting it
>> appears to be one minimalist way.
>
> The umount command basically performs a "umount -a". I can add a list
> of filesystems that should be kept, but it's more ad-hoc code. It's
> ugly.
> But I guess the whole situation is ad-hoc anyway, so elegance isn't
> exactly what we're going for here :/

Simply excluding filesystems doesn't help when the root filesystem is on one of
these devices that needs teardown actions after being unmounted. In that case,
the only workable solution is to have PID1 pivot_root() to a tmpfs with the
teardown/reboot tools in it. That way you can actually fully unmount the former
root filesystem.

Under the current architecture, I think it is ideal to maintain the
mount/unmount symmetry as much as possible. This is done in your service manager
via dependencies. Have a oneshot for each filesystem that needs to be mounted,
and (when applicable) have that oneshot depend on another oneshot that
creates/destroys the underlying lvm/md/dm-crypt device. Then the dm device will
be created before mount, and destroyed after unmount.

Yes, unmounting will fail if the filesystem is in use (or already unmounted),
and destroying will fail if the filesystem is still mounted, but that's okay
because a `down` script should be idempotent and /always/ return success. Even
when there are failures, this will minimize the number of loose ends left when
shutdownd takes over. The unmounting done by shutdownd should be treated as a
last resort.

As a side note: what if there was a oneshot that did `kill -1` when brought
down, and this oneshot depended on all of your filesystem mounts? Other than the
obvious problem of s6-rc-update nuking your system, would it be possible to make
s6-rc recover from being nuked and continue a shutdown?

--Samuel
Received on Sun Aug 18 2019 - 16:18:50 UTC