Bug 784736

Summary: output of freshclam piped into mail sometimes has ctrl-m characters and duplicate lines
Product: [Fedora] Fedora Reporter: Paul <pnewell0705>
Component: clamavAssignee: Enrico Scholz <rh-bugzilla>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 16CC: nb, ondrejj, pnewell0705, redhat-bugzilla, rh-bugzilla, steve
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-05 11:42:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
what Thunderbird gives me as attachment to mail sent by root on F16 running freshclam
none
a richer example none

Description Paul 2012-01-26 00:08:41 UTC
Description of problem:
When running freshclam through a script that sends the output to mail via a pipe, sometimes there will be a ctrl-M in the stream (sometimes more than one). Today I spotted one that not only had that but a duplication of the line as well, so the output is a bit more mangled.

The output in the log file does not have it.

I am picking up mail on a WinXP SP3 box running Thunderbird

In this case, it stripped the return before repeating the line, so dos3unix doesn't pick it up.

The call I am making is on the order of:
+++
    ((date; echo "called freshclam"; echo " "; /usr/bin/freshclam - l /var/log/freshclam.log; echo " "; /usr/bin/freshclam -V") | mail -s "freshclam" -r pnewell.edu pnewell.edu) && {
    test -x /usr/sbin/clamav-notify-servers && \
    exec /usr/sbin/clamav-notify-servers \
    :
    }
+++
I have attached what came through in mail (its an attachment to the email as I think it can't handle the ctrl-M when trying to display as the body of the text)

Version-Release number of selected component (if applicable):
ClamAV 0.97.3/14360/Wed Jan 25 14:46:00 2012

How reproducible:
So far, it seems to be on the order of 60-75% of the time it will have some ctrl-M's ... this is the first time I have seen content change (see attachment)

Steps to Reproduce:
1. See above
2.
3.
  
Actual results:
see attachment

Expected results:
No ctrl-M characters, no mangling of output

Additional info:
I have always been getting attachments rather than text on F14 and I just figured that was the way it was. I only suspected a problem when I began getting a minority of the emails as text under F16. So I would assume this is also the case in F14 (and maybe closer to 100% reproducible), but since it is EOL it doesn't make any sense to do more than just note it.

Please let me know if there is anything more I can provide

Thanks in advance,
Paul

Comment 1 Paul 2012-01-26 00:10:40 UTC
Created attachment 557566 [details]
what Thunderbird gives me as attachment to mail sent by root on F16 running freshclam

You can see a single ctrl-M in the middle and that the line is duplicated immediately after the ctrl-M and is then followed by a valid return

Comment 2 Paul 2012-01-26 00:19:35 UTC
Created attachment 557570 [details]
a richer example

I went back through my "to be deleted" and found this example which is much richer in displaying the error.

Its the same script as what I submitted in the body of the bug report. The only difference is it is called from rc.local

Comment 3 Enrico Scholz 2012-02-05 11:42:20 UTC
sorry, there is no way to turn off animated progress messages for non-tty applications.  You have to pass the '--quiet' option to freshclam.

Comment 4 Paul 2012-02-05 19:11:02 UTC
Thanks for the update. Of course, I'm sorry it can't be cleaned up, but I do appreciate your letting me know that it can't rather than leaving it unanswered.

Part of the reason I submitted this was because I had a similiar problem with the output of yum update producing pesky crtl-M's and that was a fixable problem (see Bug 720088).

Paul