Forums

Scheduled tasks killed, return code 137

Hey all,

for a few days now (I don't recall exactly when it started), my scheduled tasks have been consistently getting killed after a runtime of roughly an hour. Previously they ran fine for hours or days on end, only occasionally stopping due to restarts on the server side (Which are normal, as far as I'm informed).

The way the script is set up it very briefly interacts with some external websites (reddit, google), then waits for about five minutes to do it again. But now it sometimes, seemingly at random, stops right after these waiting periods and before anything else happens. This is what the log says:

....
INFO:requests.packages.urllib3.connectionpool:Resetting dropped connection: oauth.reddit.com
INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (5): oauth.reddit.com
INFO:root:Accessed Reddit at: 2015-10-22 12:58:53
/bin/bash: line 1: 12671 Killed                  python /bin/run_scheduled_task.py 'python2.6 calendarbot.py'

2015-10-22 13:03:05 -- Completed task, took 5761.00 seconds, return code was 137.

I have another logging.info() call right after time.sleep(300), but it doesn't get there. Also, the "took 5761.00 seconds" seems to come from somewhere else, because this script only uses about 3 seconds of processor time per hour.

I'm at a loss here, could this be somehow caused by PythonAnywhere, or is it more likely that there's a bug in my script?

Hi there,

We've been dealing with some scaling issues on the task server, and as a temporary measure we've had to restrict the maximum allowed run-time for scheduled tasks. It's currently 1 hour for free users and 6 hours for paying users -- although we're constantly tweaking it, and we hope to get back to more permissive settings as soon as possible...

Sorry for the inconvenience :/

Hello, Is this limit still in force, please? My scheduled job was killed after 10248 seconds. Any plans to remove/extend it? Thanks!

Yes, the limit is still in force. The one hour limit still stands for free accounts, but it's not a "hard" limit -- that is, your task should definitely not be killed after less than 3,600 seconds, but you may get more (depending on what else is happening on the system).

We are planning to add support for "long-running" tasks which would stay running 24/7 (or be restarted if they crash). However, this may wind up being a paid-only feature.

Hello I am wanting to run my task 24/7, but it seems to only last an hour. Would the paid feature allow 24/7? And how much is it?

For a paying account, we clear down scheduled tasks after 24 hours. We are also running a beta for "always on" tasks that we have not decided how to charge for yet.

Hello, have a similar question in another thread. I am seeing that the 1 month expiry is not really a month (for free accounts). Can someone update me to the status lengths of a FREE account (currently I am getting a three hour and then a 137 killed) and a PAID account (always active). Trying to set up something that will monitor hashtag tweets on twitter (which I have working) but I cannot have it die shortly after its kicked off.

Hi- the expiry is when we will deactivate your task and stop running it again ever. We do this to avoid say someone setting a task and forgetting about it. On the other hand, the scheduled task is meant to be for tasks that say run every day and take 5min to run and then stop. Have responded to you here as well.

I'm having a similar issue. I have a scheduled task running a script that gets data from an API on a loop with short wait due to rate limits. The whole script takes about 2.75 hours to run. During development, I set up a scheduled task to execute during the day for testing. The scheduled task consistently runs fine during the day. But when I schedule it to run early in the morning, it gets killed every time, less than halfway through, with return code 137. I am a paying customer, and am nowhere close to maxing out my daily CPU quota. Why would it run fine during the day and always get killed in the early morning?

Is it perhaps running out of memory? If it is, we will be sending you an email letting you know.

Yes, I just found the emails. It is running out of memory. I will break this into smaller tasks. Odd that sometimes it doesn't run out of memory, though.

Thanks for the reply.

Hi team, I have a similar issue than @AmplifiBi running a script that aggregates data running a list of mysql queries (DB hosted on AWS). Can you please help me check out what's going on and why am I seeing the return code 137.

Thanks, endco

Did you receive emails from us about your tasks crashing?