[linux-lvm] LVM autoactivation and udev

heming.zhao at suse.com heming.zhao at suse.com
Mon Mar 21 08:57:09 UTC 2022

On 3/9/22 23:29, Martin Wilck wrote:
> Hi David, hi Peter,
> we have recently updated LVM2 on openSUSE Factory, and are using the
> autoactivation feature now. We also use
> 'external_device_info_source="udev"' by default, because according to
> our experience it is the only way to make LVM device detection work
> reliably with multipath devices.
> With these settings, we see lots of "Udev database has incomplete
> information about device ..." messages:
>> [   12.377563] apollon systemd-udevd[810]: sda5: Processing device (SEQNUM=2787, ACTION=add)
>> [   12.412723] apollon systemd-udevd[810]: sda5: /usr/lib/udev/rules.d/69-dm-lvm.rules:82 Importing properties from results of '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
>> [   12.412767] apollon systemd-udevd[810]: sda5: Starting '/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output /dev/sda5'
>> [   12.413041] apollon systemd-udevd[810]: Successfully forked off '(spawn)' as PID 882.
>> [   12.419458] apollon lvm[882]: Udev database has incomplete information about device /dev/sda5.
> This is no surprise, because 69-dm-lvm.rules contains
> IMPORT{program}="/usr/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --autoactivation event --udevoutput --journal=output $env{DEVNAME}"
> ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} (LVM_EXEC)/lvm vgchange -aay --autoactivation event $env{LVM_VG_NAME_COMPLETE}"
> These rules are executed by udev while it is processing an "add" event
> for a PV. At that time, the udev data base doesn't contain an entry for
> this PV yet, because the entry is added only after the uevent is fully
> processed.
> Shouldn't "pvscan" be run in a RUN+= statement instead? Obviously if we
> do this, the lvm-activate-$VG unit must be started in some other way
> (e.g. by calling systemd-run directly from pvscan).
> In the cases we have observed so far, the VGs were assembled correctly
> despite these warnings. We aren't certain if this was by luck only. In
> any case, the messages irritate users.
> Or are we getting this completely wrong, and the new autoactivation
> feature should not be used with external_device_info_source="udev" at
> all? If that's the case, how is multipath component detection supposed
> to work?
> Regards,
> Martin

I make a branch for this topic.
Original topic focused on pvscan & udev in booting phase.
We (Martin & I) watched another issue, lvm2-monitor.service reported similar libudev error.
(the lvm2 version is latest 2.03.15+). the monitor issue was still related with libudev
not ready. log:

Mar 10 10:27:54 Mobile-PC systemd[1]: Stopped target Local File Systems.
Mar 10 10:27:55 Mobile-PC systemd[1]: Reached target Local File Systems.
Mar 10 10:27:55 Mobile-PC lvm[658]:   Udev database has incomplete information about device /dev/nvme0n1.
Mar 10 10:27:55 Mobile-PC lvm[658]:   /dev/nvme0n1: Failed to get external handle [udev].
Mar 10 10:27:55 Mobile-PC lvm[658]:   Udev database has incomplete information about device /dev/sda.
Mar 10 10:27:55 Mobile-PC lvm[658]:   /dev/sda: Failed to get external handle [udev].

In my understand, lvm2-monitor.service does the "clean up" job, which will complete the
monitor job for thin/mirror/others LVs, which was created during initrd phase. (because
lvm_scan doesn't have ability to start monitoring.)
on current lvm2-monitor.service, the dependency asks this service start as early as possible:
After=dm-event.socket dm-event.service
It makes monitor service start too early, and triggers libudev not ready issue.

To fix above issue, we find a workaround:
- After=dm-event.socket dm-event.service
+ After=dm-event.socket dm-event.service sysinit.target

And maybe there is another workaround (not verify):
-ExecStart=@SBINDIR@/lvm vgchange --monitor y

+ExecStart=@SBINDIR@/lvm vgchange --config 'devices { external_device_info_source="none" \
obtain_device_list_from_udev=0}' --monitor y

What's your opinion about the lvm2-monitor.service udev problem?
Could you mind to give some explain why lvm2-monitor.service is started so early?


More information about the linux-lvm mailing list