Bug 1313804

Summary:	Leap year handling broken for rsyslog, timestamps issue one day earlier
Product:	Red Hat Enterprise Linux 6	Reporter:	Peter Portante <pportant>
Component:	rsyslog7	Assignee:	Radovan Sroka <rsroka>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.6	CC:	pportant, pvrabec, rsroka, tosykora
Target Milestone:	rc	Keywords:	Patch
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1313898 (view as bug list)		Environment:
Last Closed:	2016-10-26 09:43:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1313898

Description Peter Portante 2016-03-02 11:36:18 UTC

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 15:07:54 UTC

(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 14:17:22 UTC

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 17:23:31 UTC

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 09:43:57 UTC

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.