Перезапуск скрипта python при ошибке

while true; do python bot.py; done

Можно с помощью инструкций try/except.

def function():	
	try:
		a = input("Enter a number")
		b = int(a) / 0
	except:
		function()
function()

Поместите туда свой код, при ошибке, функция будет вызвана заново.

29 янв. 2023, в 10:09

2000 руб./за проект

28 янв. 2023, в 13:14

10000 руб./за проект

29 янв. 2023, в 03:07

300000 руб./за проект

This post describes how to keep a child process alive in a BASH script:

How do I write a bash script to restart a process if it dies?

This worked great for calling another BASH script.

However, I tried executing something similar where the child process is a Python script, daemon.py which creates a forked child process which runs in the background:

#!/bin/bash

PYTHON=/usr/bin/python2.6

function myprocess {


$PYTHON daemon.py start

}
NOW=$(date +"%b-%d-%y")

until myprocess; do
     echo "$NOW Prog crashed. Restarting..." >> error.txt
     sleep 1
done

Now the behaviour is completely different. It seems the python script is no longer a child of of the bash script but seems to have ‘taken over’ the BASH scripts PID — so there is no longer a BASH wrapper round the called script…why?

A daemon process double-forks, as the key point of daemonizing itself — so the PID that the parent-process has is of no value (it’s gone away very soon after the child process started).

Therefore, a daemon process should write its PID to a file in a «well-known location» where by convention the parent process knows where to read it from; with this (traditional) approach, the parent process, if it wants to act as a restarting watchdog, can simply read the daemon process’s PID from the well-known location and periodically check if the daemon is still alive, and restart it when needed.

It takes some care in execution, of course (a «stale» PID will stay in the «well known location» file for a while and the parent must take that into account), and there are possible variants (the daemon could emit a «heartbeat» so that the parent can detect not just dead daemons, but also ones that are «stuck forever», e.g. due to a deadlock, since they stop giving their «heartbeat» [[via UDP broadcast or the like]] — etc etc), but that’s the general idea.

answered Apr 26, 2010 at 15:20

You should look at the Python Enhancement Proposal 3143 (PEP) here. In it Ben suggests including a daemon library in the python standard lib. He goes over LOTS of very good information about daemons and is a pretty easy read. The reference implementation is here.

It seems that the behavior is completely different because here your «daemon.py» is launched in background as a daemon.

In the other link you pointed to the process that is surveyed is not a daemon, it does not start in the background. The launcher simply wait forever that the child process stop.

There is several ways to overcome this. The classical one is the way @Alex explain, using some pid file in conventional places.

Another way could be to build the watchdog inside your running daemon and daemonize the watchdog… this would simulate a correct process that do not break at random (something that shouldn’t occur)…

answered Apr 26, 2010 at 15:20

This post describes how to keep a child process alive in a BASH script:

How do I write a bash script to restart a process if it dies?

This worked great for calling another BASH script.

However, I tried executing something similar where the child process is a Python script, daemon.py which creates a forked child process which runs in the background:

#!/bin/bash

PYTHON=/usr/bin/python2.6

function myprocess {


$PYTHON daemon.py start

}
NOW=$(date +"%b-%d-%y")

until myprocess; do
     echo "$NOW Prog crashed. Restarting..." >> error.txt
     sleep 1
done

Now the behaviour is completely different. It seems the python script is no longer a child of of the bash script but seems to have ‘taken over’ the BASH scripts PID — so there is no longer a BASH wrapper round the called script…why?

A daemon process double-forks, as the key point of daemonizing itself — so the PID that the parent-process has is of no value (it’s gone away very soon after the child process started).

Therefore, a daemon process should write its PID to a file in a «well-known location» where by convention the parent process knows where to read it from; with this (traditional) approach, the parent process, if it wants to act as a restarting watchdog, can simply read the daemon process’s PID from the well-known location and periodically check if the daemon is still alive, and restart it when needed.

It takes some care in execution, of course (a «stale» PID will stay in the «well known location» file for a while and the parent must take that into account), and there are possible variants (the daemon could emit a «heartbeat» so that the parent can detect not just dead daemons, but also ones that are «stuck forever», e.g. due to a deadlock, since they stop giving their «heartbeat» [[via UDP broadcast or the like]] — etc etc), but that’s the general idea.

answered Apr 26, 2010 at 15:20

You should look at the Python Enhancement Proposal 3143 (PEP) here. In it Ben suggests including a daemon library in the python standard lib. He goes over LOTS of very good information about daemons and is a pretty easy read. The reference implementation is here.

It seems that the behavior is completely different because here your «daemon.py» is launched in background as a daemon.

In the other link you pointed to the process that is surveyed is not a daemon, it does not start in the background. The launcher simply wait forever that the child process stop.

There is several ways to overcome this. The classical one is the way @Alex explain, using some pid file in conventional places.

Another way could be to build the watchdog inside your running daemon and daemonize the watchdog… this would simulate a correct process that do not break at random (something that shouldn’t occur)…

answered Apr 26, 2010 at 15:20

arsenalarsenal

2,95317 gold badges43 silver badges49 bronze badges

You shouldn’t really use this for production, but you could:

#!/bin/sh

while true; do
  nohup python testing.py >> test.out
done &

If, for any reason, python process exits, the shell loop will continue and restart it, appending to the .out file as desired. Nearly no overhead and takes very little time to set up.

answered Jan 5, 2014 at 12:17

You can have the testing program redirect the output using a commandline option
and then use a simple python script to restart the program indefinitely:

import subprocess

while True:
    try:
        print subprocess.check_output(['python', 'testing.py'])
    except KeyboardInterrupt:
        break

you can put this program in the background, and once you want to stop just pull it into the foreground and kill it.

answered Jan 5, 2014 at 8:16

There are a number of ways to monitor and respawn processes under UNIX/Linux. One of the oldest is a «respawn» entry in /etc/inittab … if you’re using the old SysV init system. Another method is to use the supervisor daemon from DJ Bernstein’s daemontools package. Other options are to use features in Ubuntu upstart … or systemd or others.

But you can look at alternatives init and in the Python code for Pardus: mudur daemon in particular.

If you decide to go with a cron job (and PID file handling) then consider reading this PEP 3143 and perhaps using its reference implementation.

As I alluded to in my other comments, robust PID file handling is tricky. It’s prone to races and corner cases. It gets trickier if there’s any chance that your PID file ends up on an NFS or other networked filesystem (some of the atomicity guarantees you get with the file handling semantics on proper local UNIX/Linux filesystems go away on some versions and implementations of NFS, for example). Also the semantics around file locking under UNIX can be tricky. (Does an flock or fcntl lock get released promptly, in your target OS, when the process holding it is killed with SIGKILL, for example?).

answered Jan 5, 2014 at 7:58

You can also use monit Or Process monitoring with ps-watcher

Monit is an open source utility for managing and monitoring,
processes, programs, files, directories and filesystems on a UNIX
system. Monit conducts automatic maintenance and repair and can
execute meaningful causal actions in error situations.

Here is example for your scenario:

check process myprocessname
        matching "myprocessname"
        start program = "nohup /usr/bin/python /path/testing.py > /tmp/test.out &"
        stop program = "/usr/bin/killall myprocessname"

Take look at monit examples

answered Jan 5, 2014 at 9:43

You need a supervisor, you can use supervisor. It is python based supervisor, therefore easy to modify if you need to.

Control is with files with .ini file syntax.

answered Jan 5, 2014 at 10:59

Terdon’s answer, did not work for me, because
pgrep -f testing.py was never ‘failing’. It would grab the pid for the cron job (because of the -f option). However, without the -f option pgrep won’t find testing.py because there’s no process called testing.py.

My solution to this was to change

pgrep -f testing.py

to

pgrep -f testing.py | pgrep python

this means the full crontab job would be:

*/5 * * * * pgrep -f testing.py | pgrep python || nohup python /home/you/scripts/testing.py > test.out

In my case, as a quick-fix, I wanted to keep my program running when it exited with en error or it was killed.
On the other hand, I wanted to stop the execution when the program terminated correctly (return code = 0)

I have tested it on Bash. It should work fine in any other shell

#!/bin/sh

echo ""
echo "Use: $0 ./instagram.py"
echo ""

echo "Executing $1 ..."

EXIT_CODE=1
(while [ $EXIT_CODE -gt 0 ]; do
    $1
    # loops on error code: greater-than 0
    EXIT_CODE=$?
done)

answered Dec 27, 2018 at 12:53

For terdon’s answer, pgrep -f testing.py will never return false according to the comments in here:

I think the issue is that cron spawns a shell to run your command, and the arguments of that shell are matched by pgrep since you are using -f

For Matt’s answer, pgrep -f testing.py is useless since pgrep python matches any running Python script. So if two Python script cronjob, the second cronjob will never run.

And then I found the solution to solve pgrep -f testing.py in the comment here: https://askubuntu.com/questions/1014559/running-pgrep-in-a-crontab?noredirect=1&lq=1

My cron for running two Python scripts:

* * * * * pgrep -f '^/usr/bin/python36 /home/ec2-user/myscript1.py' || nohup /usr/bin/python36 /home/ec2-user/myscript1.py

0 * * * * pgrep -f '^/usr/bin/python36 /home/ec2-user/myscript2.py' || nohup /usr/bin/python36 /home/ec2-user/myscript2.py

In Ubuntu this works for me thanks to --wait

#!/bin/bash

while :
do
  sleep 5
  gnome-terminal --wait -- sh -c "python3 myscript.py 'myarg1'"
done

answered Nov 17, 2020 at 20:44

How do you make a python program automatically restart itself? So let’s say there is a really simple program like:

var = input("Hi! I like cheese! Do you like cheese?").lower()
if var == "yes":
    print("That's awesome!")

Now, in a Python Shell, you would have to press either the Run button and then ‘Run Module (F5)’ or just the F5 key on your keyboard. That is the first time you run it. When the program ended, you would go back to your Cheese.py file and then press F5 to run the program again.

Everybody with me here?
OK, so my question is, how do you make the program restart itself automatically without you having to manually do it?

I use terminal on my Mac to re-start some of my python scripts with the function below.

import subprocess  
def run_again(cmd):
    subprocess.call(["bash", "-c", "source ~/.profile; " + cmd])  

Note: Don’t forget the space character after «profile;» or the function may fail silently!

Then at the bottom of my script to be re-started:

if some_condition:  
    run_again("python my_script.py %s" % my_new_arguments)  

For the original question about the cheese script:

if var != 'yes':  
    run_again("python my_cheese_script.py")  

answered Oct 13, 2017 at 18:13

You can just use a shell script like test.sh and make sure in your linux terminal you chmod +x test.sh

As for the code:

#!/bin/bash

while :
do
  sleep 5
  gnome-terminal --wait -- sh -c "python3 myscript.py 'myarg1'"
done

answered Nov 17, 2020 at 20:46