linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "heming.zhao@suse.com" <heming.zhao@suse.com>
To: Martin Wilck <mwilck@suse.com>,
	David Teigland <teigland@redhat.com>,
	Peter Rajnoha <prajnoha@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] LVM autoactivation and udev
Date: Mon, 21 Mar 2022 16:57:09 +0800	[thread overview]
Message-ID: <97c2e9f9-0959-c5ed-230a-9d4089577410@suse.com> (raw)
In-Reply-To: <38c190ac39c244d9442670589b7bfeb4f800383e.camel@suse.com>

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


  parent reply	other threads:[~2022-03-24 15:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 15:29 [linux-lvm] LVM autoactivation and udev Martin Wilck
2022-03-09 16:27 ` David Teigland
2022-03-09 17:04   ` Martin Wilck
2022-03-09 17:26     ` David Teigland
2022-03-09 19:48       ` Martin Wilck
     [not found]         ` <1f49866ba907896dc3678b47c5bb68d87e28b3c1.camel@suse.com>
2022-03-09 20:07           ` David Teigland
2022-03-09 17:07   ` Roger Heflin
2022-03-09 17:17     ` Martin Wilck
2022-03-21  8:57 ` heming.zhao [this message]
2022-03-21 16:44   ` David Teigland
2022-03-23  7:33     ` heming.zhao
2022-03-23  7:51       ` Martin Wilck
2022-03-24  8:26         ` heming.zhao
2022-03-24  9:02           ` Martin Wilck
2022-03-24 19:01           ` David Teigland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=97c2e9f9-0959-c5ed-230a-9d4089577410@suse.com \
    --to=heming.zhao@suse.com \
    --cc=linux-lvm@redhat.com \
    --cc=mwilck@suse.com \
    --cc=prajnoha@redhat.com \
    --cc=teigland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).