[linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Julian Andres Klode]

systems might have systemd as their normal init systems, but
might not be using it in their initramfs; or like Debian, support
different init systems.

Detect whether we are running on systemd by checking for /run/systemd/system
and then change the behavior accordingly.

This effectively breaks compatibility with systemd versions prior to
205, as 205 was the minimum version for the feature.

Bug-Debian: https://bugs.debian.org/933011
---
 configure.ac                  | 24 ------------------------
 udev/69-dm-lvm-metad.rules.in |  6 ++++--
 udev/Makefile.in              | 10 +---------
 3 files changed, 5 insertions(+), 35 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1e45c0edc..5beffd8e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1055,29 +1055,6 @@ AC_MSG_RESULT($BLKID_WIPING)
 AC_DEFINE_UNQUOTED(DEFAULT_USE_BLKID_WIPING, [$DEFAULT_USE_BLKID_WIPING],
 		   [Use blkid wiping by default.])
 
-################################################################################
-dnl -- Enable udev-systemd protocol to instantiate a service for background jobs
-dnl -- Requires systemd version 205 at least (including support for systemd-run)
-AC_ARG_ENABLE(udev-systemd-background-jobs,
-	      AC_HELP_STRING([--disable-udev-systemd-background-jobs],
-			     [disable udev-systemd protocol to instantiate a service for background job]),
-	      UDEV_SYSTEMD_BACKGROUND_JOBS=$enableval,
-	      UDEV_SYSTEMD_BACKGROUND_JOBS=maybe)
-
-if test "$UDEV_SYSTEMD_BACKGROUND_JOBS" != no; then
-	pkg_config_init
-	PKG_CHECK_MODULES(SYSTEMD, systemd >= 205,
-			  [UDEV_SYSTEMD_BACKGROUND_JOBS=yes],
-			  [if test "$UDEV_SYSTEMD_BACKGROUND_JOBS" = maybe; then
-				UDEV_SYSTEMD_BACKGROUND_JOBS=no
-			   else
-				AC_MSG_ERROR([bailing out... systemd >= 205 is required])
-			   fi])
-fi
-
-AC_MSG_CHECKING(whether to use udev-systemd protocol for jobs in background)
-AC_MSG_RESULT($UDEV_SYSTEMD_BACKGROUND_JOBS)
-
 ################################################################################
 dnl -- Enable udev synchronisation
 AC_MSG_CHECKING(whether to enable synchronisation with udev processing)
@@ -1772,7 +1749,6 @@ AC_SUBST(CACHE_RESTORE_CMD)
 AC_SUBST(UDEV_PC)
 AC_SUBST(UDEV_RULES)
 AC_SUBST(UDEV_SYNC)
-AC_SUBST(UDEV_SYSTEMD_BACKGROUND_JOBS)
 AC_SUBST(UDEV_RULE_EXEC_DETECTION)
 AC_SUBST(UDEV_HAS_BUILTIN_BLKID)
 AC_SUBST(USE_TRACKING)
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
index d51006496..a797bbcd6 100644
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -73,7 +73,8 @@ GOTO="lvm_end"
 # For "systemd_background" mode, systemd takes care of this by activating
 # the lvm2-pvscan@.service only once.
 LABEL="next"
-ACTION!="(PVSCAN_ACTION)", GOTO="lvm_end"
+TEST!="/run/systemd/system", ACTION!="add", GOTO="lvm_end"
+TEST=="/run/systemd/system", ACTION!="add|change", GOTO="lvm_end"
 
 LABEL="lvm_scan"
 
@@ -83,7 +84,8 @@ ENV{SYSTEMD_READY}="1"
 # --(enable|disable)-udev-systemd-background-jobs to "configure".
 # On modern distributions with recent systemd, it's "systemd_background";
 # on others, "direct_pvscan".
-GOTO="(PVSCAN_RULE)"
+TEST!="/run/systemd/system", GOTO="direct_pvscan"
+TEST=="/run/systemd/system", GOTO="systemd_background"
 
 LABEL="systemd_background"
 
diff --git a/udev/Makefile.in b/udev/Makefile.in
index e32cba921..57a96fefb 100644
--- a/udev/Makefile.in
+++ b/udev/Makefile.in
@@ -43,16 +43,8 @@ else
 BLKID_RULE=IMPORT{program}=\"${SBIN}\/blkid -o udev -p \$$tempnode\"
 endif
 
-ifeq ("@UDEV_SYSTEMD_BACKGROUND_JOBS@", "yes")
-PVSCAN_RULE=systemd_background
-PVSCAN_ACTION=add|change
-else
-PVSCAN_RULE=direct_pvscan
-PVSCAN_ACTION=add
-endif
-
 %.rules: $(srcdir)/%.rules.in
-	$(Q) $(SED) -e "s+(DM_DIR)+$(DM_DIR)+;s+(BINDIR)+$(BINDIR)+;s+(BLKID_RULE)+$(BLKID_RULE)+;s+(PVSCAN_RULE)+$(PVSCAN_RULE)+;s+(PVSCAN_ACTION)+$(PVSCAN_ACTION)+;s+(DM_EXEC_RULE)+$(DM_EXEC_RULE)+;s+(DM_EXEC)+$(DM_EXEC)+;s+(LVM_EXEC_RULE)+$(LVM_EXEC_RULE)+;s+(LVM_EXEC)+$(LVM_EXEC)+;" $< >$@
+	$(Q) $(SED) -e "s+(DM_DIR)+$(DM_DIR)+;s+(BINDIR)+$(BINDIR)+;s+(BLKID_RULE)+$(BLKID_RULE)+;s+(DM_EXEC_RULE)+$(DM_EXEC_RULE)+;s+(DM_EXEC)+$(DM_EXEC)+;s+(LVM_EXEC_RULE)+$(LVM_EXEC_RULE)+;s+(LVM_EXEC)+$(LVM_EXEC)+;" $< >$@
 
 %_install: %.rules
 	@echo "    [INSTALL] $<"
-- 
2.20.1

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 25. 07. 19 v 20:49 Julian Andres Klode napsal(a):
> systems might have systemd as their normal init systems, but
> might not be using it in their initramfs; or like Debian, support
> different init systems.
> 
> Detect whether we are running on systemd by checking for /run/systemd/system
> and then change the behavior accordingly.
> 


Wouldn't it be better to simply disable compiling/using lvmetad on such systems ?

HEAD of 2.03 already dropped lvmetad anyway.

Do you need any sort of autoactivation in ramdisk ?

There is probably higher complexity.

pvscan was not moved into systemd service just for fun - there have been at 
least 2 major mandatory points why  'pvscan' with autoactivation MUST NOT be 
executed from udev rule directly (udev timeout)

So the proposed patch must be NAC-ked as it is - as it probably causing way 
more troubles then it solves.

Regards

Zdenek

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Julian Andres Klode]

On Tue, Jul 30, 2019 at 05:02:44PM +0200, Zdenek Kabelac wrote:
> Dne 25. 07. 19 v 20:49 Julian Andres Klode napsal(a):
> > systems might have systemd as their normal init systems, but
> > might not be using it in their initramfs; or like Debian, support
> > different init systems.
> > 
> > Detect whether we are running on systemd by checking for /run/systemd/system
> > and then change the behavior accordingly.
> > 
> 
> 
> Wouldn't it be better to simply disable compiling/using lvmetad on such systems ?

I don't see how this has anything to do with lvmetad. There is no lvmetad
anymore.

> HEAD of 2.03 already dropped lvmetad anyway.
> 
> Do you need any sort of autoactivation in ramdisk ?

Of course we need the PV to be scanned automatically so we can then find
the root partition. The root device finding is event-based, we have a tool
that listens to udev and waits for 30s for the device to appear, and relies
on the events being triggered correctly.

> There is probably higher complexity.
> 
> pvscan was not moved into systemd service just for fun - there have been at
> least 2 major mandatory points why  'pvscan' with autoactivation MUST NOT be
> executed from udev rule directly (udev timeout)
> 
> So the proposed patch must be NAC-ked as it is - as it probably causing way
> more troubles then it solves.

The alternative would be to disable the systemd integration entirely in
Debian and Ubuntu, as Debian requires support for non-systemd inits, and
Ubuntu requires event-based root device finding in initramfs. Surely that's
worse.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 30. 07. 19 v 17:12 Julian Andres Klode napsal(a):
> On Tue, Jul 30, 2019 at 05:02:44PM +0200, Zdenek Kabelac wrote:
>> Dne 25. 07. 19 v 20:49 Julian Andres Klode napsal(a):
>>> systems might have systemd as their normal init systems, but
>>> might not be using it in their initramfs; or like Debian, support
>>> different init systems.
>>>
>>> Detect whether we are running on systemd by checking for /run/systemd/system
>>> and then change the behavior accordingly.
>>>
>>
>>
>> Wouldn't it be better to simply disable compiling/using lvmetad on such systems ?
> 
> I don't see how this has anything to do with lvmetad. There is no lvmetad
> anymore.

The whole point of 'service' for 'pvscan' is to postone activation of DM 
devices outside of udev rule processing.

So whatever is replacing systemd service in your's systemd-less system must 
provide similar functionality.

There is currently no way to accept autoactivation capability within udev-rule 
processing.

>> HEAD of 2.03 already dropped lvmetad anyway.
>>
>> Do you need any sort of autoactivation in ramdisk ?
> 
> Of course we need the PV to be scanned automatically so we can then find
> the root partition. The root device finding is event-based, we have a tool
> that listens to udev and waits for 30s for the device to appear, and relies
> on the events being triggered correctly.

There is nothing for finding - if you pass root LV into your ramdisk the 
proper command to activate such LV  is   'lvchange -ay vgname/lvname'

Dracut uses pretty 'navive' algorithm to run such command with whenever any 
new device is found - it's added into lvm2 filters of visible device - once it 
succeeds - it can proceed....
For the 'initramdisk' functionality this is IMHO good enough.
(Although there are several very ugly hacks in this code we would like to drop...)


>> There is probably higher complexity.

Activating 'root' LV via autoactivation mechanism is very complex.
IMHO some of them are really very very hard to resolve.

>> pvscan was not moved into systemd service just for fun - there have been at
>> least 2 major mandatory points why  'pvscan' with autoactivation MUST NOT be
>> executed from udev rule directly (udev timeout)
>>
>> So the proposed patch must be NAC-ked as it is - as it probably causing way
>> more troubles then it solves.
> 
> The alternative would be to disable the systemd integration entirely in
> Debian and Ubuntu, as Debian requires support for non-systemd inits, and
> Ubuntu requires event-based root device finding in initramfs. Surely that's
> worse.

Can't really speak for any other distros.

I'm only commenting proposed patch for moving background pvscan into direct 
udev-rule is not acceptable workaround (as it simply can't work)

The system without systemd needs to provide some other mechanism how to fire 
background job.

Note - there is upcoming SID work that can supposedly resolve some of these 
issue - but the release date and it's integration into distributions like 
Debian is a topic for another debate...

Regards

Zdenek

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Julian Andres Klode]

On Wed, Jul 31, 2019 at 11:21:10AM +0200, Zdenek Kabelac wrote:
> > Debian and Ubuntu, as Debian requires support for non-systemd inits, and
> > Ubuntu requires event-based root device finding in initramfs. Surely that's

This is nonsense. No Ubuntu release has systemd-based background scanning,
and all of them work fine. Also, it's still possible to not use backgrounding
by building lvm2 accordingly - so much for "not working".

In our current development series, we did merge the new change to enable
the background handling from Debian, and this caused our initramfs to fail.

Hence, this approach to revert to the previous behavior where needed (as it
was clearly working), and still use systemd if available.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Julian Andres Klode]

On Wed, Jul 31, 2019 at 11:21:10AM +0200, Zdenek Kabelac wrote:
> Dne 30. 07. 19 v 17:12 Julian Andres Klode napsal(a):
> > On Tue, Jul 30, 2019 at 05:02:44PM +0200, Zdenek Kabelac wrote:
> > > Dne 25. 07. 19 v 20:49 Julian Andres Klode napsal(a):
> > > > systems might have systemd as their normal init systems, but
> > > > might not be using it in their initramfs; or like Debian, support
> > > > different init systems.
> > > > 
> > > > Detect whether we are running on systemd by checking for /run/systemd/system
> > > > and then change the behavior accordingly.
> > > > 
> > > 
> > > 
> > > Wouldn't it be better to simply disable compiling/using lvmetad on such systems ?
> > 
> > I don't see how this has anything to do with lvmetad. There is no lvmetad
> > anymore.
> 
> The whole point of 'service' for 'pvscan' is to postone activation of DM
> devices outside of udev rule processing.
> 
> So whatever is replacing systemd service in your's systemd-less system must
> provide similar functionality.
> 
> There is currently no way to accept autoactivation capability within
> udev-rule processing.

This has nothing to do with the part of the message you are replying too, and
is nonsense. The code to run pvscan directly is shipped, the change just moves
the decision whether to do that from compile-time to run-time.

> 
> > > HEAD of 2.03 already dropped lvmetad anyway.
> > > 
> > > Do you need any sort of autoactivation in ramdisk ?
> > 
> > Of course we need the PV to be scanned automatically so we can then find
> > the root partition. The root device finding is event-based, we have a tool
> > that listens to udev and waits for 30s for the device to appear, and relies
> > on the events being triggered correctly.
> 
> There is nothing for finding - if you pass root LV into your ramdisk the
> proper command to activate such LV  is   'lvchange -ay vgname/lvname'
> 
> Dracut uses pretty 'navive' algorithm to run such command with whenever any
> new device is found - it's added into lvm2 filters of visible device - once
> it succeeds - it can proceed....
> For the 'initramdisk' functionality this is IMHO good enough.
> (Although there are several very ugly hacks in this code we would like to drop...)

That's a nasty hack.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 31. 07. 19 v 11:33 Julian Andres Klode napsal(a):
> On Wed, Jul 31, 2019 at 11:21:10AM +0200, Zdenek Kabelac wrote:
>>> Debian and Ubuntu, as Debian requires support for non-systemd inits, and
>>> Ubuntu requires event-based root device finding in initramfs. Surely that's
> 
> This is nonsense. No Ubuntu release has systemd-based background scanning,
> and all of them work fine. Also, it's still possible to not use backgrounding
> by building lvm2 accordingly - so much for "not working".

lvm2 activation cannot be time-bounded by random udev-rule timeout
(being chosen by systemd/udev developers anywhere between 90-180seconds).

The fact it 'mostly' works is because majority of activations are finished
with this time constrain, but it doesn't make it 'a workable' solution.

So as long as there is 'randomly' killing udev timeout - we can't relocate
activation back into udev rule.

> In our current development series, we did merge the new change to enable
> the background handling from Debian, and this caused our initramfs to fail.

Sorry to say this, we are aware of several other non-upstream accepted 
'workarounds' within Debian lvm2 packages - I can only wish users affected 
with problems caused by these 'hacks' would be asking for repair and recovery 
scenarios only and directly their authors...

> Hence, this approach to revert to the previous behavior where needed (as it
> was clearly working), and still use systemd if available.

When it appears to work on a system with a single disk really doesn't make it 
'clearly working' - we are providing solution for thousands disks based 
heavily loaded servers as well, so there is not much wish to 'hack-in' 
occasionally working fix.

So some other proposal the offloads activation out of udev rule is needed.


Regards

Zdenek

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 31. 07. 19 v 11:39 Julian Andres Klode napsal(a):
>>> I don't see how this has anything to do with lvmetad. There is no lvmetad
>>> anymore.
>>
>> The whole point of 'service' for 'pvscan' is to postone activation of DM
>> devices outside of udev rule processing.
>>
>> So whatever is replacing systemd service in your's systemd-less system must
>> provide similar functionality.
>>
>> There is currently no way to accept autoactivation capability within
>> udev-rule processing.
> 
> This has nothing to do with the part of the message you are replying too, and
> is nonsense. The code to run pvscan directly is shipped, the change just moves
> the decision whether to do that from compile-time to run-time.

As long as 'pvscan' is executed with 'auto-activation' option - it can't be 
run from udev rule.   Any proposal for this needs to first resolve,
how to ensure udev will not try to kill running command in the middle of work.

Until this is resolved - proposal of this can't be accepted upstream.

>> Dracut uses pretty 'navive' algorithm to run such command with whenever any
>> new device is found - it's added into lvm2 filters of visible device - once
>> it succeeds - it can proceed....
>> For the 'initramdisk' functionality this is IMHO good enough.
>> (Although there are several very ugly hacks in this code we would like to drop...)
> 
> That's a nasty hack.

Yes - we are aware it's ugly hack - but compared with complexity of properly
working event based activation - it's does not look so horrible...

Regards


Zdenek

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Julian Andres Klode]

On Wed, Jul 31, 2019 at 12:22:38PM +0200, Zdenek Kabelac wrote:
> Dne 31. 07. 19 v 11:39 Julian Andres Klode napsal(a):
> > > > I don't see how this has anything to do with lvmetad. There is no lvmetad
> > > > anymore.
> > > 
> > > The whole point of 'service' for 'pvscan' is to postone activation of DM
> > > devices outside of udev rule processing.
> > > 
> > > So whatever is replacing systemd service in your's systemd-less system must
> > > provide similar functionality.
> > > 
> > > There is currently no way to accept autoactivation capability within
> > > udev-rule processing.
> > 
> > This has nothing to do with the part of the message you are replying too, and
> > is nonsense. The code to run pvscan directly is shipped, the change just moves
> > the decision whether to do that from compile-time to run-time.
> 
> As long as 'pvscan' is executed with 'auto-activation' option - it can't be
> run from udev rule.   Any proposal for this needs to first resolve,
> how to ensure udev will not try to kill running command in the middle of work.
> 
> Until this is resolved - proposal of this can't be accepted upstream.

Again: The code is already there. I'm just moving the decision what to pick from
compile-time to run-time. This is entirely orthogonal to whether the existing code
works well or not.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Gionatan Danti]

Il 31-07-2019 12:16 Zdenek Kabelac ha scritto:
> When it appears to work on a system with a single disk really doesn't
> make it 'clearly working' - we are providing solution for thousands
> disks based heavily loaded servers as well, so there is not much wish
> to 'hack-in' occasionally working fix.

Not related to the core question - just to ask if you really have 
servers with thousands disks connected...
Is this a (relatively) common scenario, so much to hamper very common 
one/few disks system?
No intention to flame - I am genuinely curious...
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 31. 07. 19 v 12:41 Julian Andres Klode napsal(a):
> On Wed, Jul 31, 2019 at 12:22:38PM +0200, Zdenek Kabelac wrote:
>> Dne 31. 07. 19 v 11:39 Julian Andres Klode napsal(a):
>>>>> I don't see how this has anything to do with lvmetad. There is no lvmetad
>>>>> anymore.
>>>>
>>>> The whole point of 'service' for 'pvscan' is to postone activation of DM
>>>> devices outside of udev rule processing.
>>>>
>>>> So whatever is replacing systemd service in your's systemd-less system must
>>>> provide similar functionality.
>>>>
>>>> There is currently no way to accept autoactivation capability within
>>>> udev-rule processing.
>>>
>>> This has nothing to do with the part of the message you are replying too, and
>>> is nonsense. The code to run pvscan directly is shipped, the change just moves
>>> the decision whether to do that from compile-time to run-time.
>>
>> As long as 'pvscan' is executed with 'auto-activation' option - it can't be
>> run from udev rule.   Any proposal for this needs to first resolve,
>> how to ensure udev will not try to kill running command in the middle of work.
>>
>> Until this is resolved - proposal of this can't be accepted upstream.
> 
> Again: The code is already there. I'm just moving the decision what to pick from
> compile-time to run-time. This is entirely orthogonal to whether the existing code
> works well or not.


So how about making  2 set of  lvm2 packages for Debian.

1st. set build with dependency on systemd libraries.
2nd. is build without dependency on systemd libraries (thus installable for 
non-systemd users)


lvm2 is not (ATM) build with runtime detection of systemd -  it's either 
compiled to work with systemd (expect all the services to be there).

2nd. mode is compilation without systemd world (provided mostly for older
distros).

We do not test 'hybrid' - where lvm2 would be adapting to presence of  systemd 
binaries (and we don't have capacity to test all these combinations)


Regards

Zdenek

Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules

[Zdenek Kabelac]

Dne 31. 07. 19 v 12:51 Gionatan Danti napsal(a):
> Il 31-07-2019 12:16 Zdenek Kabelac ha scritto:
>> When it appears to work on a system with a single disk really doesn't
>> make it 'clearly working' - we are providing solution for thousands
>> disks based heavily loaded servers as well, so there is not much wish
>> to 'hack-in' occasionally working fix.
> 
> Not related to the core question - just to ask if you really have servers with 
> thousands disks connected...
> Is this a (relatively) common scenario, so much to hamper very common one/few 
> disks system?
> No intention to flame - I am genuinely curious...


Yes - we usually learn about these issues in a hard way... ;)
I'd say some users exceeds even our imagination...

Zdenek