Bug 824378 - Logging in sosGetCommandOutput in helpers.py is broken
Logging in sosGetCommandOutput in helpers.py is broken
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sos (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Bryn M. Reeves
David Kutálek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-23 07:25 EDT by David Kutálek
Modified: 2013-02-21 05:58 EST (History)
5 users (show)

See Also:
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 05:58:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Kutálek 2012-05-23 07:25:20 EDT
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 09:24:21 EDT
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 Product and Program Management 2012-07-10 04:46:42 EDT
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 Product and Program Management 2012-07-10 21:58:42 EDT
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 09:55:06 EST
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 05:58:04 EST
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

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