Handle tracker not resolvable / reachable

[derpeter]

If the tracker is not reachable we still try to set the ticket failed which results in an error.

C3TT.setTicketFailed[b'C3TTException: A OS error occurred\nError message: [Errno -2] Name or service not known',

[a-tze]

Maybe the script should follow the behaviour of the perl stuff: try it every n seconds for a decent amount of time (like 100 times). If the tracker is unreachable, there is no downside in having the script "hang", it would not get a new workload on the next run anyways.

[derpeter]

I would prefer that it ends it self gracefully and get retriggert by the systemd unit timer.
But independent of how we handle the retry, trying to set the ticket failed is an useless behavior that i want to fix.

[a-tze]

Yes, setting the ticket failed is useless because it will probably not work anyway. It will not be retriggered anyway: if setting ticket failed succeeds, it is not given to the worker again. If nothing is done with the ticket, it is still in state releasing and owned by the worker, and will also not be given to any worker without someone manually fixing this.
Self-healing in a retry loop has indeed the disadvantage that the worker is blocked for some time, but if the tracker is unreachable, that doesnt matter much.

Does producing an error have an impact on the systemd service/timer? Does systemd suspend the timer or something?

[derpeter]

At the point this error happens in the code the script has no ticket, so it will not work in any case :-)
It has not impact on systemd but i see not harm in trying it each timer interval.
I can check if there is way to tell systemd to suspend a timer for specific time if the exit code is non 0.

[a-tze]

Ahhh okay. Then it makes perfectly sense to gracefully exit! I thought you're referring to the tracker communication at the end of the script run, when it tries to call "setTicketDone"!

[derpeter]

sorry is this was misleading.