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

[josh at joshtriplett.org]

On Fri, Jul 10, 2015 at 09:44:40AM -0700, Josh Triplett wrote:
> On Fri, Jul 10, 2015 at 09:53:01AM +0200, Peter Rajnoha wrote:
> > 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,
> 
> The above are the only such messages I see on each boot.
> 
> > please check if lvm2-lvmetad.socket
> > is enabled (so it can instantiate lvm2-lvmetad.service on
> > first socket access):
> > 
> > systemctl status lvm2-lvmetad.socket
> 
> It's "active (running)" on the booted system.
> 
> > 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...
> 
> I just booted the system again, and the delay seems to have gone away.
> I don't know if that means it's non-deterministic, or if it only happens
> on the first boot after upgrade.  If it's the latter, this is still a
> bug, but not an RC one.

I just saw the bug again; looks like it's non-deterministic.  There was
a delay of more than a minute on lvm2-monitor.service.

- Josh Triplett