fix(deploy): swap the runtime while the service is down #64
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: mi/werkator#64
Reference in New Issue
Block a user
A self-deployment replaced the running instance's runtime directory
underneath it, and for the thirty seconds until the restart that
instance could not start a single child process:
The JVM resolves jspawnhelper under its own java.home, which is a path
inside the installed runtime, and the deployment had just put a
different runtime there. All six repositories reported their origin as
unreachable at that instant, and the metrics sample of that moment was
wrong for a month afterwards (PR#63 stopped that consequence; this is
its cause).
The build therefore installs nothing now. It stages the new runtime as
werkator.new and proves it starts here, and the transient unit does the
rest in the order that matters: stop, swap, start. The JVM being
replaced never sees its own runtime change.
The fixed delay goes with it. Thirty seconds was a guess at when the
deploy build would be recorded — too short would recover it as
interrupted and deploy again, so it was chosen long. The unit now asks
the instance instead: a build leaves the running list only after its
status and artifacts are written, so an idle instance is the condition
the delay was guessing at, and it is usually true within seconds. After
ten minutes it restarts regardless and says so.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
A self-deployment replaced the running instance's runtime directory underneath it, and for the thirty seconds until the restart that instance could not start a single child process: Cannot run program "git": Failed to exec spawn helper The JVM resolves jspawnhelper under its own java.home, which is a path inside the installed runtime, and the deployment had just put a different runtime there. All six repositories reported their origin as unreachable at that instant, and the metrics sample of that moment was wrong for a month afterwards (PR#63 stopped that consequence; this is its cause). The build therefore installs nothing now. It stages the new runtime as werkator.new and proves it starts here, and the transient unit does the rest in the order that matters: stop, swap, start. The JVM being replaced never sees its own runtime change. The fixed delay goes with it. Thirty seconds was a guess at when the deploy build would be recorded — too short would recover it as interrupted and deploy again, so it was chosen long. The unit now asks the instance instead: a build leaves the running list only after its status and artifacts are written, so an idle instance is the condition the delay was guessing at, and it is usually true within seconds. After ten minutes it restarts regardless and says so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>