CODEWITHSUNDEEP
pythonexceptioncrashsystemd
ESilk
ESilk

Reputation: 302

"Crash-proofing" script vs.using systemd to guarantee near-constant operation

Perhaps this is a broad question, but I haven't found an answer elsewhere, so here goes.

The Python script I'm writing needs to run constantly (in a perfect world, I recognize this may not be exactly possible) on a deployed device. I've already dedicated time to adding "try...except" statements throughout so that, should an issue arise, the script will recover and continue to work.

The issue is that I'm not sure I can (nor should) handle every single possible exception that may be thrown. As such, I've decided it may be better to allow the script to die and to use systemd to restart it.

The three options:

The third choice seems the most reasonable to me. So the question is this: What factors should be considered when optimizing between "crash-proof" code and allowing a crash and restart by systemd?

For some more application specific information: there is a small but noticeable overhead involved with starting the script, the main portion will run between 50 to 100 times per second, it is not "mission critical" in that there will be no death/damage in the event of failure (just some data loss), and I already expect intermittent issues with the network it will be on.

Upvotes: 0

Views: 61

Answers (1)

Mark Stosberg
Mark Stosberg

Reputation: 13401

All known exceptional cases should be handled. Any undefined behavior is a potential security issue.

As you suggest, it is also prudent to plan for unknown exceptions. Perhaps there's also a small memory leak that will also cause the application to crash even when it's running correctly. So, it's still prudent to have systemd automatically restart it if it fails, even when all expected failure modes have been handled.

Upvotes: 1

Related Questions