Running Scripts from cron and systemd

## What cron actually does When cron runs an entry it attaches the command's standard output and standard error to a pipe rather than to a terminal, since there is no terminal. If anything at all comes out of that pipe, cron composes a mail message containing the output and sends it to the crontab's owner. If nothing comes out, no mail is sent. That is the whole notification design: **output is the alert**. Two variables in the crontab steer it. `MAILTO=address` sends the mail somewhere else, and it applies to every entry below it in the file, so you can set different destinations for different blocks. `MAILTO=""` disables mail entirely for the entries that follow. Crucially, cron mails **output**, not **exit status**. A job that exits 1 while printing nothing generates no mail. Most cron implementations do log the run to syslog or the journal, and some record the exit status there, but that is a log line nobody reads, not a notification. ## Why the mail so often never arrives Mail delivery is not cron's job — it hands the message to a local mail transport agent. Desktop and traditional server installs have one; minimal cloud images, containers and hardened hosts frequently do not. In that case the output is simply dropped, and the cron daemon typically logs a note that no mail transport is installed and the output was discarded. Teams then get the worst outcome available: a mechanism they believe is alerting them, that has never delivered anything. Even where mail works, it goes to a local spool file on that host, not to a rotation, a chat channel or an on-call system. It is a 1980s design that survives because it is the default. ## The `> /dev/null 2>&1` reflex A job that prints a progress line on every successful run mails the owner every night. The usual response is to append `> /dev/null 2>&1` to the crontab line. That redirects standard output to the bit bucket and then points standard error at the same place, so **both** streams are discarded. The mailbox goes quiet, and so does the failure that arrives three weeks later. This is the single most common way a scheduled job becomes invisible. ## The shape that works **Make the script quiet on success.** The convention that makes cron's design usable is silence when there is nothing wrong. A script that prints nothing on a clean run needs no redirection at all, and any output it produces is by definition worth reading. **Keep a durable log anyway.** Diagnosis needs history, and mail is not history: ```bash 0 3 * * * /opt/app/backup.sh >> /var/log/backup.log 2>&1 ``` This keeps everything, forfeits mail, and needs its own rotation — an acceptable trade when the script reports failures through a channel that actually reaches a human. **Report failures deliberately.** Do not rely on the mail path being intact. Have the script call your alerting on a failing exit: ```bash if ! /opt/app/backup.sh >>"$log" 2>&1; then /usr/local/bin/notify-oncall "backup failed, see $log on $(hostname)" fi ``` **Or keep the output but only on failure.** The `chronic` wrapper from moreutils runs a command, swallows its output when it succeeds, and prints everything it captured when it fails — which turns a chatty command into a cron entry that mails only when something is wrong, without editing the command itself. ## Answering "did it even run?" When a job appears not to have run, distinguish three states: cron never started it, it started and failed, or it ran fine and did nothing visible. The cron daemon's own log records the first, an exit status or your log file records the second. A run marker the script itself writes — a touched file or a heartbeat ping — is what lets you assert the third, and a monitoring check on the freshness of that marker is far more reliable than waiting for a message that stopped arriving.