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
```
@David,
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?
Thanks,
_______________________________________________
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/
