Chris Worner
Well-known member
- Joined
- Apr 15, 2016
- Messages
- 635
- Points
- 28
A backup script I wrote ran perfectly every time I tested it from the shell, then silently produced nothing for four nights in a row once it was in crontab. No error anywhere I thought to look.
Cron does not give your job the environment your login shell has. The PATH it hands over is usually just /usr/bin:/bin, it does not read .bashrc or .profile, and HOME may not be what you assume. So a script calling mysqldump or php or aws by bare name works when you run it and fails the moment cron runs it, with a not found error that goes nowhere.
Two things fixed it for me. Absolute paths for every binary the script calls, and a redirect on the crontab line so output lands in a file I can read instead of a local mail spool nobody empties. If I want to see what cron is actually handing over, I put
What I still have not settled is where these scripts belong. Root's crontab, the site user's crontab, or a systemd timer. Each one has bitten me for a different reason. Which do you use for per site jobs?
Cron does not give your job the environment your login shell has. The PATH it hands over is usually just /usr/bin:/bin, it does not read .bashrc or .profile, and HOME may not be what you assume. So a script calling mysqldump or php or aws by bare name works when you run it and fails the moment cron runs it, with a not found error that goes nowhere.
Two things fixed it for me. Absolute paths for every binary the script calls, and a redirect on the crontab line so output lands in a file I can read instead of a local mail spool nobody empties. If I want to see what cron is actually handing over, I put
env > /tmp/cronenv on a temporary minute schedule and compare it against my own env.What I still have not settled is where these scripts belong. Root's crontab, the site user's crontab, or a systemd timer. Each one has bitten me for a different reason. Which do you use for per site jobs?
