supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Brett Neumeier <bneumeier@gmail.com>
To: Guillermo <gdiazhartusch@gmail.com>
Cc: Supervision <supervision@list.skarnet.org>
Subject: Re: s6-linux-init: Actions after unmounting filesystems
Date: Sun, 18 Aug 2019 16:36:31 -0500	[thread overview]
Message-ID: <CAGSetNuzteLW91-Uq-xXKKbcgi7Lx6iotr8XjwV4mEXnE8QO1g@mail.gmail.com> (raw)
In-Reply-To: <CADQ2Nw85w2Ny-E_d2gQdmTi0mhYaU68S6giOQs3h31WafS4Q-Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Sat, Aug 17, 2019 at 2:20 PM Guillermo <gdiazhartusch@gmail.com> wrote:

> There are certain setups that require doing something after
> filesystems are unmounted. Two examples are LVM logical volumes and
> LUKS encrypted volumes, but I suppose there must be more cases. In any
> such setup, the shutdown sequence would include a 'vgchange -a n'
> command or 'cryptsetup close' command after filesystems are unmounted.
>

How important are these cases?

I have not inspected the code to see what cryptsetup close does, aside from
remove the encrypted device mapping for the encrypted volume; nor have I
looked at the LVM code to see if it does anything other than remove device
mapping. But in either case, what I generally do on my systems is simply
unmount volumes (or in the case of the root filesystem, remount it
read-only), sync to make sure all dirty buffers are written, and then just
shut down/reboot/whatever.

Leaving LVM and encrypted volumes active has never caused any problems for
me.

It seems worthwhile to ask whether those examples are real problems that
need to be addressed, since all of the proposed solutions have some level
of hairiness about them. And if those examples are *not* real issues, it
might be worthwhile to ask if there are other examples that *are*.

-- 
Brett Neumeier (bneumeier@gmail.com)

      parent reply	other threads:[~2019-08-18 21:36 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
2019-08-18 20:36             ` Oliver Schad
2019-08-18 15:08   ` Guillermo
2019-08-18 21:36 ` Brett Neumeier [this message]

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=CAGSetNuzteLW91-Uq-xXKKbcgi7Lx6iotr8XjwV4mEXnE8QO1g@mail.gmail.com \
    --to=bneumeier@gmail.com \
    --cc=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).