Debian bash script works fine from command line; fails in crontab

Question

I'm trying to use the DreamHost API (see here) to update a DNS entry using crontab. I have written the following bash script:

#!/bin/bash
dh_api_key=<my api key>
dh_domain=<my fq subdomain>

dh_url="https://api.dreamhost.com/?key=$dh_api_key&record=$dh_domain&type=A"

ip_addr=`ifconfig eth0 | grep "inet addr" | 
    grep -o "\([0-9]\{1,3\}\.\?\)\{4\}" | head -n 1`

old_ip_addr=`wget -q -O - ""$dh_url&cmd=dns-list_records"" | 
    grep $dh_domain | grep -o "\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}"`

dh_url="https://api.dreamhost.com/?key=$dh_api_key&record=$dh_domain&type=A"
dh_url_add="$dh_url&cmd=dns-add_record&value=$ip_addr"
dh_url_del="$dh_url&cmd=dns-remove_record&value=$old_ip_addr"

echo $ip_addr
echo $old_ip_addr

if [ "$ip_addr" == "$old_ip_addr" ]
then
    echo SAME
else
    echo DIFFERENT; UPDATING
    wget -q -O - "$dh_url_del"
    wget -q -O - "$dh_url_add"
fi

My crontab entry looks like this:

0,15,30,45 * * * * /home/<username>/dreamhost_api/dns_update_script > /home/<username>/dreamhost_api/dns_update_script.out # <-- note the redirection

If I run the script manually, I get the following output:

<old ip address>
<new ip address>
DIFFERENT; UPDATING

... and everything updates as it should. If I let crontab run the job instead, the update never happens. When I look at the dns_update_script.out file, I see:

<blank line>
<blank line>
SAME

So the script seems to have nothing for the ip_addr and old_ip_addr variables when the script is run by crontab (which of course means the update never happens). Any idea why? Does piping not work (or have some caveats?) when used in crontab?

Answer 1

since both $ip_addr and $old_ip_addr are ending up blank when it runs from cron, perhaps turning on xtrace and then examining the resulting output from the cron invocation could give you the clue on what's not working.

putting

set -x

before the ip_addr= line should do the trick. then let cron run and you should get a bunch of output in the resulting email (or you could redirect the output as another user mentioned. bearing in mind that xtrace emits to stderr, so use something like

* * * * * script >/tmp/outputfile 2>&1

Answer 2

When crond runs a script on behalf of a user, the script will NOT have the same environment variables that the user had from the command line. The script will often fail. These are variables like PATH and LD_LIBRARY_PATH, and so on.

Add lines to your script file to the script to have it source your logon scripts: /etc/profile, plus any others.

Create this crontab entry:

* * * * *  set > /tmp/mycronenv.txt

Save the changes to crontab. Wait a minute or two. Go back and get rid of that entry. Finally:

set > myenv.txt
diff myenv.txt /tmp/mycronenv.txt

This will show you what I mean. How to correct it is up to you. The two outputs have to be identical for your script to run.