archive mirror
 help / color / mirror / Atom feed
From: David Teigland <>
To: Tom Yan <>
Cc: LVM general discussion and development <>
Subject: Re: [linux-lvm] Reason to use -r when systemd-run vgchange -aay
Date: Tue, 14 Dec 2021 09:34:40 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Dec 14, 2021 at 01:45:57PM +0800, Tom Yan wrote:
> 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 added -r to make it easier to see the status/output of the transient
service.  The problem of rerunning the same transient service crossed my
mind at one point, but I never went back to check that.  With your
confirmation, it sounds like -r should be removed.  I want to check if
we can see everything we need to without -r.  I think that service
templates only work with device names, where we need a VG name.

The behavior of repeated VG autoactivation is not entirely well defined,
but we've made some attempt to maintain the status quo.  We may add an
lvm.conf setting at some point to control that behavior if issues appear.

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

I'm not sure about that, those generated services don't get much attention
and we've begun asking around to see if they could be removed.


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

  reply	other threads:[~2021-12-14 15:35 UTC|newest]

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

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