Bug 1462792 - RHV-H - systemd: Cannot add dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.
RHV-H - systemd: Cannot add dependency job for unit lvm2-lvmetad.socket, igno...
Status: NEW
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
4.1.2
Unspecified Unspecified
medium Severity medium
: ovirt-4.3.0
: ---
Assigned To: Nir Soffer
Raz Tamir
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-19 10:33 EDT by Marian Jankular
Modified: 2017-11-15 10:45 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-27 07:45:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marian Jankular 2017-06-19 10:33:37 EDT
Description of problem:
during rhvh boot following message appears
"systemd: Cannot add dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked."

Version-Release number of selected component (if applicable):
redhat-release-virtualization-host-4.1-2.1.el7.x86_64
version below 4.1-2 as well

How reproducible:
everytime

Steps to Reproduce:
1. install rhvh
2. boot it
3. check /var/log/messages

Actual results:
systemd: Cannot add dependency job for unit lvm2-lvmetad.socket, ignoring: Unit is masked.

Expected results:
as lvm2-lvmetad is disabled i would expect that is would not be as any dependency for service

Additional info:
Comment 1 Sandro Bonazzola 2017-06-20 05:39:14 EDT
Nir, is there any functional implication here other than the warning?
Comment 2 Nir Soffer 2017-06-20 05:46:54 EDT
This bug should move to lvm. I don't
know why lvm is logging warnings about
disabled and msaked service.
Comment 3 Sandro Bonazzola 2017-06-27 05:41:35 EDT
Nir, moving to you,, can you please handle the move to lvm?
Comment 5 Peter Rajnoha 2017-06-27 07:45:26 EDT
Please, do not mask lvm2-lvmetad.socket - it's used by lvm2-lvmetad.service and also referenced in various other systemd units and you would need to mask them too for this to be complete (but you don't need to this at all).

If you disable lvmetad in lvm.conf (use_lvmetad=0), then lvm tools will not use lvmetad and hence they won't initiate a connection through lvmetad socket. So there's no gain in masking the lvm2-lvmetad.socket - it's simply not used. Just keep the lvm2-lvmetad.socket as it is, do not mask it please.
Comment 6 Nir Soffer 2017-06-27 07:59:34 EDT
Thanks Peter, moving the bug to vdsm, we will change the configuration.
Comment 9 Nir Soffer 2017-06-27 08:01:51 EDT
Tal, this should be a trivial change, do you want to schedule it to 4.1.4?
Comment 10 Allon Mureinik 2017-06-27 09:01:22 EDT
(In reply to Nir Soffer from comment #9)
> Tal, this should be a trivial change, do you want to schedule it to 4.1.4?

If it's really that trivial, yes please.
We should strive to fix bugs with customer tickets as early as possible.
Comment 12 Allon Mureinik 2017-07-02 16:38:09 EDT
4.1.4 is planned as a minimal, fast, z-stream version to fix any open issues we may have in supporting the upcoming EL 7.4.

Pushing out anything unrelated, although if there's a minimal/trival, SAFE fix that's ready on time, we can consider introducing it in 4.1.4.
Comment 16 Klaas Demter 2017-10-24 10:44:37 EDT
is it safe to manually do the suggested changes?
use_lvmetad=0 in lvm.conf and unmask lvm2-lvmetad.socket? I would like to get rid of the systemd error messages
Comment 17 Nir Soffer 2017-10-24 12:11:24 EDT
(In reply to Klaas Demter from comment #16)
> is it safe to manually do the suggested changes?
> use_lvmetad=0 in lvm.conf and unmask lvm2-lvmetad.socket? I would like to
> get rid of the systemd error messages

Peter, can you answer that?

Based on https://www.redhat.com/archives/lvm-devel/2017-October/msg00035.html,
I think this should be solved by LVM. I feel safer when lvmetad *cannot* run
or be auto-activated and use_lvmetad is disabled in lvm.conf.
Comment 18 Peter Rajnoha 2017-11-01 11:06:41 EDT
This should be working already (if not, please let me know the lvm version + attach the -vvvv output from the LVM command which causes the lvmetad to get instantiated even if use_lvmetad=0 is set):

● lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lvmetad(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/lvm2-lvmetad.service

[0] raw/~ # lvmconfig --type current global/use_lvmetad
use_lvmetad=0

[0] raw/~ # pvscan --cache

[0] raw/~ # systemctl status lvm2-lvmetad
● lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lvmetad(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/lvm2-lvmetad.service

[0] raw/~ # pvs
...

[0] raw/~ # vgs
...

[0] raw/~ # lvs
...

[0] raw/~ # systemctl status lvm2-lvmetad
● lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; static; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:lvmetad(8)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/lvm2-lvmetad.service
Comment 19 Klaas Demter 2017-11-03 05:25:43 EDT
So that means it is safe to do the changes manually for my running rhev hypervisors and you can incorporate those changes into 4.2? :)
Comment 20 Klaas Demter 2017-11-03 05:52:44 EDT
to answer my own question: I've tested it on a test hypervisor, vdsmd checks the service on startup so its not enough to simply change the config and unmask the lvm2-lvmetad.service

Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: Error:
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: One of the modules is not configured to work with VDSM.
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: To configure the module use the following:
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: 'vdsm-tool configure [--module module-name]'.
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: If all modules are not configured try to use:
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: 'vdsm-tool configure --force'
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: (The force flag will stop the module's service and start it
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: afterwards automatically to load the new configuration.)
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: abrt is already configured for vdsm
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: Units need configuration: {'lvm2-lvmetad.service': {'LoadState': 'loaded', 'ActiveState': 'inactive'}}
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: lvm requires configuration
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: libvirt is already configured for vdsm
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: Current revision of multipath.conf detected, preserving
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: Modules lvm are not configured
Nov 03 10:40:57 rhev-hypervisor.example.com vdsmd_init_common.sh[3103]: vdsm: stopped during execute check_is_configured task (task returned with error code 1).
Nov 03 10:40:57 rhev-hypervisor.example.com systemd[1]: vdsmd.service: control process exited, code=exited status=1
Comment 22 Nir Soffer 2017-11-07 06:55:00 EST
(In reply to Klaas Demter from comment #20)
> to answer my own question: I've tested it on a test hypervisor, vdsmd checks
> the service on startup so its not enough to simply change the config and
> unmask the lvm2-lvmetad.service

vdsm requires that the lvm2-lvmetad service and socket are masked and disabled.
You will have to disable this check by modifying
/usr/lib/python2.7/site-packages/vdsm/tool/configurators/lvm.py.
Comment 24 Klaas Demter 2017-11-07 08:32:49 EST
Is there a change proposed for this issue or is it still being evaluated?
Comment 25 Nir Soffer 2017-11-07 16:39:08 EST
(In reply to Klaas Demter from comment #24)
> Is there a change proposed for this issue or is it still being evaluated?

Waiting for evaluation. How bad is the extra logging caused by this issue?
Comment 26 Klaas Demter 2017-11-08 02:10:18 EST
(In reply to Nir Soffer from comment #25)
> (In reply to Klaas Demter from comment #24)
> > Is there a change proposed for this issue or is it still being evaluated?
> 
> Waiting for evaluation. How bad is the extra logging caused by this issue?

Hi Nir,
the log volume is not that bad, it's a single line but it gets logged every day once per hypervisor. The problem for me is that I have to start ignoring messages in my monitoring that I would rather not just turn off :)

I could add the specific warning to a white list but I buy rhv so that our problems get fixed properly.

Greetings
Klaas

Note You need to log in before you can comment on or make changes to this bug.