On Sunday, 9 June 2013, Christian Kastner <deb...@kvr.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2013-06-07 15:55, Saint Germain wrote:
>> On 5 June 2013 23:34, Christian Kastner <deb...@kvr.at> wrote:
>>> On 2013-06-05 13:12, Saint Germain wrote:
>>>>>> Indeed even if cron has nothing to do, a temporary file is
>>>>>> always created in /tmp and immediatly deleted.
>>>
>>> So another workaround for you would be to comment out the hourly
>>> stanza from /etc/crontab.
>>>
>>> Any other solution would be overly complex to implement, I'm
>>> afraid.
>>
>> Ok I haven't carefully read the commit, so I didn't understand why
>> this file creation was necessary in the first place (and why other
>> distro don't have this behavior).
>
> To prevent data loss.
>
> Summarized: one of cron's features is the mailing of output. "Regular"
> cron connects to the MTA, runs the job and pipes its output to the
> MTA. However, some MTAs time out if they don't receive input within a
> certain amount of time, resulting in the output not being sent by
> mail, resulting in data loss (see bugs #155109, #443615).
>
> With the patch, we write to a tmpfile and only connect to the MTA when
> the job is finished, thereby preventing this possible data loss.
>
>> If mounting /tmp on a tmpfs as a workaround is acceptable,
>> probably that creating the temporary file directly in RAM would
>> also be acceptable ?
>
> That came to my mind as a possible solution, too. The problem is we
> don't know how much RAM we might have available (think embedded
> systems), so consuming possibly large amounts of it periodicalyly may
> result in Bad Stuff(tm) happening to the system.
>
> An alternative could be to control this behaviour (pipe to MTA
> directly vs pipe to tmpfile) via a command-line flag.
>

OK got it !
Thanks for having taken the time to explain. A command-line flag would be
ideal, I agree.

Best regards,

Reply via email to