Bug 384461 - service: prefix tag surplus clustat clurgmgrd display double
service: prefix tag surplus clustat clurgmgrd display double
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rgmanager (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Lon Hohberger
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2007-11-15 07:05 EST by Ervin Horvath
Modified: 2009-04-16 18:56 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0353
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 10:30:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Alters clustat output. (876 bytes, patch)
2007-11-15 12:44 EST, Lon Hohberger
no flags Details | Diff
Corrected patch (984 bytes, patch)
2007-11-15 13:11 EST, Lon Hohberger
no flags Details | Diff
Format service status according to terminal width (5.38 KB, patch)
2007-11-15 17:42 EST, Lon Hohberger
no flags Details | Diff
More updates. Don't exceed MAXHOSTNAMELEN (9.10 KB, patch)
2007-11-27 13:48 EST, Lon Hohberger
no flags Details | Diff
Patch with memsets on all string buffers prior to calling snprintf (10.08 KB, patch)
2007-11-27 14:03 EST, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Ervin Horvath 2007-11-15 07:05:18 EST
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 

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):

How reproducible:

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
Comment 1 Lon Hohberger 2007-11-15 12:44:42 EST
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
Comment 2 Lon Hohberger 2007-11-15 13:11:18 EST
Created attachment 260171 [details]
Corrected patch
Comment 3 Lon Hohberger 2007-11-15 17:42:27 EST
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.
Comment 4 Kiersten (Kerri) Anderson 2007-11-19 14:57:33 EST
All cluster version 5 defects should be reported under red hat enterprise linux
5 product name - not cluster suite.
Comment 5 Lon Hohberger 2007-11-27 13:48:35 EST
Created attachment 270041 [details]
More updates.  Don't exceed MAXHOSTNAMELEN
Comment 6 Lon Hohberger 2007-11-27 14:03:04 EST
Created attachment 270071 [details]
Patch with memsets on all string buffers prior to calling snprintf
Comment 7 Lon Hohberger 2007-11-30 15:10:18 EST
The patch has been applied to CVS for clustat.
Comment 8 RHEL Product and Program Management 2007-12-17 14:34:50 EST
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
Comment 11 errata-xmlrpc 2008-05-21 10:30:44 EDT
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.

Comment 12 Ervin Horvath 2008-05-22 03:41:43 EDT
Unfortunately the link is wrong, there's no such ERRATA published. Pls. correct

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