The output from
cronjobs is often unceremoniously redirected to
/dev/null just to keep them quiet. This is a bad practice as you don’t get any feedback when potentially important tasks go wrong. (If the task isn’t important, why are you running it on a schedule?)
systems provide a simple tool called
systemd-cat for directing
stderr to the journal. Below is a complete example of a simple monthly
cron job that will run
certbot once every month and save whatever it outputs to the journal under the arbitrary identifier “certbot-cron”. A good identifier will make it easier to look up the output in the journal if you need it later.
I’ll use the automated TLS certificate renewal program
certbot from Let’s Encrypt as the example command throughout this article. It serves nicely as an example of something you need to know about if it at some point will return an unsuccessful condition.
You can then quickly look at certbot output in the journal using
journalctl with the same identifier that you gave the
systemd-cat only accepts one executable with any number of arguments. You can’t run multiple commands at once or use pipes. It will capture
stderr, and assign them appropriate properties in the journal.
You can pipe output into
systemd-cat, but this will only capture
stdout. Important and actionable information will often show up in
stderr, and you’d have to redirect the flow of
stdout to capture it. I’ll not demonstrate this here, as I believe this is the wrong approach.
If you need to run more complex cron jobs with multiple commands, you should save them to a script, make that executable, and then run that script through
systemd-cat as a single command. This will capture
stdout as well as
stderr, and keep your crontab more readable and easier to maintain.