Bug 1295744

Summary: CR-LF-terminated lines break output formatting
Product: Red Hat Enterprise Linux 7 Reporter: Martin Frodl <mfrodl>
Component: logwatchAssignee: Jan Synacek <jsynacek>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: jsynacek, mfrodl, ppisar, qe-baseos-apps
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1295467 Environment:
Last Closed: 2016-04-28 11:14:32 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:

Description Martin Frodl 2016-01-05 11:40:03 UTC 
+++ This bug was initially created as a clone of Bug #1295467 +++

Description of problem:

When a log file processed by logwatch contains lines terminated with <CR><LF>,
<CR> is treated as a regular character rather than a part of the line break.
This has two unpleasant consequences:

(1) The log message may no longer match the specified pattern, making the line
    an unmatched entry. This may or may not be the expected behaviour.

(2) When printing a <CR><LF>-terminated entry, be it matched or unmatched, the
    carriage return is interpreted literally which breaks the output
    formatting.

Consider the following example, paying special attention to the **Unmatched
Entries** section in logwatch output:

# file /var/log/maillog
/var/log/maillog: ASCII text, with CRLF line terminators

# cat /var/log/maillog
Sep 24 04:17:27 mail1 sm-mta[14263]: k808NQxv028473: <wyman>... User unknown
Sep 24 04:19:01 mail1 sm-mta[12654]: k8O8F027026507: <cotter>... User unknown
Sep 24 04:25:33 mail1 sm-mta[14462]: k8O8VWJc037652: <helman>... User unknown

# logwatch --service sendmail --range all

 ################### Logwatch 7.4.0 (03/01/11) #################### 
        Processing Initiated: Tue Jan  5 06:38:00 2016
        Date Range Processed: all
        Detail Level of Output: 0
        Type of Output/Format: stdout / text
        Logfiles for Host: myhost.redhat.com
 ################################################################## 
 
 --------------------- sendmail Begin ------------------------ 

 **Unmatched Entries**
: 1 Time(s)@tallhart.com>... User unknown
: 1 Time(s)manderly.com>... User unknown
: 1 Time(s) pyke.com>... User unknown
 ---------------------- sendmail End ------------------------- 

 
 ###################### Logwatch End ######################### 

Version-Release number of selected component (if applicable):
logwatch-7.4.0-28.20130522svn140.el7.noarch
Comment 2 Jan Synacek 2016-03-16 13:55:33 UTC 
I don't know how perl handles this internally. Moving to perl team to get some input.
Comment 3 Petr Pisar 2016-03-16 14:26:13 UTC 
Use need-info instead of assigning-to.

Perl uses platform's specific end-of-lines processing. On Linux, it is LF, thus LF is the line separator. This can be redefined, for each file handle or line processing function separately.

Show me exact Perl code with input and undesired output that you think does not match your expectation.

But in general, I believe processing files as is used on given platform by any other tools is fine.
Comment 4 Jan Synacek 2016-04-26 12:53:49 UTC 
Ok, I definitely don't want to fix this in general in every script "just in case". Then patch for this is quite trivial:

--- /usr/share/logwatch/scripts/services/sendmail	2013-12-28 17:01:49.000000000 +0100
+++ /usr/share/logwatch/scripts/services/sendmail.new	2016-04-26 14:51:15.825294510 +0200
@@ -381,6 +381,7 @@
 }
 # $ThisLine might have been reset (undef, or empty string) in $MatchFilter
 next unless $ThisLine;
+   $ThisLine =~ s/\r$//;
 
    if (
       # informational statements of little value

I wonder, how did the sendmail log end up with CRLF newlines?
Comment 5 Martin Frodl 2016-04-28 08:46:41 UTC 
See bug 1295467 comment 4.