Bug 1313804 - Leap year handling broken for rsyslog, timestamps issue one day earlier
Leap year handling broken for rsyslog, timestamps issue one day earlier
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rsyslog7 (Show other bugs)
6.6
All Linux
unspecified Severity high
: rc
: ---
Assigned To: Radovan Sroka
BaseOS QE Security Team
: Patch
Depends On:
Blocks: 1313898
  Show dependency treegraph
 
Reported: 2016-03-02 06:36 EST by Peter Portante
Modified: 2016-10-26 05:43 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1313898 (view as bug list)
Environment:
Last Closed: 2016-10-26 05:43:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Portante 2016-03-02 06:36:18 EST
From http://lists.adiscon.net/pipermail/rsyslog/2016-March/042159.html:

-----

Hi all,

I just wanted to let you know that we have found an issue with the
unixtimestamp formatting option in leap years. The problem started on
March, 1st and will persist till the end of the year. The timestamp is
one day in the past.

A patch is available here, it shall probably work with almost all
rsyslog versions:
  https://github.com/rgerhards/rsyslog/commit/ffb321f1698a971e0acda48cafa97bb344cf0829

Full details can be found in this issue tracker:
   https://github.com/rsyslog/rsyslog/issues/830

Note that I will NOT release a 8.16.1 version for this fix. Usually, I
would have done so, but the 8.17.0 release is due next Tuesday and
will probably available as RC on friday. Given the fact that I would
need at least one additional day to craft 8.16.1, I don't think this
makes much sense.

Distro packages (and other users as well, of course) can apply
above-mentioned short patch. I actually suggest to do so, as this
problem exists, I think, in all versions supporting the
"unixtimestamp" formatting option (side-note: v5.8 does not have this
option).

Rainer

-----


Note that this appears to be a very old problem with the code and is likely affecting any rsyslog configuration that is using the "timegenerated" property in their rsyslog templates.

This will also likely need to be fixed in RHEL 7 releases, too.
Comment 2 Tomas Heinrich 2016-03-02 10:07:54 EST
(In reply to Peter Portante from comment #0)
> Note that this appears to be a very old problem with the code and is likely
> affecting any rsyslog configuration that is using the "timegenerated"
> property in their rsyslog templates.
> 
> This will also likely need to be fixed in RHEL 7 releases, too.

Cloning for el7...
Comment 5 Radovan Sroka 2016-10-03 10:17:22 EDT
Hi Peter,

I was trying to reproduce on rhel6 and I'm not able to do so. From my point of view timestamps are correct.

in rsyslog7 we have state before this commit:
https://github.com/rsyslog/rsyslog/commit/7f6c72a2

So if it is really not working, please give me the reproducer.
Comment 6 Peter Portante 2016-10-10 13:23:31 EDT
The full PR is https://github.com/rsyslog/rsyslog/pull/831, with tests, too.

This only occurs when using the "unixtimestamp" reference, see "date-unixtimestamp" property options.
Comment 7 Tomas Sykora 2016-10-26 05:43:57 EDT
Hi,

this bug does not occur in our version of rsyslog in rhel6 as we are using older version in which the code is different from the current upstream version and works fine. I'm closing this.

Note You need to log in before you can comment on or make changes to this bug.