If the upgrade --schedule causes a new cron task to start while the previous upgrade is still running, the follow-up upgrade should fail, and the initial upgrade should be allowed to run to completion.
This should already work for the systemd exec mechanism, but the kube locking is presumably broken: the overlapping cron task will acquire the lock since it already has the correct value, fail on the systemd exec, and then release the lock... leaving the initial upgrade running with the lock cleared.
If the upgrade
--schedule
causes a new cron task to start while the previous upgrade is still running, the follow-up upgrade should fail, and the initial upgrade should be allowed to run to completion.This should already work for the systemd exec mechanism, but the kube locking is presumably broken: the overlapping cron task will acquire the lock since it already has the correct value, fail on the systemd exec, and then release the lock... leaving the initial upgrade running with the lock cleared.
The log is missing the failing lock release for the initial cron task, because the pod crashes with the
log.Fatalf
for the overlapping cron task.