script runs at terminal - but not in cron

Question

I'm logged in as user pi via SSH and have a wifi checking script wifi_test_1.sh in the following directry: /usr/src/scripts/wifi_test_1.sh

When i enter the command /usr/src/scripts/wifi_test_1.sh into the terminal, it runs; i can see the "echos", but when i enter this: */1 * * * * /usr/src/scripts/wifi_test_1.sh into my crontab -e, I can not see it running.

When i do a grep CRON /var/log/syslog I see:

Feb 24 22:35:01 raspberrypi /USR/SBIN/CRON[7537]: (pi) CMD (/usr/src/scripts/wifi_test_1.sh)

But no echos from the script.

Is the script running in the background, so i cannot see the echos from the script, when logged in as pi at terminal via SSH?

script for completeness:

#!/bin/bash

# Which Interface do you want to check/fix
wlan='wlan0'

# perform check 
if ifconfig $wlan | grep -q "inet addr:" ; then

    echo "==============="
    echo "Network is Okay"
    echo "==============="

else

    echo "================================================="
    echo "Network connection down! Attempting reconnection."
    echo "================================================="


    ifdown $wlan
    sleep 10
    ifup --force $wlan
    ifconfig $wlan | grep "inet addr"
fi
exit 0

Answer 1

There are a couple of things I'd do differently and it's a combination of a fuller version of Octopus' comment, a modified version of the answer by rob and my own thing.

By default, CRON's output is send to the Mail Transport Agent or MTA and on Debian the default is exim4 and you can read the mail messages with mutt for example. And with your crontab entry it would send both stdout (your echo statements) and stderr (errors) to it.

If you don't have and/or don't want an MTA, rob's variant works good too, but you'll miss any errors that would occur (see my next point for that). You can have both stdout and stderr if you change it to this:
*/1 * * * * /usr/src/scripts/wifi_test_1.sh >> /tmp/cronoutput.log 2>&1
This will send stderr (fd 2) to stdout (fd 1) and therefor ends up in your custom log file. Note that /tmp/ is cleared on reboot and you'd thus lose any files stored there, but in this case that may not be an issue.

The last suggestion I have is to use FULL paths in your commands.
While developing I'd add echo "PATH: " $PATH so that your $PATH is send to stdout and that makes it easy to spot errors or wrong assumptions in your code. ifconfig, ifup and ifdown are in /sbin/ and that was not in the $PATH of the 'cron'-user. Adding a export PATH=/sbin/:$PATH at the beginning of the script fixed that.
But I actually prefer to just use the full paths in my code and would thus have used /sbin/ifconfig, /sbin/ifup and /sbin/ifdown.

Answer 2

When working with CRON I always output the result to a dedicated file, such as

*/1 * * * *  /usr/src/scripts/wifi_test_1.sh >> /tmp/cronoutput.log

rather than try and setup a mail daemon

Answer 3

QUESTION:

Is the script running in the background, so i cannot see the echos from the script, when logged in as pi at terminal via SSH?

N.B.

Know first that the script is running - it's that the absence of the output you expected only makes it seem like it's not running.

ANSWER:

Running a script from an interactive shell (e.g. bash is the RPi default) is different than running it from cron.

Consider the situation when you run a script from your interactive shell in a terminal. By default the "standard output" (stdout) and "standard error" (stderr) generated when you run a command are sent to the TTY (or PTY) device (e.g. /dev/pts/0) in which your interactive shell is running. This stdout/stderr appears in the terminal as the command/program writes it. You see it in your terminal because the interactive shell knows where to send it (e.g. /dev/pts/0).

Now consider that same script run from cron. There is no interactive shell, and the script has no way to know what your /dev/pts is - if you even have one!

So what does it do with stdout and stderr? Answer: They are sent to /dev/null... effectively a "black hole".

However, Linux provides a solution! It's called redirection - specifically output redirection. You can deploy redirection in your cron jobs very easily; following are examples:

* * * * * /usr/src/scripts/wifi_test_1.sh > /home/pi/scriptoutputs.txt 2>&1

The > is the symbol used to specify redirection to a file with "overwrite"; i.e. each write action overwrites the file's previous contents. To "append" the outputs to the end of the file, use >> instead of >.

The 2>&1 is another redirection that effectively combines the stdout (1) with the stderr (2) to capture both stderr and stdout in the same file.

To get only the stdout to a file:

* * * * * /usr/src/scripts/wifi_test_1.sh > /home/pi/scriptoutputs.txt

If you only want stderr:

* * * * * /usr/src/scripts/wifi_test_1.sh 2> /home/pi/scriptoutputs.txt

What about getting cron outputs in email?

If that's what you want - if that's useful for you - then yes, you can do that. You may configure how this works through the MAILTO option in your crontab:

MAILTO= | This sends no email
MAILTO=pi | This sends email to local user pi
[email protected] | Requires a Gmail account & meeting Google's requirements for an "untrusted" source

IMHO, output-via-email is not a good option. If it's sent to a local user (e.g. pi) you will have to either install a decent email client, or use the clunky default mail utility. Sending to a real mail account requires an SMTP server - with all of the attendant hassles. But again, it can be done if this is what you need.