[linux-lvm] Reason to use -r when systemd-run vgchange -aay

[linux-lvm] Reason to use -r when systemd-run vgchange -aay

[Tom Yan]

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: https://github.com/lvmteam/lvm2/pull/37

All the best,
Tom

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Reason to use -r when systemd-run vgchange -aay

[David Teigland]

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: https://github.com/lvmteam/lvm2/pull/37

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.

Dave

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Re: [linux-lvm] Reason to use -r when systemd-run vgchange -aay

[Tom Yan]

On Tue, 14 Dec 2021 at 23:35, David Teigland <teigland@redhat.com> wrote:
>
> 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.

Yeah without `-r` the services will not be listed in `systemctl`, but
apparently their "deactivation" will still be logged.

Regardless, FYI, the following works too (there might still be room
for improvement though):

$ git diff /{usr/lib,etc}/udev/rules.d/69-dm-lvm.rules
diff --git a/usr/lib/udev/rules.d/69-dm-lvm.rules
b/etc/udev/rules.d/69-dm-lvm.rules
index 1a6b450..abf5396 100644
--- a/usr/lib/udev/rules.d/69-dm-lvm.rules
+++ b/etc/udev/rules.d/69-dm-lvm.rules
@@ -13,6 +13,7 @@ ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="lvm_end"
 # Only process devices already marked as a PV - this requires blkid
to be called before.
 ENV{ID_FS_TYPE}!="LVM2_member", GOTO="lvm_end"
 ENV{DM_MULTIPATH_DEVICE_PATH}=="1", GOTO="lvm_end"
+ACTION=="remove", ENV{LVM_VG_NAME_COMPLETE}=="?*",
RUN+="/usr/bin/systemctl stop lvm-activate@$env{LVM_VG_NAME_COMPLETE}"
 ACTION=="remove", GOTO="lvm_end"

 # Create /dev/disk/by-id/lvm-pv-uuid-<PV_UUID> symlink for each PV
@@ -80,7 +81,7 @@ ENV{SYSTEMD_READY}="1"
 # it's better suited to appearing in the journal.

 IMPORT{program}="/usr/bin/lvm pvscan --cache --listvg --checkcomplete
--vgonline --udevoutput --journal=output $env{DEVNAME}"
-ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run -r
--no-block --property DefaultDependencies=no --unit
lvm-activate-$env{LVM_VG_NAME_COMPLETE} /usr/bin/lvm vgchange -aay
--nohints $env{LVM_VG_NAME_COMPLETE}"
+ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemctl start
lvm-activate@$env{LVM_VG_NAME_COMPLETE}"
 GOTO="lvm_end"

 LABEL="lvm_end"

$ cat /etc/systemd/system/lvm-activate\@.service
[Unit]
DefaultDependencies=no

[Service]
RemainAfterExit=yes
ExecStart=/usr/bin/lvm vgchange -aay --nohints %i

>
> 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: https://github.com/lvmteam/lvm2/pull/37
>
> 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.
>
> Dave
>

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/