* [linux-lvm] Reason to use -r when systemd-run vgchange -aay @ 2021-12-14 5:45 Tom Yan 2021-12-14 15:34 ` David Teigland 0 siblings, 1 reply; 3+ messages in thread From: Tom Yan @ 2021-12-14 5:45 UTC (permalink / raw) To: LVM general discussion and development, David Teigland 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/ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-lvm] Reason to use -r when systemd-run vgchange -aay 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 2021-12-14 16:55 ` Tom Yan 0 siblings, 1 reply; 3+ messages in thread From: David Teigland @ 2021-12-14 15:34 UTC (permalink / raw) To: Tom Yan; +Cc: LVM general discussion and development 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/ ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-lvm] Reason to use -r when systemd-run vgchange -aay 2021-12-14 15:34 ` David Teigland @ 2021-12-14 16:55 ` Tom Yan 0 siblings, 0 replies; 3+ messages in thread From: Tom Yan @ 2021-12-14 16:55 UTC (permalink / raw) To: David Teigland; +Cc: LVM general discussion and development 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/ ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-12-14 16:56 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2021-12-14 16:55 ` Tom Yan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.