Description of problem: The $IncludeConfig behavior of rsyslog is wrong. It seems that $IncludeConfig is handled before adding the rule into the rule set. When doing the following reproducer, this is because the followings happen inside the rsyslog. 1. The "local1.*" rule is created. 2. After adding the "local1.*" rule into the rule list, the "local2.*" rule is created. 3. /etc/rsyslog.conf.sub started to be read. 4. The "local5.*" rule is created. 5. After adding the "local5.*" rule into the rule list, the ":fromhost-ip" rule is created. 6. After reading /etc/rsyslog.conf.sub, the ":fromhost-ip" rule is added into the rule list. 7. The "local2.*" rule is added into the rule list. The order is different from the one the local2.* rule describes, so (something) is set at the end of the list, and the log is not printed by the previous ":fromhost-ip" rule. Version-Release number of selected component (if applicable): - rsyslog-4.6.2 How reproducible: always Steps to Reproduce: As for the rsyslog setting, I described the followings for example. /etc/rsyslog.conf -------------------------------------------- local1.* /var/log/local1.log local2.* /var/log/local2.log $IncludeConfig /etc/rsyslog.conf.sub -------------------------------------------- /etc/rsyslog.conf.sub -------------------------------------------- local5.* /var/log/local5.log :fromhost-ip, isequal, "127.0.0.1" ~ -------------------------------------------- Now that I run the following commands. # logger -p "local1.info" test # logger -p "local2.info" test # logger -p "local5.info" test Actual results: As a result, logs from local1.* and local5.* are recorded, but a log from local2.*’s is NOT. Expected results: It is recorded in local1, local2, local5, and order. Additional info: $IncludeConfig is a global directive. So, is it allowed to describe a global directive into the section where rules are described?
Created attachment 627213 [details] fix for the bug
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-0450.html
I checked rsyslog-5.8.10-10.el6_6.src.rpm, but it doesn't include rsyslog-5.8.10-bz847568.patch. In Changelog, I can find following. - drop patch 5 hich introduced a regression. Resolved #927405. Reverts :#847568. So I understand the patch was reverted. My question is, the bug which was reported in Description still exist after revert the patch from 5.8.10-10.el6_6 ?
(In reply to masanari iida from comment #7) > I checked rsyslog-5.8.10-10.el6_6.src.rpm, > but it doesn't include rsyslog-5.8.10-bz847568.patch. > > In Changelog, I can find following. > - drop patch 5 hich introduced a regression. > Resolved #927405. > Reverts :#847568. > > So I understand the patch was reverted. > My question is, the bug which was reported in Description still > exist after revert the patch from 5.8.10-10.el6_6 ? That is correct. There are no plans for fixing this in the rsyslog package. The rsyslog7 package should behave correctly and everybody is encouraged to switch to it.