Different output when run from crontab

Hi,

I have a script which checks to see if an app is running and will restart it if it is not.

For some reason when I run it from the crontab it always says it is not running.

The script is as follows: -

#!/bin/sh
#
# The following script will look for the PID of SickBeard and output the result

PROGRAM="SickBeard"
PROGRAM1="/volume1/@appstore/sickbeard/SickBeard.py"
LOG_DIR="/volume1/@appstore/"
LOG_FILE="sb_monitor.log"
APPCHK=$(ps | grep $PROGRAM1 | grep -v "grep $PROGRAM1" | wc -l)
SUPPORTSTAFF="me@me.com"

# The 'if' statement below checks to see if the process is running
# with the 'ps' command.  If the value is returned as a '0' then
# an email will be sent and the process will be safely restarted.

echo "Number of processes running =$APPCHK"

if [ $APPCHK = '0' ];

then

# Write datestamp & output to log file
echo "$(date +%c) $*" >> $LOG_DIR/$LOG_FILE
echo "$PROGRAM is not running">> $LOG_DIR/$LOG_FILE

# Send an email to advise SickBeard was down
echo "$PROGRAM is not running" | /opt/bin/nail -s "$LOG_FILE" -a $LOG_DIR/$LOG_FILE $SUPPORTSTAFF

# Start SickBeard
echo "$(date +%c) $*"
echo "Starting $PROGRAM"
/var/packages/sab2/target/utils/bin/python /volume1/@appstore/sickbeard/SickBeard.py --quiet &

else

# When Sickbeard is running write to log file to say all is fine
echo "$(date +%c) $*" >> $LOG_DIR/$LOG_FILE
echo "$PROGRAM is running">> $LOG_FILE
echo "No action taken...">> $LOG_FILE
echo "$PROGRAM is running"
echo "No action taken..."

fi

exit

The crontab entry is: -

#minute        hour        mday        month        wday        who        command
0        0        *        *        *        root        /usr/sbin/ntpdate -b pool.ntp.org
*/1        *        *        *        *        root        /volume1/@appstore/sickbeard_Monitor.sh >> /volume1/@appstore/log.txt 2>&1

The logic will always return APPCHK=0 when run from the crontab.

Any ideas?

have you checked the mailbox for related errors while running this job in cron.?

Yeah, no errors.

The script runs, it just does not seem to interpret the logic correctly like it does if I run it myself.

try to add the output of ps command in the log file before greping anything from.

Then you can make sure atleast you are getting the program name (as in $PROGRAM1) as required in the ps output.

A "ps" command with no parameters will list the processes for the current terminal only. A "ps" command with no parameters run from cron will fail because there is no current terminal context.

Please post what Operating System and version you are running. There is much variety in the syntax for "ps".
Please post the output from "ps" when run from the command line after starting the application. I'd be surprised to see full path names in that output.

In the end you will need a syntax for "ps" which shows your application when it is running.

Hi,

I'm running this on a Synology DS210 NAS in the ash shell.

The output for the ps command at the prompt is: -

/volume1 # ps | grep sickbeard
 1561 root      2928 S    grep sickbeard
10514 root      188m S    /var/packages/sab2/target/utils/bin/python /volume1/@appstore/sickbeard/SickBeard.py --quiet
/volume1 #

Regards,

Simpic

I have no experience of "ash" or a version of "ps" which behaves like this.

(Appeal for "ash" expert).

General advice is to create a test cron and run the "ps" command and look at the results. Then possibly run the "ps" command with parameters to show processes not started from the current terminal.
If however the "ps" command from a cron is good enough, then replace

grep $PROGRAM1
with
grep "${PROGRAM1}"

So I have found the issue but have no idea how to fix it!

When running from the crontab the output of any command is chopped to a certain length, so the grep on the PS command can not find what it is looking for as the 'uniqueness' of the string is past the chop off point.

I guess this is something to do with the terminal env for the cron.

Does anyone know how I can change that?

EXAMPLE FROM CRON...

5231 root      345m S    /var/packages/sab2/target/utils/bin/python /volume1/

EXAMPLE FROM COMMAND LINE PS

5231 root      187m S    /var/packages/sab2/target/utils/bin/python /volume1/@appstore/sickbeard/SickBeard.py --quiet

you can try executing the .profile of the corresponding user before the script in the cron entry and try.

0 19 * * 2 /home/myuser/.profile; /home/myuser/bin/garbage-day-email.sh 

Time to look at "man ps" on your computer. There's too much variety in the syntax for "ps" to guess accurately but "ps -w" (wide) is one guess.

Hi,

I'm afraid as this is running Busy Box it does not have man. And I'm pretty confident it is nothing to do with the actual ps command. It will use the -w command as default. No difference if I include that in the script as an argument.

The issue is around cron not running in an env set terminal.

I tried the

0 19 * * 2 /home/myuser/.profile; /home/myuser/bin/garbage-day-email.sh

in the crontab with no joy.

It still cuts the output off at 78 characters.

Maybe Busy Box will just not allow it and I'll have to come up with a more intuitive way of checking the process :wall:

Try using -ww ... some versions of the ps command define this as:

   -w              Wide output. Use this option twice for unlimited width.

The 78 character width is sneakily suspicious to standard tty width.
Why are you so confident it is not the ps command?
My hypothesis of the problem would be the ps command cannot identify the output terminal and so it is defaulting to the default tty settings.

In your script, try experimenting also with the 'tty' command. This will either correct your problem or give you better insight.

Try this way. Make a startup script that will start the actual process and stores the PID in a text file.

Later in the cron script you may check for the PID which stored in the text file.

But the problem with this is, when the program crashes and the PID stored in the text file will be reused. And we may end up saying yes for the wrong process.

So check for the possibilities of process crash.

PID text file must be removed when the process stops.

Thanks for the suggestions, I'll have a play around this weekend.

Just a thought... most problems with scripts acting differently when executed out of crontab are related to the restricted environment that is set up by cron for the programs to execute in. Perhaps the version of "ps" invoked by cron is different from the version of "ps" invoked when you run it on the command line.

It might be valuable to run "env" in the script and store its output in a file, for later examination. You "should" see that PATH is probably different from the path you have in your command line shell. There may be other surprises when comparing them with the environmental variables present in your command-line environment.

Thanks for the suggestions, I'll have a play around this weekend.