archive mirror
 help / color / mirror / Atom feed
From: Tom Yan <>
To: LVM general discussion and development <>,
	David Teigland <>
Subject: [linux-lvm] Reason to use -r when systemd-run vgchange -aay
Date: Tue, 14 Dec 2021 13:45:57 +0800	[thread overview]
Message-ID: <> (raw)

Hi David,

I notice that in the "new" 69-dm-lvm.rules, vgchange -aay is run with
systemd-run, which is not a problem.

However, the fact that the --remain-after-exit (i.e. -r) switch is
used is, because the service is not stopped when e.g. one deactivates
a VG with vgchange -an, which will prevent the VG from being
auto-activated again if e.g. the PV is removed and inserted again.

I'm not sure if that was a desired behaviour / one of the intended
purposes. Regardless, I'm not exactly seeing the sense of that either.

Besides, I don't suppose it would work very well for multi-PV VGs
anyway. I mean, most likely similar errors (albeit probably harmless)
would be spammed because of the repeated attempt to *create* a
transient unit of the same name. (Repeated systemd-run is NOT the same
as repeated systemctl start; it's also the reason that triggering
`systemctl stop` with remove event is not a perfect idea either, since
transient unit created would be gone once it is stopped, so repeated
systemctl stop will cause more errors to be spammed; Yet we need the
unit to be gone when it is stopped for the current approach, even if
it's possible to prevent it from going away.)

So are there any reasons that we actually need -r? If so, I think we
need to deal with them with another approach (maybe unit template?).

I also saw this PR on github. I'm not sure if what it stated makes any
sense though:

All the best,

linux-lvm mailing list
read the LVM HOW-TO at

             reply	other threads:[~2021-12-14  5:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14  5:45 Tom Yan [this message]
2021-12-14 15:34 ` [linux-lvm] Reason to use -r when systemd-run vgchange -aay David Teigland
2021-12-14 16:55   ` Tom Yan

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* 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).