Forums

Sorry for my constant messages to the forums, but I'm just getting used to this service. Last night I set up several python consoles, and when I came back from school today they were all reset. Is this something that happens periodically or was it just a bizarre bug? Thank you :)

Hello,

My understanding (which could be wrong) is that when the software running PythonAnywhere is updated, then the console server is restarted. And this happens (approximately) once a week - but it could be more often is there is a bug fix they want to get live.

If you want your shell/python scripts to persist, can I recommend using a scheduled task to check if things are up and running and to restart it if it goes down

Thanks

Robert

rcs1000 is entirely correct, but we didn't update PythonAnywhere last night. So while I'd definitely recommend that you use scheduled tasks as he suggests, there's something odd happening here. Which consoles were they? If you give me the console names or URLs (don't worry, they'll remain private to you) then I can take a look at our logs for errors.

Sorry, I cleared the consoles so I don't know their URLs anymore. I tried setting up tasks but I have more than 10 programs. Is there any other way to manage this?

It's still a mystery. Maybe your programs are crashing. COuld you put in some logging to see what they are doing?

To run multiple programs on a scheduled task, you can just use a bash script that runs the other programs.

Or use a wrapper script with subprocess. I used to have a utility script somewhere which would launch a set of other commands in parallel with subprocess and collect their output, and email it off if the return code ended up being non-zero. Unfortunately I think I left it at a previous company and no longer have a copy... Not very tricky to write something like that, though.

EDIT:

I found a spare few minutes to dig through some old backups and found the class I wrote to handle multiple concurrent subprocess invocations. The code is a little large to post in this thread, but I posted it on my wiki for anybody who's interested.

It's not particularly efficient (especially the base class behaviour of buffering all data in a simple str object) but it should be good enough for normal purposes. Also, this bit doesn't handle the emailing and checking the return codes (although it does store the return codes in a dictionary) as those are the parts I don't have any more, but those bits are pretty easy to put in the calling code.