Bug#826570: lvm2: erroneously starts lvmetad on upgrade

[Apollon Oikonomopoulos]

Hi,

On Mon, 06 Jun 2016 14:11:54 +0100 Matthew Vernon <mcv21 at cam.ac.uk> 
wrote:
> Hi,
> 
> Last night, my unattended guests upgraded their lvm2 (to the version
> above) as part of an overnight update run. As a result of this,
> lvmetad was started up despite use_lvmetad=0 in lvm.conf, and now lvm
> commands are spitting out warnings of the form:
> 
> WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!
> 
> ...this is giving me a lot of cron mail!
> 
> I think this is most likely the postinst erroneously thinking that
> lvmetad was running and so asking systemd to (re-)start it. I have
> checked my logs, though, and lvmetad hasn't run on this system as far
> back as logs go.
> 

We were bitten by the same issue. This is caused by a set of 
dependencies between lvm systemd services, as follows:

 - lvm2.postinst restarts lvm2-lvmetad.socket. lvm2-lvmetad.service 
   itself is not (re-)started.

 - lvm2-pvscan at .service's, which are already activated via udev, have a 
   Requires=lvm2-lvmetad.socket dependency.

 - When lvm2-lvmetad.socket gets restarted, the pvscan services get 
   restarted as well, trigering `pvscan --cache` which in turn uses the 
   lvmetad socket and causes the lvmetad service to start using socket 
   activation.

I'm not sure what the solution would be here; possible solutions would 
be to either skip restarting the socket (unless the unit file has 
changed between versions), or relax the Requires= dependency to Wants=, 
which will skip the pvscan restarts.

Note that stretch's lvm2 has a completely different way of handling 
pvscan et al, using a systemd generator, so I'm not sure it is affected.

Cheers,
Apollon