Bug 824378

Summary: Logging in sosGetCommandOutput in helpers.py is broken
Product: Red Hat Enterprise Linux 6 Reporter: David Kutálek <dkutalek>
Component: sosAssignee: Bryn M. Reeves <bmr>
Status: CLOSED ERRATA QA Contact: David Kutálek <dkutalek>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3CC: agk, bmr, ddumas, gavin, prc
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sos-2.2-35.el6 Doc Type: Bug Fix
Doc Text:
Cause: Sos did not log errors when attempting to collect output from external commands due to changes in the logging design in earlier releases. Consequence: No message was written to the sos log file when an external command could not be executed. Fix: The logging is now carried out in the core plug-in code. Result: Failure to execute an external program is now correctly logged.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-21 10:58:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Kutálek 2012-05-23 11:25:20 UTC
Description of problem:

# grep -n soslog /usr/lib/python2.6/site-packages/sos/helpers.py
44:    # soslog = logging.getLogger('sos')
53:        # soslog.log(logging.VERBOSE, "binary '%s' does not exist or is not runnable" % cmdfile)

So effectively sosGetCommandOutput() does not log at all. It is called from plugintools.py and devicemapper.py.

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

sos-2.2-27.el6.noarch

How reproducible:

Always

Steps to Reproduce:
1. see above
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Bryn M. Reeves 2012-05-28 13:24:21 UTC
I think I have this fixed now. It ended up touching a lot more files than helpers.py however so I think it was the right decision to drop this for 6.3:

# gendiff . .orig | diffstat
 helpers.py              |   26 ++++++++++++--------------
 plugins/autofs.py       |    4 ++--
 plugins/devicemapper.py |    3 +--
 plugins/xen.py          |    4 ++--
 plugintools.py          |    3 ++-
 5 files changed, 19 insertions(+), 21 deletions(-)

In addition to the problem in helpers itself (which could only be fixed by moving the log output to the wrapper in plugintools - there is no log context made available to the helper functions) fixing this exposed a bunch of modules that were using relative paths and a bug in the handling of relative paths passed to sosGetCommandOutput().

This should all now work as expected although tbh I am still not happy with this part of sos: the function names are weird (sosGetCommandOuput to me sounds like an external API name only, that's actually callExtProg..).

Comment 2 RHEL Program Management 2012-07-10 08:46:42 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 RHEL Program Management 2012-07-11 01:58:42 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 12 Bryn M. Reeves 2013-01-09 14:55:06 UTC
Rather than have devicemapper deal with the raw status stuff returned from sosGetCommandOutput() I'd rather convert it to use the Plugin API (callExtProg()) - this causes it to use the common status checking code there rather than having each plugin do this (really plugins should never use those helpers directly).

If you move or remove /sbin/lvmdump the devicemapper module now logs:

2013-01-09 10:59:30,081 INFO: could not run 'lvmdump -d /tmp/rhel6-vm2-2013010910591357729169/lvmdump'

Comment 16 errata-xmlrpc 2013-02-21 10:58:04 UTC
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.

http://rhn.redhat.com/errata/RHBA-2013-0474.html