Deployed a backup script on a new server, tested it manually — worked fine. Set up crontab, came back next morning, no backup. Turns out /usr/local/bin wasn’t in cron’s PATH so pg_dump just silently didn’t exist.
Switched to absolute path and it worked immediately. Fifteen minutes of debugging for a one-character fix. I keep making this mistake every time I set up a new box. At this point I should just have a checklist taped to my monitor.
hey, at least you caught it within a day.
EDIT : Next time make the cron job run when you’re finished deploying it.
cron isn’t using your login shell. that’s the trap.
but put PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin at the top of the crontab, then test the exact command once with env -i HOME=“$HOME” PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/sh -c ‘…’, and you catch most of the “worked in my terminal” stuff before it turns into tomorrow’s missing backup. MAILTO or a heartbeat catches the next failure.
Looks like you need to collect your crontab logs somewhere you can read.
Or maybe even set up a valid MAILTO in the crontab so that failures are emailed to them.
My “pro” tips:
- set up an email alias from root to an email you actually read
- always use absolute paths
- anything complex, put it in a shell script
You can append
2>&1 | logger -t my-cronjobto any command, and it will write logs to system journal which you can view with
journalctl
