0

I've been having issues lately with a cron script that has been running for a long time and suddenly stopped working. The script runs on root crontab. The organization is as follows:

  • In the crontab i execute a run_script.sh script
  • Inside the .sh script i execute cd to a specific directory and then execute pipenv run python script.py

The run_script.sh works correctly if manually executed, but when is triggered by cron it returns an error of importing a library which is present in python3 (the script.py is written in python3) but not in python2. So i assume that for some reason there's gotta be a problem when setting up the venv using pipenv even though the logs only show an import library error.

I've tried changing the run_script.sh to pipenv run python3 script.py and still got the same error log.

Also tried setting the PATH env in both the cron file and the run_script.sh adding the path to python3 to the existing PATH and that didn't work for me neither.

Lastly i sudo apt update && upgrade the machine and still the script doesn't work.

Here are the outputs of uname -a and lsb_release -a:

Linux ubuntu 5.7.0-2-amd64 #1 SMP Debian 5.7.10-1 (2020-07-26) x86_64 GNU/Linux


No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

Thanks in advance!

2
  • because thru a cron, the initialization of the process is different, all of your .profiles and things like that will not be run. So the environment is different.
    – Rob
    Commented Aug 25, 2021 at 20:51
  • what's weird is that the script used to run correctly until a few days ago, and i've changed nothing sice it has stopped running. I'm really lost here
    – Seba Rossi
    Commented Aug 26, 2021 at 16:26

1 Answer 1

-2

Jobs run through cron, or systemd startup scripts aren't run in the same runtime environment that you have on your desktop. systemd startup scripts are run as root. None of your PATH changes, or other environment variable settings are automatically propagated to your cron job. For example, there's no $DISPLAY, so GUI programs need special treatment (read man xhost).

One can set environment variables for all one's cron jobs in the crontab file Read man 5 crontab.

Look at the results of echo "=== id ===";id;echo "=== set ===";set;echo "=== env ===";env | sort;echo "=== alias ===";alias in each of your environments.

Since the command part of the crontab line is, by default, interpreted by /bin/sh, which has a simpler syntax than /bin/bash, I recommend having command be a call to a bash script (executable, mounted, starts with #!/bin/bash) which sets up the environment, then calls the desired program.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .