On Tue, 14 Dec 2021 at 23:35, David Teigland <teigland@xxxxxxxxxx> 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@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
