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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
