Description of problem: Exceptions and error messages are logged to stdout instead of stderr. The stream stdout is buffered. This can produce unexpected results, especially with debugging output. Version-Release number of selected component (if applicable): qpid-tools-0.14-5 How reproducible: 100% Steps to Reproduce: 1. run management tools without broker running 2. realize that the error message was logged to stdout Actual results: Exceptions and error messages are logged to stdout Expected results: Exceptions and error messages are logged to stderr Additional info: # service qpidd status qpidd is stopped # qpid-config 2>/dev/null Failed: error: (111, 'Connection refused') # service qpidd start Starting Qpid AMQP daemon: [ OK ] # qpid-config -a amqps://localhost:5671 --ssl-certificate=cert.pem 2>/dev/null Failed: Exception: Client authentication not supported by this version.
Created attachment 879838 [details] proposed patch note: the patch also removes extra trailing spaces
Comment on attachment 879838 [details] proposed patch This works well for qpid-config. We'll need to make similar changes to the other python tools. You might consider using the new print function syntax: from __future__ import print_function and adding a function: def print_stderr(str): print(str, file=sys.stderr) and then calling print_stderr() whenever you explicity want to print to stderr. The pros of doing this are - It is future-proof in that it is the recommended way for python 2.x and 3.x - Calling a function named print_stderr is self-documenting The big con of doing this is that all print statements would need to be changed to print functions. See http://docs.python.org/3.0/whatsnew/3.0.html#print-is-a-function
(In reply to Ernie from comment #5) > Comment on attachment 879838 [details] > proposed patch > > This works well for qpid-config. We'll need to make similar changes to the > other python tools. > > You might consider using the new print function syntax: > from __future__ import print_function > and adding a function: > def print_stderr(str): > print(str, file=sys.stderr) > > and then calling print_stderr() whenever you explicity want to print to > stderr. > The pros of doing this are > - It is future-proof in that it is the recommended way for python 2.x and 3.x > - Calling a function named print_stderr is self-documenting > > The big con of doing this is that all print statements would need to be > changed to print functions. > > See http://docs.python.org/3.0/whatsnew/3.0.html#print-is-a-function Unfortunately, I don't think we can use print_function. It appears to have become available in python 2.6, and el5 is python 2.4.
(In reply to Justin Ross from comment #6) > (In reply to Ernie from comment #5) > > Comment on attachment 879838 [details] > > proposed patch > > > > This works well for qpid-config. We'll need to make similar changes to the > > other python tools. > > > > You might consider using the new print function syntax: > > from __future__ import print_function > > and adding a function: > > def print_stderr(str): > > print(str, file=sys.stderr) > > > > and then calling print_stderr() whenever you explicity want to print to > > stderr. > > The pros of doing this are > > - It is future-proof in that it is the recommended way for python 2.x and 3.x > > - Calling a function named print_stderr is self-documenting > > > > The big con of doing this is that all print statements would need to be > > changed to print functions. > > > > See http://docs.python.org/3.0/whatsnew/3.0.html#print-is-a-function > > Unfortunately, I don't think we can use print_function. It appears to have > become available in python 2.6, and el5 is python 2.4. Eeks, my mistake. This is targeted for versions of RHEL > 5, so Ernie's advice stands.
Actually it shall be addressed in both 2.x and 3.x, so leaving this bug tracking 2.x defect and cloning for 3.x.