[linux-lvm] [PATCH 1/1] pvscan: wait for udevd

[heming.zhao at suse.com]

On 2/17/21 4:22 PM, Martin Wilck wrote:
> On Wed, 2021-02-17 at 09:49 +0800, heming.zhao at suse.com wrote:
>> On 2/11/21 7:16 PM, Christian Hesse wrote:
>>> From: Christian Hesse <mail at eworm.de>
>>>
>>> Running the scan before udevd finished startup may result in
>>> failure.
>>> This has been reported for Arch Linux [0] and proper ordering fixes
>>> the issue.
>>>
>>> [0] https://bugs.archlinux.org/task/69611
>>>
>>> Signed-off-by: Christian Hesse <mail at eworm.de>
>>> ---
>>>    scripts/lvm2-pvscan.service.in | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/scripts/lvm2-pvscan.service.in b/scripts/lvm2-
>>> pvscan.service.in
>>> index 09753e8c9..7b4ace551 100644
>>> --- a/scripts/lvm2-pvscan.service.in
>>> +++ b/scripts/lvm2-pvscan.service.in
>>> @@ -4,6 +4,7 @@ Documentation=man:pvscan(8)
>>>    DefaultDependencies=no
>>>    StartLimitIntervalSec=0
>>>    BindsTo=dev-block-%i.device
>>> +After=systemd-udevd.service
>>>    Before=shutdown.target
>>>    Conflicts=shutdown.target
>>>    
>>>
>>
>> I watched a similar issue with lvm2-monitor.service.
>> In a very old machine (i586), udevd cost too much time to finish, it
>> triggered
>> lvm2-monitor timeout then reported:
>>> WARNING: Device /dev/sda not initialized in udev database even
>>> after waiting 10000000 microseconds.
>>
>> One workable solution is to add "systemd-udev-settle.service"
>> (obsoleted) or
>> "local-fs.target" in "After" of lvm2-monitor.service.
> 
> We have to differentiate here. In our case we had to wait for "systemd-
> udev-settle.service". In the arch case, it was only necessary to wait
> for systemd-udevd.service itself. "After=systemd-udevd.service" just
> means that the daemon is up, it says nothing about any device
> initialization being completed.
> 
> But in general, I think this needs deeper analysis. Looking at
> https://bugs.archlinux.org/task/69611, the workaround appears to have
> been found simply by drawing an analogy to a previous similar case.
> I'd like to understand what happened on the arch system when the error
> occured, and why this simple ordering directive avoided it.
> 
> 1. How had the offending pvscan process been started? I'd expect that
> "pvscan" (unlike "lvm monitor" in our case) was started by an udev
> rule. If udevd hadn't started yet, how would that udev rule have be
> executed? OTOH, if pvscan had not been started by udev but by another
> systemd service, than *that* service would probably need to get the
> After=systemd-udevd.service directive.
> 
> 2. Even without the "After=" directive, I'd assume that pvscan wasn't
> started "before" systemd-udevd, but rather "simultaneously" (i.e. in
> the same systemd transaction). Thus systemd-udevd should have started
> up while pvscan was running, and pvscan should have noticed that udevd
> eventually became available. Why did pvscan time out? What was it
> waiting for? We know that lvm checks for the existence of
> "/run/udev/control", but that should have become avaiable after some
> fractions of a second of waiting.
> 
> Regards,
> Martin
> 
> 

Hello Martin,

You've got a point there. The arch issue needs a full boot log to analyze.
My reply in previous mail didn't agree his patch, it just described the
watching and I wanted to give lvm maintainers some other info about
lvm2-monitor.service.

Thanks,
Heming