Description of problem: An exception on osinfo kdump_status() during getCapabilities is logged with debug level. This won't go to vdsm.log unless as vdsm does not run with debug logs by default anymore. So any issues while detecting the kdump status of the host are not logged in vdsm.log. If an exception is thrown, vdsm will return -1 (UNKNOWN) to the engine while no error is logged at all in vdsm.log. def kdump_status(): try: # check if kdump service is running with open('/sys/kernel/kexec_crash_loaded', 'r') as f: status = int(f.read().strip('\n')) if status == KdumpStatus.ENABLED: # check if fence_kdump is configured status = KdumpStatus.DISABLED with open('/etc/kdump.conf', 'r') as f: for line in f: if line.startswith('fence_kdump_nodes'): status = KdumpStatus.ENABLED break except (IOError, OSError, ValueError): status = KdumpStatus.UNKNOWN ---> logging.debug( 'Error detecting fence_kdump configuration status', exc_info=True, ) return status Version-Release number of selected component (if applicable): vdsm-4.19.43-3.el7ev.x86_64 How reproducible: Always Steps to Reproduce: # chmod 600 /etc/kdump.conf # vdsm-client Host getCapabilities | grep kdumpStatus "kdumpStatus": -1, Actual results: Logs are clean Expected results: Exception logged with ERROR level. Additional info: Enabling DEBUG, I get this. But this requires back and forth on support case. # vdsm-client Host setLogLevel level=DEBUG # vdsm-client Host getCapabilities | grep kdumpStatus 2018-01-09 14:34:32,690+1000 DEBUG (jsonrpc/3) [root] Error detecting fence_kdump configuration status (osinfo:93) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/osinfo.py", line 84, in kdump_status with open('/etc/kdump.conf', 'r') as f: IOError: [Errno 13] Permission denied: '/etc/kdump.conf'
https://gerrit.ovirt.org/#/c/86088/
Verified on vdsm-4.20.14-1.el7ev.x86_64
This scenario is logged in vdsm.log as a warning.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1489
BZ<2>Jira Resync