supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: s6-linux-init: Actions after unmounting filesystems
Date: Sun, 18 Aug 2019 16:28:40 -0300	[thread overview]
Message-ID: <CADQ2Nw_ZceQnU6G5Zc_rDC4CMUanCi+GLqMxY-kw71iDa0nGfg@mail.gmail.com> (raw)
In-Reply-To: <emb1b6130d-f674-4683-8f1f-696dabe927ea@elzian>

El dom., 18 ago. 2019 a las 15:36, Laurent Bercot escribió:
>
> >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.
>
> Are there systems in the real world that actually work like that? That
> need pivoting into a "shutdownramfs" in order to be able to unmount the
> rootfs and perform teardown operations on it? This is doable, of course,
> but sounds too complex and too brittle. You'd need more than a fsck to
> recover after a power loss, for instance.

I know that there are people that have the rootfs on an LVM logical
volume or a LUKS encrypted volume, yes. However, those are specialized
setups. I don't use one myself, I think they are risky, and I don't
know the details, but I think they are handled with a (mandatory)
initramfs. Perhaps someone else knows this better. Our friends from
the systemd project have thought of that as well (the 'shutdownramfs'
would be the initramfs that is kept mounted at /run/initramfs):

* https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface

But I think of this as a separate problem, that maybe also means
revisiting the decision of not having s6-svscan do its finish
procedure. I didn't want to mention all the complicated cases at once
:)

>   Now the fun part for me is to find a way for s6-l-i-umountall to
> leave the proper filesystems mounted. It's not as straightforward as
> it seems: if /dev is a symlink to, say, /mnt/tmpfs/dev, then you want
> to keep /mnt/tmpfs/dev, even if it means you have to keep /mnt/tmpfs.
> But if you have a second dev mount on /usr/local/mychroot/dev, then
> you want to unmount that one, so you can unmount /usr/local. I suppose
> I can count the number of devtmpfs, procfs and sysfs, and only keep
> one of each (the first that was mounted), but I have to think more
> about it to make sure it catches everything.

Why not just leaving all of them alone? s6-linux-init-umountall
already warns about, but then just ignores, umount(2) failures. What
happens if you try to unmount /mnt/tmpfs, and you have a devtmpfs
mounted on /mnt/tmpfs/dev that you have previously skipped?

G.


  reply	other threads:[~2019-08-18 19:28 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
2019-08-18 18:35         ` Laurent Bercot
2019-08-18 19:28           ` Guillermo [this message]
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=CADQ2Nw_ZceQnU6G5Zc_rDC4CMUanCi+GLqMxY-kw71iDa0nGfg@mail.gmail.com \
    --to=gdiazhartusch@gmail.com \
    --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).