Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
A bug in the implementation of the configuration file parser caused the rule specified immediately before the '$IncludeConfig' directive to be reordered after the contents of the included configuration file.
This caused the order of processing to be different from the intended one with potential of message losses.
The bug was corrected and now the order of processing is the same as the one laid down in the configuration file(s).
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?
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.