supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Samuel Holland <samuel@sholland.org>
To: Laurent Bercot <ska-supervision@skarnet.org>,
	supervision@list.skarnet.org
Subject: Re: s6-linux-init: Actions after unmounting filesystems
Date: Sun, 18 Aug 2019 11:18:50 -0500	[thread overview]
Message-ID: <a77fcd9c-8454-5c87-92f2-814aff5fc5b0@sholland.org> (raw)
In-Reply-To: <emc7256f0a-c18a-4003-a038-03c1e2098da8@elzian>

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


  parent reply	other threads:[~2019-08-18 16:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-17 19:14 Guillermo
2019-08-17 23:01 ` Laurent Bercot
2019-08-18  4:09   ` Casper Ti. Vector
     [not found]   ` <20190818040925.yqy4nm7cwsnrtyjl@caspervector>
2019-08-18  6:26     ` Laurent Bercot
2019-08-18  8:34       ` Casper Ti. Vector
2019-08-18 16:18       ` Samuel Holland [this message]
2019-08-18 18:35         ` Laurent Bercot
2019-08-18 19:28           ` Guillermo
2019-08-18 20:36             ` Oliver Schad
2019-08-18 15:08   ` Guillermo
2019-08-18 21:36 ` Brett Neumeier

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=a77fcd9c-8454-5c87-92f2-814aff5fc5b0@sholland.org \
    --to=samuel@sholland.org \
    --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).