Bug 672583

On investigation, this is ultimately because the init.d script for cumin calls the daemon function in /etc/init.d/functions as a spawned process.  The return result is therefore not available to /sbin/service.  The daemon function must not be run in another shell; the spawn must be moved downstream into cumin after initial checks.

Additionally, in order for this to work well /usr/bin/cumin needs to parse not only it's own arguments but check any arguments that will be passed to cumin-web and cumin-data for validity.  This can be accomplished with invocations of cumin-web and cumin-data with an --init-only style argument.

Fixed in revision 4538 on trunk.

Implemented as described in Comment 2 above.  Extra invocation from init.d to check options is done if $CUMIN_OPTIONS has been set (default is not set).

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
    The service script does not validate arguments passed to cumin on startup.  It is possible that options specified in /etc/sysconfig/cumin may be erroneous. 

Consequence
    The service script will report OK when the service is started, even though the service may be only partially running or not running at all due to bad arguments.

Fix
    The service script passes arguments to cumin for validation before starting the service.

Result
    The service script will report FAILED if incorrect options are specified for cumin.

If a service returns FAILED, system administrator tends to look
into logs to see what went wrong. Is there any place where the
log of what went wrong during cumin startup could be found?

Working, without log on cumin-0.1.4539-1.el5

Jan,

  Good point.  I will take a look at recording failures to the log.  Currently, no, errors from bad options show up as exceptions or messages printed to stderr.  This was tickling my mind as well :)

Fixed in revision 4542 on truck.

Details, modified tech notes to follow.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,11 +1,11 @@
 Cause
-    The service script does not validate arguments passed to cumin on startup.  It is possible that options specified in /etc/sysconfig/cumin may be erroneous. 
+    The service script starts cumin in a separate process and does not check its return status. 
 
 Consequence
-    The service script will report OK when the service is started, even though the service may be only partially running or not running at all due to bad arguments.
+    The script will report OK when the service is started, even though the service may be only partially running or not running at all due to bad options or other errors on startup.  Additionally, problems occurring before cumin logging is operational will only be apparent from the console window if at all.
 
 Fix
-    The service script passes arguments to cumin for validation before starting the service.
+    Before fully launching cumin, the service script runs the cumin initialization sequence to check for bad options or other problems on startup.  This verifies that cumin will initialize and that logging will be operational when the service is started. 
 
 Result
-    The service script will report FAILED if incorrect options are specified for cumin.+    The service script will report FAILED if incorrect options are specified or other problems on startup are detected before cumin logging becomes operational.

The /usr/bin/cumin script will log to $CUMIN_HOME/log/master.log.  /usr/bin/cumin will return after the first error is detected.  The following error events will be logged:

1) Errors in options to /usr/bin/cumin

2) Extra arguments to /usr/bin/cumin

3) Initialization failures in cumin-web or cumin-data instances, including any output by written by these programs to stderr.  The name of the program is given, along with any arguments passed to identify the instance.  This covers missing configuration sections, too, for example --webs=thisDoesNotExist --datas=NeitherDoesThis.

In addition, the following non-error events are logged by /usr/bin/cumin as it runs:

4) The successful start of a cumin-web or cumin-data instance, including arguments.  This is an INFO level log entry.

5) The restart of a previously started instance.  This is a WARN level log entry.  This happens if an instance is killed manually, or if it exits unexpectedly.  Note, in these cases any details about the exit are the responsbility of the cumin-web or cumin-data instance -- any details should be logged by the instance to its particular log file.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -5,7 +5,7 @@
     The script will report OK when the service is started, even though the service may be only partially running or not running at all due to bad options or other errors on startup.  Additionally, problems occurring before cumin logging is operational will only be apparent from the console window if at all.
 
 Fix
-    Before fully launching cumin, the service script runs the cumin initialization sequence to check for bad options or other problems on startup.  This verifies that cumin will initialize and that logging will be operational when the service is started. 
+    Before fully launching cumin, the service script runs the initialization sequence to check for bad options or other problems.
 
 Result
-    The service script will report FAILED if incorrect options are specified or other problems on startup are detected before cumin logging becomes operational.+    The service script will report FAILED if problems are detected on startup and details will be logged in $CUMIN_HOME/log/master.log.  If no problems are found the service script will report OK.

Verified with cumin-0.1.4554-1.el5

# echo CUMIN_OPTIONS="-nonsense" > /etc/sysconfig/cumin
# service cumin restart
Stopping cumin:                                            [  OK  ]
Starting cumin:                                            [FAILED]
# tail /var/log/cumin/master.log 
8133 2011-02-24 14:44:27,362 INFO Starting: cumin-web --section=web
8133 2011-02-24 14:44:27,399 INFO Starting: cumin-data --section=data
13537 2011-02-24 15:10:29,544 ERROR Error in options
usage: cumin [options]

cumin: error: no such option: -n

# echo CUMIN_OPTIONS="--webs=nonsense" > /etc/sysconfig/cumin
# service cumin start
Starting cumin:                                            [FAILED]
# tail /var/log/cumin/master.log 
  File "/usr/share/cumin/python/cumin/config.py", line 33, in parse
    return self.parse_files(paths)
  File "/usr/share/cumin/python/parsley/config.py", line 24, in parse_files
    values = section.parse(parser)
  File "/usr/share/cumin/python/parsley/config.py", line 46, in parse
    items = parser.items(section)
  File "/usr/lib64/python2.4/ConfigParser.py", line 544, in items
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'nonsense'

Changes to log handling/IO redirection affect this.  Bad options should still be detected, but the output location/content is a little different.  Master log will contain general failure notices, error information will be in $CUMIN_HOME/log/<section_name>.stderr and possibly $CUMIN_HOME/log/<section_name>.stdout.

(started locally, rather than with service)

$ cumin --webs=not_there --init-only

$ more /home/mckay/src/cumin-fedora/cumin/trunk/cumin/instance/log/master.log 
21514 2011-03-03 15:39:30,515 ERROR Usage: cumin [options]

cumin: error: no such option: --nonsense

21646 2011-03-03 15:40:44,457 ERROR Subprocess failed init check: cumin-web --section=not_there --init-only --daemon

$ $ more /home/mckay/src/cumin-fedora/cumin/trunk/cumin/instance/log/not_there.stderr

Traceback (most recent call last):
  File "/home/mckay/src/cumin-fedora/cumin/trunk/cumin/bin/cumin-web", line 57, in main
    config, values, opts, args = get_configuration(CuminWebOptionParser(), CuminWebConfig)
  File "/home/mckay/src/cumin-fedora/cumin/trunk/cumin/python/cumin/config.py", line 179, in get_configuration
    values = config.parse()
  File "/home/mckay/src/cumin-fedora/cumin/trunk/cumin/python/cumin/config.py", line 33, in parse
    return self.parse_files(paths)
  File "/home/mckay/src/cumin-fedora/cumin/trunk/parsley/python/parsley/config.py", line 24, in parse_files
    values = section.parse(parser)
  File "/home/mckay/src/cumin-fedora/cumin/trunk/parsley/python/parsley/config.py", line 46, in parse
    items = parser.items(section)
  File "/usr/lib64/python2.6/ConfigParser.py", line 564, in items
    raise NoSectionError(section)
NoSectionError: No section: 'not_there'

Verified in cumin-0.1.4683-1.el5

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 therefore 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/RHEA-2011-0889.html