Hide Forgot
Description of problem: No error or warning appears while starting service if the configuration is erroneous. Version-Release number of selected component (if applicable): since at least rsyslog-4.6.2-3.el6.x86_64.rpm How reproducible: always Steps to Reproduce: 1. Make sure ktah rsyslog-gssapi is not installed 2. configure rsyslog to use im gssapi: $ModLoad imgssapi.so $InputGSSServerRun 514 $InputGSSServerPermitPlainTCP on 3. service rsyslog start Actual results: status is OK even if in log is: Feb 16 12:32:17 rhel62 kernel: imklog 4.6.2, log source = /proc/kmsg started. Feb 16 12:32:17 rhel62 rsyslogd: [origin software="rsyslogd" swVersion="4.6.2" x-pid="12184" x-info="http://www.rsyslog.com"] (re)start Feb 16 12:32:17 rhel62 rsyslogd-2066: could not load module '/lib64/rsyslog/imgssapi.so', dlopen: /lib64/rsyslog/imgssapi.so: cannot open shared object file: No such file or directory [try http://www.rsyslog.com/e/2066 ] Feb 16 12:32:17 rhel62 rsyslogd: the last error occured in /etc/rsyslog.conf, line 79:"$ModLoad imgssapi.so" Feb 16 12:32:17 rhel62 rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Feb 16 12:32:17 rhel62 rsyslogd: the last error occured in /etc/rsyslog.conf, line 80:"$InputGSSServerRun 514" Feb 16 12:32:17 rhel62 rsyslogd-3003: invalid or yet-unknown config file command - have you forgotten to load a module? [try http://www.rsyslog.com/e/3003 ] Feb 16 12:32:17 rhel62 rsyslogd: the last error occured in /etc/rsyslog.conf, line 81:"$InputGSSServerPermitPlainTCP on" Expected results: at least some warrning Additional info:
I'm probably going to close this as WONTFIX. Several reasons for this: - By the time the configuration is parsed, the daemon had already forked and has no access to stderr. The warnings/errors are still logged, though. - The syslogd configuration is rarely changed and the daemon provides an option (-N) to check the configuration file for errors. - If you want the daemon to abort at any sign of misconfiguration, there's a configuration directive: http://www.rsyslog.com/doc/rsconf1_abortonuncleanconfig.html $AboortOnUncleanConfig Available since: 5.3.1+ Default: off - The philosophy of rsyslog is to proceed even if there are errors in the config file as a running syslogd is a vital part of the os. - There's already an older bz arguing this point: https://bugzilla.redhat.com/show_bug.cgi?id=136141 "syntax errors in syslogd.conf cause lost log messages without warning"