Bug 1295744 - CR-LF-terminated lines break output formatting
CR-LF-terminated lines break output formatting
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: logwatch (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jan Synacek
BaseOS QE - Apps
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-05 06:40 EST by Martin Frodl
Modified: 2016-04-28 07:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1295467
Environment:
Last Closed: 2016-04-28 07:14:32 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 Martin Frodl 2016-01-05 06:40:03 EST
+++ 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@manderly.com>... User unknown
Sep 24 04:19:01 mail1 sm-mta[12654]: k8O8F027026507: <cotter@pyke.com>... User unknown
Sep 24 04:25:33 mail1 sm-mta[14462]: k8O8VWJc037652: <helman@tallhart.com>... 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 09:55:33 EDT
I don't know how perl handles this internally. Moving to perl team to get some input.
Comment 3 Petr Pisar 2016-03-16 10:26:13 EDT
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 08:53:49 EDT
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 04:46:41 EDT
See bug 1295467 comment 4.

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