What is the 'working directory' when cron executes a job?

Question

I have a script that works when I run it from the command line, but when I schedule it with cron I get errors that it cannot find files or commands. My question is twofold:

1. When I schedule a cron job using crontab -e, does it use my user ID as the basis for its permissions? Or does it use a cron user ID of some sort and its related permissions?

2. When a cron job is launched, what is the working directory? Is it the directory where I specify the script to run, or a different directory?

Here is my cron job:

15 7 * * * /home/xxxx/Documents/Scripts/email_ip_script.sh

Here is the actual script:

vIP_ADDR="`curl automation.whatismyip.com/n09230945.asp`"
echo "$vIP_ADDR"
sed "s/IPADDR/$vIP_ADDR/g" template.txt > emailmsg.txt
ssmtp XXXXX@gmail.com < emailmsg.txt

Here are the errors I get when I view the mail message produced by cron:

sed: can't read template.txt: No such file or directory
/home/xxxx/Documents/Scripts/email_ip_script.sh: line 15: ssmtp: command not found

It cannot find the template.txt but it resides in the same directory as the script. It also cannot run ssmtp, but I can as my user. What am I missing to get this to work properly?

Answer 1

Add cd /home/xxxx/Documents/Scripts/ if you want your job to run in that directory. There's no reason why cron would change to that particular directory. Cron runs your commands in your home directory.

As for ssmtp, it might not be in your default PATH. Cron's default path is implementation-dependent, so check your man page, but in all likelihood ssmtp is in /usr/sbin which is not in your default PATH, only root's.

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
15 7 * * * cd /home/xxxx/Documents/Scripts && ./email_ip_script.sh

Answer 2

If your cronjob is a bash script, the following will CD to the location of your script (assuming that you're using absolute path in your cron definition):

cd "$(dirname "$0")";

Answer 3

To answer question 1: if you run crontab -e as your own user the jobs will be scheduled in that user's crontab and will thus run with the permissions of that user.

But you need to consider that the jobs will run in a non-interactive shell meaning that the $PATH might be different from the one you have when running the script from the command line.

It is best to always use full paths in scripts, especially if you plan to schedule them via at/cron etc.

I would also recommend using full paths to all files to avoid exactly the problems you see.

To prevent race conditions and other security issues you should also use mktemp to make sure the file you read is not modified by anything outside your script.

So I'd change the script to something like:

vIP_ADDR="`curl automation.whatismyip.com/n09230945.asp`"
echo "$vIP_ADDR"
mail_msg=`/bin/mktemp`
/bin/sed "s/IPADDR/$vIP_ADDR/g" /home/xxxx/Documents/Scripts/template.txt > $mailmsg
/path/to/ssmtp XXXXX@gmail.com < $mailmsg
/bin/rm $mailmsg

Answer 4

The default working directory for cron in executing the job is the home directory, typically /home/your-user-name.

Answer 5

cron runs each user's scheduled jobs as that user. This should be enough for us to work out that it runs your scripts relative to your home directory.

If you need it to run from a different location, simply use cd in your script to go to that location.

ssmtp is probably not in cron's default PATH (it is set to be very narrow by design on most platforms). You can either specify the full path to ssmtp in your script, or you can explicitly set PATH in a) your crontab file, which will be available to all your scripts, or b) in each script.

Answer 6

Some people have hinted or linked at it but the best way to find out since I can't find it in the man docs for my distro is just add this to a cron

* * * * * echo $PWD > /tmp/lolcronjobs

In my case ubuntu defaults to only using /usr/bin:/bin which caused a few issues.

Answer 7

Check this thread how you can easily find out cron's environment, it is much less than you are used to in an interactive shell. Best is to assume nothing been set and explicitly set it yourself.