[SOLVED] bash script not functioning when run by cron

Issue

the below bash script is set to kill firefox processes (used by python script) and kill any running same script before running the python script in a loop untill it give error code 0.

#!/bin/bash

for pid in $(pidof -x start-manheim.sh);
do
    if [ $pid != $$ ]; then
        kill -9 $pid;
    fi
done

while true
do
    #pkill -f firefox;
    echo "starting script on `date`";
    python3 mmr-gen.py;
    if [ $? -eq 0 ]
    then
        break;
    fi
done

The script run manually perfectly as it is supposed to, but when using cron :

*/2 * * * * /bin/bash /root/start-manheim.sh >> /root/manheim.log

the script just loops through it without running any python. log data:

starting script on Sat Jul  9 14:54:01 UTC 2022
starting script on Sat Jul  9 14:54:02 UTC 2022
starting script on Sat Jul  9 14:54:03 UTC 2022
starting script on Sat Jul  9 14:54:04 UTC 2022
starting script on Sat Jul  9 14:54:05 UTC 2022
starting script on Sat Jul  9 14:54:06 UTC 2022
starting script on Sat Jul  9 14:54:08 UTC 2022
starting script on Sat Jul  9 14:54:09 UTC 2022
starting script on Sat Jul  9 14:54:10 UTC 2022
starting script on Sat Jul  9 14:54:11 UTC 2022
starting script on Sat Jul  9 14:54:12 UTC 2022
starting script on Sat Jul  9 14:54:13 UTC 2022
starting script on Sat Jul  9 14:54:14 UTC 2022
starting script on Sat Jul  9 14:54:15 UTC 2022
starting script on Sat Jul  9 14:54:17 UTC 2022
starting script on Sat Jul  9 14:54:18 UTC 2022
starting script on Sat Jul  9 14:54:19 UTC 2022
starting script on Sat Jul  9 14:54:20 UTC 2022
starting script on Sat Jul  9 14:54:21 UTC 2022
starting script on Sat Jul  9 14:54:22 UTC 2022
starting script on Sat Jul  9 14:54:23 UTC 2022
starting script on Sat Jul  9 14:54:24 UTC 2022
starting script on Sat Jul  9 14:54:25 UTC 2022
starting script on Sat Jul  9 14:54:26 UTC 2022
starting script on Sat Jul  9 14:54:27 UTC 2022
starting script on Sat Jul  9 14:54:28 UTC 2022
starting script on Sat Jul  9 14:54:29 UTC 2022
starting script on Sat Jul  9 14:54:30 UTC 2022
starting script on Sat Jul  9 14:54:31 UTC 2022
starting script on Sat Jul  9 14:54:32 UTC 2022
starting script on Sat Jul  9 14:54:34 UTC 2022
starting script on Sat Jul  9 14:54:35 UTC 2022

Solution

The CRON environment may be different; e.g., the PATH may be different and a python executable may not be in the CRON PATH. Consider adding an export PATH=/bin:/sbin:/usr/bin:/usr/sbin or similar to your script prior to executing a first external command, a reasonable safety standard to consider anyway. Alternatively, you could call all externals via their absolute path, though that can easily become cumbersome.

Reiterating Barmar, do consider redirecting stderr either to stdout or to a file to capture errors; e.g., 2>&1 (add stderr to stdout), 2> /tmp/manheim.err (clobber and write stderr to file), or 2>> /tmp/manheim.err (append stderr to file).

A few other/unrelated thoughts that may be worth considering, if you haven't already:

• Unless mmr-gen.py is monitoring and following its parent process, a kill -9 to a start-manheim.sh process would kill start-manheim.sh, though not mmr-gen.py.
• Consider a mutual exclusion lock of some kind for preventing duplicative runs, as opposed to killing and restart previous script runs (e.g., a Bash noclobber lock).
• Consider running Bash scriptserrexit enabled (#!/bin/bash -e, set -e, or set -o errexit). errexit is helpful for exception safety and handling discipline.
• Consider using [[ ]], as opposed to [ ], assuming use Bash, Z Shell, or another supporting Bash variant. [[ ]] is generally more efficient and syntactically forgiving.
• -eq, -ne, and the like are arithmetic operators, while ==, !=, and the like are technically string operators (e.g., [ 1 == 01 ] does not evaluate to true, while [ 1 -eq 01 ] does). In your case, the distinction shouldn't be relevant, though intention and consistency in scripting are generally good practices to consider.

Given the echo output, the script is clearly running; though, to tripleee's comment, and for completeness, the following are also good to check (lots drawn from the other post, which has a great deal of useful information):

• Check for errors reported by/through CRON (e.g., find /var/log -maxdepth 1 -type f -mmin -60 -exec grep -Hi cron '{}' \; | less -S).
• Verify how your CRON flavor handles stdout and stderr (e.g., * * * * * echo stdout; echo stderr 1>&2 and check default or specific MAILTO [if there is one] and/or files [e.g., find /var/{log,spool/mail} -maxdepth 1 -type f -mmin -60 -exec zegrep -H 'std(err|out)' '{}' \;]).
• Check the inherited CRON environment (e.g., * * * * * /usr/bin/env > /tmp/env, examine /tmp/env, and remove the job). Specifically, for example, check that the inherited PATH is sufficient.
• Verify that CRON is indeed running (e.g., pgrep -P 1 -U root cron) and, if not, investigate and, if safe to do so, (re)start it (e.g., systemctl start cron.service). Given the echo output, this isn't a problem here.
• Verify that your command is executable by CRON (e.g., an appropriate execute bit [e.g., chmod -v 0755 start-manheim.sh, assuming the script is OK to be world readable and executable] and a correct shebang [e.g., #!/bin/bash -e]). Given the echo output, this isn't a problem here.
• Review documentation for your flavor of CRON (e.g., man 5 crontab) for crontab syntax correctness and subtleties (e.g., presence of unescaped %s).

Answered By - ahi324

Answer Checked By - Timothy Miller (WPSolving Admin)