Bug 877349 - it should be possible to start corosync-notifyd without editing (nonexisting) /etc/sysconfig/corosync-notifyd
it should be possible to start corosync-notifyd without editing (nonexisting)...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: corosync (Show other bugs)
6.4
Unspecified Unspecified
medium Severity low
: rc
: ---
Assigned To: Jan Friesse
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-16 05:28 EST by Jaroslav Kortus
Modified: 2013-11-20 23:31 EST (History)
3 users (show)

See Also:
Fixed In Version: corosync-1.4.1-16.el6
Doc Type: Bug Fix
Doc Text:
Cause: User tries to execute corosync-notifyd service without configuration. Consequence: service fails Fix: Add default /etc/sysconfig/corosync-notifyd. Result: service corosync-notifyd start works for fresh installed package without any additional configuration.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-20 23:31:51 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)
Proposed patch - part 1 - Improve corosync-notifyd example (1018 bytes, patch)
2013-04-16 11:06 EDT, Jan Friesse
no flags Details | Diff
Proposed patch - part 2 - Install sysconfig/corosync-notifyd in specfile (1.23 KB, patch)
2013-04-16 11:07 EDT, Jan Friesse
no flags Details | Diff

  None (edit)
Description Jaroslav Kortus 2012-11-16 05:28:43 EST
Description of problem:
To actually be able to start corosync-notifyd without red FAIL one must do action similar to this:
echo "OPTIONS=\"-d\" " > /etc/sysconfig/corosync-notifyd

This should have been by default and user should be guided in comments in /etc/sysconfig/corosync-notifyd how to change this (dbus vs snmp).

If sysconfig file cannot be provided, then the init script should be changed to include one of the usable options by default.

Status message would probably be also welcome (either to stdout during service start and/or to syslog).

Version-Release number of selected component (if applicable):
corosync-1.4.1-11.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. clean install
2. /etc/rc.d/init.d/corosync-notifyd start
3.
  
Actual results:
Starting Corosync Notifier (corosync-notifyd):             [FAILED]
Syslog:
Nov 16 04:11:36 marathon-03c1-node01 corosync-notifyd[21286]: no event type enabled, see corosync-notifyd -h, exiting.


Expected results:
service starts with reasonable defaults


Additional info:
Comment 2 Jan Friesse 2012-11-19 02:44:39 EST
(In reply to comment #0)
> Description of problem:
> To actually be able to start corosync-notifyd without red FAIL one must do
> action similar to this:
> echo "OPTIONS=\"-d\" " > /etc/sysconfig/corosync-notifyd
> 
> This should have been by default and user should be guided in comments in
> /etc/sysconfig/corosync-notifyd how to change this (dbus vs snmp).
> 

Agree

> If sysconfig file cannot be provided, then the init script should be changed
> to include one of the usable options by default.
> 
> Status message would probably be also welcome (either to stdout during
> service start and/or to syslog).
> 

???? As you noted later, there is "no event type enabled, see corosync-notifyd -h, exiting." message in syslog. What you mean by this requirement?
Comment 3 Jaroslav Kortus 2012-11-19 05:10:22 EST
> > If sysconfig file cannot be provided, then the init script should be changed
> > to include one of the usable options by default.
> > 
> > Status message would probably be also welcome (either to stdout during
> > service start and/or to syslog).
> > 
> 
> ???? As you noted later, there is "no event type enabled, see
> corosync-notifyd -h, exiting." message in syslog. What you mean by this
> requirement?

Something like "Using dbus for notifications. Use /etc/sysconfig/corosync-notifyd for override."?
Comment 5 Jan Friesse 2013-04-16 11:06:32 EDT
Created attachment 736371 [details]
Proposed patch - part 1 - Improve corosync-notifyd example

Example now contains default option -d, so corosync-notifyd init script don't fall. Also description is improved a little bit.
Comment 6 Jan Friesse 2013-04-16 11:07:02 EDT
Created attachment 736381 [details]
Proposed patch - part 2 - Install sysconfig/corosync-notifyd in specfile
Comment 7 Jan Friesse 2013-04-16 11:16:46 EDT
(In reply to comment #3)
> > > If sysconfig file cannot be provided, then the init script should be changed
> > > to include one of the usable options by default.
> > > 
> > > Status message would probably be also welcome (either to stdout during
> > > service start and/or to syslog).
> > > 
> > 
> > ???? As you noted later, there is "no event type enabled, see
> > corosync-notifyd -h, exiting." message in syslog. What you mean by this
> > requirement?
> 
> Something like "Using dbus for notifications. Use
> /etc/sysconfig/corosync-notifyd for override."?

I don't think this is really achievable in consistent way. First of all, from upstream point of view, corosync-notifyd init script is just init script. It's possible to run corosync-notifyd without that. And second problem is, what about debian? They have /etc/defaults (not /etc/sysconfig) so it mean to hack ether init script to display these message what means to parse OPTIONS what is just overkill (and extra useless work effort) or corosync-notifyd.c source code where we are back to /etc/defaults vs. /etc/sysconfig problem.

Also I don't think such message is extremely useful. With patch 1, -d is now default so corosync-notifyd is started and works. Other then that is really about common sense (like almost all of daemons in RHEL has config in /etc/sysconfig/daemon_name) or documentation.
Comment 14 Jaroslav Kortus 2013-09-11 10:47:02 EDT
# service corosync-notifyd start
Starting Corosync Notifier (corosync-notifyd): [  OK  ]
#

Config file present in /etc/sysconfig/corosync-notifyd
Verified with corosync-1.4.1-17.el6.x86_64. Thank you.
Comment 16 errata-xmlrpc 2013-11-20 23:31:51 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-1531.html

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