Linux Interview Question 10: Cron Job Environment Path
Linux Interview Questions · Test 1 · question 10 of 10
A backup script, /opt/backup/run.sh, works every time you run it from your terminal. You add it to your own user crontab with crontab -e, but the job's output shows pg_dump: command not found. pg_dump lives in /usr/local/pgsql/bin, which you added to PATH in your ~/.bashrc.
What is the most likely cause, and the right fix?
Show answer and explanation
Answer:
Your terminal is an interactive shell, and bash reads ~/.bashrc only when it starts an interactive non-login shell. cron does not start jobs from your login session: the daemon sets up a small environment itself (SHELL=/bin/sh, HOME and LOGNAME from the crontab owner's /etc/passwd entry, and a default PATH of its own). A non-interactive shell running a script never reads ~/.bashrc, so /usr/local/pgsql/bin is not on the job's PATH. A crontab may contain name = value environment settings, so a line such as PATH=/usr/local/pgsql/bin:/usr/bin:/bin at the top works. Using absolute paths inside the script is even more robust. "Works in my terminal, fails in cron" is almost always an environment difference.
Option A is wrong because a user crontab's jobs run as the crontab's owner, not root. Editing root's shell profile would not help in any case, since cron doesn't read profiles.
Option C is wrong because a missing execute bit produces Permission denied for the script itself, not command not found for a command *inside* the script. The script clearly ran.
Option D is wrong because /bin/sh searches PATH like any POSIX shell. Switching to SHELL=/bin/bash would still start a non-interactive bash that does not read ~/.bashrc, so the directory would still be missing.
References: crontab(5) - Linux manual page; bash(1) - Linux manual page