Forums

Scheduled task aborts silently

[SOLVED - the error was due to the default version of Python used on scheduled task -- 2.7 vs 3.6. The script choked on an unrecognized UTF-8 string]

Runs a+ from the console.

Aborts after a few seconds when scheduled.

I suspect that it violates some implicit rule. The script fires requests to an API at a very rapid rate. (3+/second average. Probably faster bursts)

[EDIT - inserting a short sleep does not solve the problem]

What is a+? Do you have a link? If it is also printing to the screen, it is possible that your console is getting killed for spamming too much output.

The script is at /home/gauvins/tracksHunter/search.py

A+ meant no problem. Executes 100% all the time. (What would have been the British equivalent? :)

aha! sorry thought it was some a/b testing thing.

One thing I can think of is that maybe someone on that same task server is also firing out requests at a very rapid rate, and so you are getting rate limited by that API endpoint when you do it from the task server but not from the console server. Now- when you say that the task aborts, do you have an error message we can debug?

I see you've emailed about this too -- will reply back over email, and we can post back here if we discover something generally useful.

Thanks for your time.

Well, finally it looks like the problem was that scheduled tasks run on 2.7 while the default for new scripts (if I understand correctly) is 3.6

As it happens, 2.7 doesn't handle UTF-8 "natively", while 3.6 does. Which explains why the script ran within a console, but aborted as a scheduled task.

A couple of other factors contributed to my being misled wrt throttling.

All is well.

For now :)

Excellent, glad you worked it out :-) You've probably already worked this out, but for anyone else reading -- the way to force a particular version of Python for a scheduled task is to specify the interpreter explicitly in the scheduled task definition. That is, instead of scheduling this:

/home/yourusername/something/script.py

...schedule this:

python3.6 /home/yourusername/something/script.py

Actually, I've used an hashbang. (#!/usr/bin/python3.6)

Thanks for the tip.

Right, that would work too. I think there would be some problems with it if you were using a virtualenv, though -- the hashbang-detection logic isn't quite smart enough for that -- so an explicit interpreter is generally safer.