0

I have python script in which i am calling the other script using subprocess.Popen

subprocess.Popen("python sample.py", shell=True)

When running manually sample.py is running fine but when scheduled in cron sample.py is not executing. Please help

Improve this question
7
  • unix.stackexchange.com/editing-help, see the part about code (block) formatting
    – ilkkachu
    Sep 23, 2021 at 11:09
  • What does "is not executing" mean, exactly? What happens instead? Do you get some error message? What does the error say? How are you running it? What do you have in the crontab, exactly? Remember, we can't see into your system to check the actual situation, you'll have to tell the details too.
    – ilkkachu
    Sep 23, 2021 at 11:10
  • let's say i have script test.py. In test.py i am calling some other python script sample.py using subprocess.Popen("python sample.py", shell=True). When calling it from linux terminal like " python test.py " script test.py & sample.py is executed properly. But when i calling from cron the sample.py script is not executing & no error is coming.
    – jazz
    Sep 23, 2021 at 11:17
  • you need to show the code. Everything needed to make the issue present itself. If what you have is too long to post, edit it into a minimal version that shows the issue. It's no use for anyone to guess what you might have there, when you have the actual code in front of you, and could just post it. You can edit your question to add whatever is needed, formatting in comments sucks.
    – ilkkachu
    Sep 23, 2021 at 11:19
  • 1
    PATH and other environnement variable are not set the same way in cron and in interactive session.
    – Archemar
    Sep 23, 2021 at 11:30

1 Answer 1

Reset to default
-3

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 from ~/.bashrc 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.

Improve this answer
3
  • I don't think the text about $DISPLAY or /bin/sh or /bin/bash is relevant here at all. The user is using Python, not a shell script.
    – Kusalananda ♦
    Sep 23, 2021 at 13:50
  • @Kusalananda It's an explanation of how the execution environment differs between desktop and cron. The original problem (and many others like it) is caused by a misunderstanding of execution environments.
    – waltinator
    Sep 23, 2021 at 19:25
  • Absolutely, but what does it mean in the context of this particular question, and what is the implication given what the questioner is doing?
    – Kusalananda ♦
    Sep 23, 2021 at 19:28

You must log in to answer this question.

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