Bug 583607 - logwatch must understand RSYSLOG_FileFormat timestamps
Summary: logwatch must understand RSYSLOG_FileFormat timestamps
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: logwatch
Version: 5.5
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: David Kutálek
URL:
Whiteboard:
Depends On:
Blocks: 974044
TreeView+ depends on / blocked
 
Reported: 2010-04-19 08:38 UTC by Peter Bieringer
Modified: 2013-06-13 10:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 448789
: 583621 974044 (view as bug list)
Environment:
Last Closed: 2012-08-29 11:16:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Patch for applystddate to catch the new rsyslog timestamp (1.16 KB, patch)
2010-04-19 14:39 UTC, Peter Bieringer
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:1217 0 normal SHIPPED_LIVE logwatch bug fix update 2012-08-29 15:15:59 UTC

Description Peter Bieringer 2010-04-19 08:38:37 UTC
Hi,

after upgrading systems from RHEL 5.4 to 5.5, logwatch reports are no longer catching entries of /var/log/secure and /var/log/messages, because rsyslog was updated to 3.x which now reports in the new timestamp without any adjustments.

Just note, that default config provided by Red Hat is also not changing the timestamp entry.

This results, that logwatch is now broken imho using default rsyslog configuration of 5.5

Just note that the RHEL 5.5 changelog does not mention any changes regarding rsyslog.

BTW: I'm happy that RHEL 5.5 ships rsyslog 3.x, but had not expect such imcompatibility without any notice.

+++ This bug was initially created as a clone of Bug #448789 +++

Logwatch parses the timestamps of the log files it processes.

The traditional Unix syslog timestamp looks like this:

May 28 14:14:46 HOSTNAME ...

The rsyslog package refers to this timestamp format as
"RSYSLOG_TraditionalFileFormat".  It has several glaring deficiencies: it
doesn't collate, it doesn't contain timezone information, and it has only
single-second precision.

rsyslog also supports a more modern timestamp format, called
"RSYSLOG_FileFormat", which is essentially the ISO8601 date/time format.  It
looks like this:

2008-05-28T14:14:46.316223-04:00 HOSTNAME ...

This timestamp format overcomes the deficiencies of the traditional timestamp
format.

However, logwatch does not understand this timestamp format; logwatch expects
all system logs to have the traditional timestamp format.

Logwatch should be enhanced (preferably by upstream) to understand the
RSYSLOG_FileFormat for timestamps, so that system administrators have the option
of using that format for system logs without breaking logwatch.

If I submitted an enhancement patch for logwatch to understand the
RSYSLOG_FileFormat, and the patch was reasonable, would you accept it?  Would
upstream?

--- Additional comment from varekova on 2008-05-29 09:14:52 EDT ---

Hello, thanks for your interest, the best solution is to discuss this problem on
logwatch development mailing list - logwatch-devel. The upstream
guys should be the persons who decide whether it is better to add this support
or not. Could you forward this question to the upstream list? If there is any
problem, please add here a comment.

Comment 1 Peter Bieringer 2010-04-19 08:59:27 UTC
According to http://www.rsyslog.com/doc-v3compatibility.html the new timestamp was chosen by default since version 3.x now.

Workaround to get old timestamp:

add to first line of /etc/rsyslog.conf:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Comment 2 Peter Bieringer 2010-04-19 14:39:08 UTC
Created attachment 407611 [details]
Patch for applystddate to catch the new rsyslog timestamp

Comment 3 RHEL Program Management 2011-01-11 20:29:26 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 4 RHEL Program Management 2011-01-11 23:02:21 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 5 RHEL Program Management 2011-05-31 13:22:50 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 6 RHEL Program Management 2011-09-23 00:12:49 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 11 errata-xmlrpc 2012-08-29 11:16:56 UTC
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-2012-1217.html


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