Bug 844379 - Junk included in cron job output
Junk included in cron job output
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
17
x86_64 Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-30 08:51 EDT by Adny H
Modified: 2012-08-01 11:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-01 11:01:16 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)
Email received when I run "crontest.sh" from cron (19.52 KB, application/octet-stream)
2012-07-30 08:51 EDT, Adny H
no flags Details

  None (edit)
Description Adny H 2012-07-30 08:51:31 EDT
Created attachment 601257 [details]
Email received when I run "crontest.sh" from cron

Description of problem:

I have a cron job that runs once a day to identify and purge some duplicate files. It emits one line to stdout per file it deletes.  The output mailed to me by cron preiodically includes lumps of binary data.  

To test, I created a much simpler job that simply echo's a couple of hundred lines of text. This works as expected as long as there is no delay between the lines being echo'd.  If I include a usleep 100000 between each line, I get the same binary junk included as in my real job's output.


Version-Release number of selected component (if applicable):

cronie-1.4.8-11.fc17.x86_64
cronie-1.4.8-10.fc16.x86_64


How reproducible:

Completely.

Steps to Reproduce:

1. Schedule a job with cron that outputs a reasonable amount to stdout, with delays between each line.  I used the following "crontest.sh":

#! /bin/bash
limit=200
delay=100000
for l in `seq -w 1 $limit`; do
    echo "This is line number $l of $limit ... Something fox, something dog."
    usleep $delay
done

2. Receive bad output by mail.

  
Actual results:

(Mail received from the script above attached).

The 58th line output includes a null byte part way through (in place of the "o" in "of 200") and is followed by a block of binary data after which the 58th line completes from the "o" that was mangled earlier and normal output resumes.

Line 121 of the output next shows the same corruption (but one character further in).  And again at line 184.


Expected results:

Unmangled lines of text in the output mailed by cron.


Additional info:

The binary data includes a small number of tantalising strings: "Linux", "seshat.verelanthe.lan" (the machine's hostname), and "3.4.6-2.fc17.x86_64" (the version of the running kernel).

Running the test script and piping its output into mail does not show any problems.
Comment 1 Adny H 2012-07-30 08:53:53 EDT
Sorry, forgot to mention:  this seems to affect (at least) Fedora 15, 16 and 17.  I see this behaviour on my F16 and F17 boxes at the moment (the F15 box was upgraded before I'd got around to filing the bug report).
Comment 2 Adny H 2012-08-01 08:18:43 EDT
Done some more testing.  I'm only able to reproduce the problem if mail is moved off the machine with ssmtp.

Piping the output of my test script to sendmail (i.e. ssmtp) does not show the problem, I still only see it if the script is run by cron.

Any suggestions on how to identify if this is a bug with cron, or ssmtp?

ssmtp-2.61-17.fc17.x86_64
Comment 3 Marcela Mašláňová 2012-08-01 08:56:23 EDT
I don't think it's a problem of cron. Cronie is just doing what you want. It calls exec on your script. You can try different sendmail utility if it's a problem for all.
Comment 4 Adny H 2012-08-01 11:01:16 EDT
OK; looks like this is an ssmtp bug.

I just tried using using a simple "dump stdin to a file" replacement for the mail command and what I'm seeing is that cron is sending the job's output to the mail program in blocks that correspond to the intact portions of the corrupt emails.  I.e. the corruption I see in the mail coincides with the pause between the blocks of output piped to ssmtp (as sendmail).

If I pipe the same output as cron creates through sendmail (i.e. ssmtp) with a delay at the same point, I get corruption in the same way.

Will file a fresh bug against ssmtp.

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