Send cron job output to syslog on Ubuntu

Pipe a job's output to logger to submit it to the local logging system. Configuring rsyslog's cron facility separately controls cron daemon events; it does not automatically capture everything a script prints.

This distinction matters on Ubuntu 20.04 and other Debian/Ubuntu systems: the record saying a command was launched is different from the command's own output and completion result.

Tag the application output

A minimal user-crontab example is:

* * * * * /home/appuser/myjob.sh 2>&1 | logger -t myjob

2>&1 combines the script's streams, and -t myjob adds a tag. The destination depends on the host's journal and rsyslog routing. On a host routing these messages to /var/log/syslog, inspect them with:

grep 'myjob' /var/log/syslog

On a journald host, journalctl -t myjob is another useful lookup. Logging access may require privileges.

Preserve the job result

The simple pipeline normally returns logger's status, which can mask a failed script. For status-aware use, put it in a Bash wrapper:

#!/bin/bash
/home/appuser/myjob.sh 2>&1 | logger -t myjob
results=("${PIPESTATUS[@]}")
logger -t myjob "event=finish status=${results[0]} logger_status=${results[1]}"
exit "${results[0]}"

Schedule the wrapper instead. Include a run identifier when executions can overlap. Successful local submission does not prove a remote log destination received the message; test the path end to end.

Route cron daemon events separately

First inspect existing rsyslog rules. Many Ubuntu installations already route cron events into the general syslog file; a commented-out dedicated cron rule does not mean cron logging is entirely disabled.

To add a separate file, an administrator can configure a rule such as:

cron.*    /var/log/cron.log

Place it in an appropriate rsyslog configuration file, validate the resulting configuration, then apply it:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Review the existing routing and ordering to avoid unwanted duplication. The rule matches messages carrying the cron facility. logger -t myjob normally uses a different default facility; a tag alone does not make its messages match cron.*.

Inspect the separate scheduler file with tail -f /var/log/cron.log. Script output still needs the logger pipeline or another explicit destination.

Collect and verify both kinds of evidence

Guance file log collection can collect syslog and dedicated task files. Send an identifiable test event and run both a successful and a deliberately failing test job. Confirm the job's result as well as its launch record, and check local logs when centralized records are missing.

Common questions

Where does cron send output by default? Traditional cron normally tries to email unredirected output. Delivery requires a working mail transport and can be disabled with MAILTO="".

Does enabling cron.* capture script stdout? No. It routes messages already submitted with that facility.

Where do systemd timer job logs appear? Inspect the associated service, for example journalctl -u myjob.service. The timer journal mainly concerns scheduling and timer state.

References

• Debian cron logging
• util-linux logger manual
• rsyslog selector syntax
• Bash PIPESTATUS variable