* [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
@ 2019-07-25 18:49 Julian Andres Klode
2019-07-30 15:02 ` Zdenek Kabelac
0 siblings, 1 reply; 12+ messages in thread
From: Julian Andres Klode @ 2019-07-25 18:49 UTC (permalink / raw)
To: linux-lvm; +Cc: 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
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-25 18:49 [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules Julian Andres Klode
@ 2019-07-30 15:02 ` Zdenek Kabelac
2019-07-30 15:12 ` Julian Andres Klode
0 siblings, 1 reply; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-30 15:02 UTC (permalink / raw)
To: LVM general discussion and development, Julian Andres Klode
Cc: Julian Andres Klode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-30 15:02 ` Zdenek Kabelac
@ 2019-07-30 15:12 ` Julian Andres Klode
2019-07-31 9:21 ` Zdenek Kabelac
0 siblings, 1 reply; 12+ messages in thread
From: Julian Andres Klode @ 2019-07-30 15:12 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-30 15:12 ` Julian Andres Klode
@ 2019-07-31 9:21 ` Zdenek Kabelac
2019-07-31 9:33 ` Julian Andres Klode
2019-07-31 9:39 ` Julian Andres Klode
0 siblings, 2 replies; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-31 9:21 UTC (permalink / raw)
To: Julian Andres Klode; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 9:21 ` Zdenek Kabelac
@ 2019-07-31 9:33 ` Julian Andres Klode
2019-07-31 10:16 ` Zdenek Kabelac
2019-07-31 9:39 ` Julian Andres Klode
1 sibling, 1 reply; 12+ messages in thread
From: Julian Andres Klode @ 2019-07-31 9:33 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 9:21 ` Zdenek Kabelac
2019-07-31 9:33 ` Julian Andres Klode
@ 2019-07-31 9:39 ` Julian Andres Klode
2019-07-31 10:22 ` Zdenek Kabelac
1 sibling, 1 reply; 12+ messages in thread
From: Julian Andres Klode @ 2019-07-31 9:39 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 9:33 ` Julian Andres Klode
@ 2019-07-31 10:16 ` Zdenek Kabelac
2019-07-31 10:51 ` Gionatan Danti
0 siblings, 1 reply; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-31 10:16 UTC (permalink / raw)
To: LVM general discussion and development, Julian Andres Klode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 9:39 ` Julian Andres Klode
@ 2019-07-31 10:22 ` Zdenek Kabelac
2019-07-31 10:41 ` Julian Andres Klode
0 siblings, 1 reply; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-31 10:22 UTC (permalink / raw)
To: Julian Andres Klode; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 10:22 ` Zdenek Kabelac
@ 2019-07-31 10:41 ` Julian Andres Klode
2019-07-31 11:09 ` Zdenek Kabelac
0 siblings, 1 reply; 12+ messages in thread
From: Julian Andres Klode @ 2019-07-31 10:41 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 10:16 ` Zdenek Kabelac
@ 2019-07-31 10:51 ` Gionatan Danti
2019-07-31 11:12 ` Zdenek Kabelac
0 siblings, 1 reply; 12+ messages in thread
From: Gionatan Danti @ 2019-07-31 10:51 UTC (permalink / raw)
To: LVM general discussion and development; +Cc: Julian Andres Klode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 10:41 ` Julian Andres Klode
@ 2019-07-31 11:09 ` Zdenek Kabelac
0 siblings, 0 replies; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-31 11:09 UTC (permalink / raw)
To: Julian Andres Klode; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
2019-07-31 10:51 ` Gionatan Danti
@ 2019-07-31 11:12 ` Zdenek Kabelac
0 siblings, 0 replies; 12+ messages in thread
From: Zdenek Kabelac @ 2019-07-31 11:12 UTC (permalink / raw)
To: LVM general discussion and development, Gionatan Danti
Cc: Julian Andres Klode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-07-31 11:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-25 18:49 [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules Julian Andres Klode
2019-07-30 15:02 ` Zdenek Kabelac
2019-07-30 15:12 ` Julian Andres Klode
2019-07-31 9:21 ` Zdenek Kabelac
2019-07-31 9:33 ` Julian Andres Klode
2019-07-31 10:16 ` Zdenek Kabelac
2019-07-31 10:51 ` Gionatan Danti
2019-07-31 11:12 ` Zdenek Kabelac
2019-07-31 9:39 ` Julian Andres Klode
2019-07-31 10:22 ` Zdenek Kabelac
2019-07-31 10:41 ` Julian Andres Klode
2019-07-31 11:09 ` Zdenek Kabelac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).