This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1274063 - vdsm fails to start due to incorrect permissions on /tmp/ovirt.log
vdsm fails to start due to incorrect permissions on /tmp/ovirt.log
Status: CLOSED NEXTRELEASE
Product: vdsm
Classification: oVirt
Component: General (Show other bugs)
---
x86_64 Linux
urgent Severity urgent (vote)
: ovirt-3.6.1
: 4.17.11
Assigned To: Dan Kenigsberg
Meni Yakove
network
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-21 15:42 EDT by Ivan Bulatovic
Modified: 2016-02-10 14:17 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-18 05:49:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
danken: ovirt‑3.6.z?
danken: ovirt‑4.0.0?
rule-engine: planning_ack?
fdeutsch: devel_ack+
rule-engine: testing_ack?


Attachments (Terms of Use)
chown the /tmp/ovirt.log (457 bytes, patch)
2015-10-22 14:48 EDT, Ivan Bulatovic
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 47829 master MERGED utils: replace import for persist/unpersist Never
oVirt gerrit 47968 ovirt-3.6 MERGED utils: replace import for persist/unpersist Never

  None (edit)
Description Ivan Bulatovic 2015-10-21 15:42:53 EDT
Description of problem:

On a clean install from ovirt-3.6-snapshot repo, vdsm fails to start during hosted-engine deployment or adding a node to the existing engine.

systemctl status vdsmd.service:

Process: 25532 ExecStart=/usr/share/vdsm/daemonAdapter -0 /dev/null -1 /dev/null -2 /dev/null /usr/share/vdsm/vdsm (code=exited, status=1/FAILURE)
 Main PID: 25532 (code=exited, status=1/FAILURE);         : 25577 (vdsmd_init_comm)

Snip from /var/log/mom.log

2015-10-21 21:19:04,556 - mom - INFO - MOM starting
2015-10-21 21:19:04,581 - mom.HostMonitor - INFO - Host Monitor starting
2015-10-21 21:19:04,581 - mom - INFO - hypervisor interface vdsmxmlrpc
2015-10-21 21:19:07,372 - mom - ERROR - Failed to initialize MOM threads
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run
    hypervisor_iface = self.get_hypervisor_interface()
  File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 216, in get_hypervisor_interface
    module = __import__('mom.HypervisorInterfaces.' + name + 'Interface', None, None, name)
  File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmxmlrpcInterface.py", line 24, in <module>
    from vdsm import vdscli
  File "/usr/lib/python2.7/site-packages/vdsm/vdscli.py", line 29, in <module>
    from . import sslutils
  File "/usr/lib/python2.7/site-packages/vdsm/sslutils.py", line 28, in <module>
    from vdsm.utils import (
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 66, in <module>
    from ovirtnode import ovirtfunctions
  File "/usr/lib/python2.7/site-packages/ovirtnode/ovirtfunctions.py", line 1867, in <module>
    logger = setup_custom_logger()
  File "/usr/lib/python2.7/site-packages/ovirtnode/ovirtfunctions.py", line 1858, in setup_custom_logger
    handler = logging.FileHandler(log_file)
  File "/usr/lib64/python2.7/logging/__init__.py", line 902, in __init__
    StreamHandler.__init__(self, self._open())
  File "/usr/lib64/python2.7/logging/__init__.py", line 925, in _open
    stream = open(self.baseFilename, self.mode)
IOError: [Errno 13] Permission denied: '/tmp/ovirt.log'

Changing permissions from root:root to vdsm:kvm on /tmp/ovirt.log fixes the issue, and vdsm starts successfully.

Selinux is in permissive mode, but it was enforced during the installation of the components (no denials from the logs as far as I can tell).

Version-Release number of selected component (if applicable):

vdsm-4.17.9-15.git1a7d1d3.el7.noarch
mom-0.5.1-2.el7.noarch
ovirt-node-3.3.0-0.14.ovirt36.20151012220735.git5f84da0.el7
Comment 2 Dan Kenigsberg 2015-10-22 07:18:33 EDT
Apparently, the mere

   from ovirtnode import ovirtfunctions

logs onto /tmp/ovirt.log.

If the first import happened to be in root context, we'd get this error.
Comment 3 Red Hat Bugzilla Rules Engine 2015-10-22 07:18:36 EDT
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 5 Ivan Bulatovic 2015-10-22 14:48 EDT
Created attachment 1085643 [details]
chown the /tmp/ovirt.log

When I remove ovirt.log from the tmp directory and reboot, vdsm starts successfully. Supervdsmd creates the temporary log file with root privileges, and when vdsm starts with user privileges, it changes ownership of /tmp/ovirt.log to vdsm:kvm.
Comment 6 Fabian Deutsch 2015-10-23 03:15:32 EDT
This is an relict from old ovirt-node times.
The logging is setup when ovirtnode.ovirtfunctions is getting imported, which is not good.

Normally the import happens because of persistence, in that case ovirt.node.utils.fs.Config can be used these days, which should not suffer the import problems.
Comment 7 Red Hat Bugzilla Rules Engine 2015-10-23 06:06:53 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 8 Ivan Bulatovic 2015-10-23 14:44:20 EDT
(In reply to Fabian Deutsch from comment #6)
> 
> Normally the import happens because of persistence, in that case
> ovirt.node.utils.fs.Config can be used these days, which should not suffer
> the import problems.

Yes, forcing import from ovirt.node.utils.fs (commenting out importing from ovirtnode) in vdsm/utils.py does not prevent mom-vdsm and vdsm units from starting anymore.

Thanks Fabian, I caught this by accident, thought I should report it (even though I don't fully understand implications of it all, yet).
Comment 9 Fabian Deutsch 2015-11-03 06:17:12 EST
Ivan, cool, nice to hear that it worked.
Comment 10 Fabian Deutsch 2015-11-03 06:18:39 EST
Moving this over to vdsm where the patch resides.

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