chronic runs a command and throws away its output — unless the command
fails, in which case it prints everything the command wrote and exits
non-zero. It comes from moreutils, a small collection of Unix tools that
arguably should have existed all along.
It exists because of how cron reports failure. Cron mails you anything a job
writes to stdout or stderr. A job that prints a progress line on every
successful run mails you every day, so you start ignoring the mail — and the
one message that matters gets ignored with it. Redirecting to /dev/null
fixes the noise by throwing the failures away too.
chronic gives you the useful version of both: silence when things work, the
full output when they don't. Then an email from the box means something is
actually wrong.
A crontab where the noisy jobs are wrapped and the reporting ones aren't:
MAILTO="you@example.com"
@daily chronic /usr/bin/nice /usr/bin/trash-empty 30
0 6 * * 1 /usr/local/sbin/weekly-traffic-report.sh # meant to mail, so bare
Two things chronic does not do, both easy to assume it does:
popd, say — reports success no
matter what failed earlier, and chronic faithfully stays quiet. set -e
in the script is what makes the exit status honest.chronic echo hello and then
chronic sh -c 'echo hello; exit 1'.
Done when: the first prints nothing, the second prints hello, and
echo $? after it shows 1.false then true), and run it
under chronic.
Done when: nothing is printed, you can explain why, and adding
set -e to the script makes the failure appear.crontab -l and decide for each job
whether it should be wrapped.
Done when: you can name at least one job that is correctly left bare
because its output is the point.