Crontask command exits with code 0 on LockError/LockNotOwnedError — is this intentional?

[lewoudar]

Hi, thanks for this package — it's been working well for us.

I ran into an interesting edge case around the exit code of the crontask management command when the Redis lock can't be acquired. Looking at crontask.py:

except utils.LockNotOwnedError as e:
    capture_exception(e)
    self.stderr.write(
        "The lock is no longer owned by the scheduler. Shutting down."
    )
except utils.LockError as e:
    capture_exception(e)
    self.stderr.write("Another scheduler is already running.")

Both exceptions are caught, reported to Sentry, and written to stderr, but handle() then returns normally — so the process exits with code 0.

Context: we run this on Fly.io Machines, with two replicas of the same process group (a primary + a standby) for HA. On deploy, both instances briefly race for the lock. The loser exits cleanly (as designed, I assume — it's not really an error, just "someone else already grabbed the lock"). The problem is that Fly's default machine restart policy is on-failure, which only restarts on a non-zero exit code. Since the loser exits 0, it's never restarted — it just sits stopped indefinitely until someone manually restarts it, even though crontask is meant to run continuously as a long-lived daemon.

I suspect the current behavior assumes an orchestrator that reconciles process count independently of exit code (e.g., a Kubernetes Deployment, which keeps N replicas alive regardless of container exit status) — which isn't the case on every platform.

Was exiting 0 here a deliberate choice (treating "lost the lock race" as a non-error, expected outcome), or would you be open to exiting non-zero in these cases (or making it configurable) so that exit-code-based supervisors can restart the instance too? Happy to open a PR if that's a welcome direction — just wanted to check the intent first.

Thanks!