Red Hat Bugzilla – Bug 384461
service: prefix tag surplus clustat clurgmgrd display double
Last modified: 2009-04-16 18:56:01 EDT
From Bugzilla Helper: User-Agent: Opera/9.24 (Windows NT 5.1; U; en) Description of problem: The extra "service:" prefix in clustat prints and clurgmgrd syslogs are unneccessary, and I think it confusing. Imagine one creates an Oracle_service, then wants to check it from command line (creating grep on that etc.): this is how clustat command in RH5.1 behaves: ... Service Name Owner (Last) State ------- ---- ----- ------ ----- service:Oracle_servi machine4.co.uk recovering It not only an unwanted prefix, but it actually cuts user service name to an unreadable lenght. Following this bug's logic why not printing everything in this lame format: "service: Oracle_servi" (-ce) "ownder: machin" (-e4.co.uk) "status: recove" (-ring) ok. you may state that I should grep for clustat -l or -x where these prints are not corrupted, but then: why is the default most common view is such unreadable? Next: looking at /var/log/messages: ... Nov 15 14:32:26 machete3 clurgmgrd[4682]: <notice> Service service:Oralce_service is stopped .. Does this log makes sense? "Service service:<actualname>..." Please remove this prefix, like it was never printed in RHCS4.x Version-Release number of selected component (if applicable): rgmanager-2.0.31-1.el5 How reproducible: Always Steps to Reproduce: 1. clustat 2. grep service: /var/log/messages Actual Results: 1. service:<Myservi 2. Service service:<Myservicename> is stopped. Expected Results: 1. <Myservicename> 2. Service <Myservicename> is stopped. Additional info: Needs only a minor workaround in print and log calls
Created attachment 260141 [details] Alters clustat output. In RHEL5 (and cvs-head), any resource can be managed at the top level by rgmanager. Though almost all benefit from being children of the "service" container resource, none are required to be. Primary attribute namespaces are unique between resource classes. That is, you can have a virtual machine named Myservicename, a service named Myservicename, and a script named Myservicename all at the top level if you wanted. Clustat would thus produce the following output if there was no differentiation: Service Name Owner (Last) State ------- ---- ----- ------ ----- Myservicename machine1 started Myservicename machine2 started Myservicename machine1 started This is clearly a rather confusing prospect. One might argue that 'service' should be treated specially and have it removed from the "normal" output of clustat, and possibly the logs: Service Name Owner (Last) State ------- ---- ----- ------ ----- Myservicename machine1 started vm:Myservicename machine2 started script:Myservicenam machine1 started This might be even more the case since most people are not going to place a script at the top level. Additionally, this would also make it more consistent with 'clusvcadm', since it expands to match 'service:' automatically if you don't specify it on the command line. So, the patch changes default clustat output as noted above, but not log messages.
Created attachment 260171 [details] Corrected patch
Created attachment 260541 [details] Format service status according to terminal width Makes clustat adapt to screen width and also give 10 extra spaces for service names on standard-width (80 column) terminals. Tested on 136x37. In scripts, it defaults to 80x24.
All cluster version 5 defects should be reported under red hat enterprise linux 5 product name - not cluster suite.
Created attachment 270041 [details] More updates. Don't exceed MAXHOSTNAMELEN
Created attachment 270071 [details] Patch with memsets on all string buffers prior to calling snprintf
The patch has been applied to CVS for clustat.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0353.html
Unfortunately the link is wrong, there's no such ERRATA published. Pls. correct