See bug 670561 comment #5 cumin-0.1.4478-1.el5 How reproducible: 100% Steps to Reproduce: Variant A: 1. echo CUMIN_OPTIONS="-nonsense" > /etc/sysconfig/cumin 2. service cumin restart Actual results: usage: cumin [options] cumin: error: no such option: -n Expected results: Starting cumin: [FAIL] Variant B: 1. echo CUMIN_OPTIONS="--webs=nonsense" > /etc/sysconfig/cumin 2. service cumin start Actual results: Python traceback Exception: Section [nonsense] not present in configuration files. Expected results: Starting cumin: [FAIL]
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