Hi, On Mon, 06 Jun 2016 14:11:54 +0100 Matthew Vernon <[email protected]> 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. - [email protected]'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
