Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)

[Peter Rajnoha]

On 07/10/2015 01:48 AM, Josh Triplett wrote:
> Package: lvm2
> Version: 2.02.122-1
> Severity: grave
> File: /lib/systemd/system/lvm2-monitor.service
> 
> On a laptop with encrypted root and swap, I now get a minutes-long delay at boot
> time, due to lvm2-monitor.  Here's the complete set of messages at boot
> (transcribed from a photo of the screen):
> 
> Loading, please wait...
>   /run/lvm/lvmetad.socket: connect failed: No such file or directory
>   WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
>   Volume group "data" not found
>   Cannot process volume group data
> Unable to find LVM volume data/root
>   /run/lvm/lvmetad.socket: connect failed: No such file or directory
>   WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
>   Volume group "data" not found
>   Cannot process volume group data
> Unable to find LVM volume data/swap
> Please unlock disk sda2_crypt:
>   /run/lvm/lvmetad.socket: connect failed: No such file or directory
>   WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
>   Reading all physical volumes.  This may take a while...
>   Found volume group "data" using metadata type lvm2
>   /run/lvm/lvmetad.socket: connect failed: No such file or directory
>   WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
>   2 logical volume(s) in volume group "data" now active
> cryptsetup: sda2_crypt set up successfully
> fsck from util-linux 2.26.2
> /dev/mapper/data-root: clean, [...]
> [      ] A start job is running for Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling (59s / no limit)
> 
> 
> That last line matches the description in lvm2-monitor.service.
> 
> (The preceeding lvm2 errors may or may not be related.  The recurring
> two lines of lvmetad errors are new, as is the long delay on
> lvm2-monitor.service; the errors before unlocking the disk about not
> finding data/root and data/swap occurred with previous versions of
> lvm2.)

If initrd is generated, the existing lvm.conf needs to be modified
so the configuration is suitable for initrd environment (where I
suppose lvmetad daemon is not running). So the script generating
initrd needs to modify lvm.conf so that use_lvmetad=0 is used.

In case lvmetad daemon is not running in initrd, which is, I suppose,
exactly the case here - running lvmetad (the LVM metadata caching
daemon) is not quite useful in initrd anyway as lvmetad would need
to be started again after switching to root fs.

So that's probably the first problem here.

If those "falling back to internal scanning" messages appear
even after switching to root fs, please check if lvm2-lvmetad.socket
is enabled (so it can instantiate lvm2-lvmetad.service on
first socket access):

systemctl status lvm2-lvmetad.socket

If it's disabled then the distro needs to make sure it's always
enabled so whenever use_lvmetad=1 is used, the lvm2-lvmetad.service
can be instantiated automatically.

Let's check these things first before debugging the lvm2-monitor.service
delay...

-- 
Peter