[Discuss] Cron behaviour

[brendan]

On 14-01-09 01:38 PM, John Blomfield wrote:
> On 01/09/2014 12:07 PM, brendan wrote:
>> i'm late to chime in here, but in general it's a bad idea to have cron
>> rely on STDOUT, STDERR, or X. there are some newer notification services
>> to get around this problem, like Growl (primarily OS X, but there's a
>> linux version too) or Ubuntu's notify service (that uses DBUS) - or
>> using sendmail or mailx, as denis suggests. in some cases, using
>> stdout/stderr/x in this manner can cause the cron jobs to fail
>> (stdout/stderr can have buffering problems if cron jobs output to them).
>>
>> in your case, it's probably not a big deal (you are always running X, so
>> you'll never have any problems) - but it might be worth investigating
>> some of these notification services for anyone doing something similar
>> in the future.
> Thanks, that's interesting. I am not sure if this issue applies to my
> script or not. I am running rsync in the cron bash script and the
> rsync output which would normally go to stdout and stderr is
> redirected to log files that I can check if required. Its the return
> values from rsync that I check for success or failure and use to
> control my Kdialog popups.
>
> Rsync is a command line program so I don't think you can avoid the
> fact that its output is by default on stdout/stderr. Even if you run
> Rsync as a process from C/C++ code you still have to redirect it in
> some way. I have written a C++ program for another purpose that does
> just that.

if you are redirecting to log files, you are all good. the problem
arises when they aren't redirected and the output going to them fills up
cron's buffer.

instead of a shell script to handle the redirection, you could just do
it on the command line: "rsync stuff 2>>/var/log/cron_stderr.append.log
>> /var/log/cron_stdout.append.log" (or a single > to always overwrite
the file)

the new/safe way of avoiding an X call from your script that watches the
return output would be to write to one of the messaging services (like
DBUS), then have something polling (or waiting on, if the service can
push) the messaging service for the message the cron job sent. then cron
doesn't have any external dependencies to complete the job.

there's nothing inherently wrong with what you are doing, it would just
be a risky thing to implement inside a production environment.