Repository navigation
fix(supervisor): stop recovering a lost boundary after SIGTERM #5342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1800,6 +1800,7 @@ pub async fn run_sandbox_instance( | |
| )); | ||
| } | ||
| () = &mut shutdown_requested => { | ||
| running.begin_stop(); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Two questions about the scope of this:
|
||
| let _ = agent | ||
| .signal(openshell_isolation_interface::contract::BoundarySignal::Term) | ||
| .await; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -52,11 +52,7 @@ const DELETE_DEADLINE: Duration = Duration::from_secs(10); | |
| /// Many workloads do not exit immediately on TERM, for example while they run | ||
| /// cleanup handlers. Deleting such a running sandbox should still complete | ||
| /// promptly, rather than waiting out the runtime's termination grace period. | ||
| // | ||
| // Unignore this when the supervisor half of #5025 lands: on Podman the | ||
| // supervisor container still waits out its stop timeout. | ||
| #[testkit::test] | ||
| #[ignore = "https://github.com/NVIDIA/OpenShell/issues/5025"] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thanks for remembering to remove this! |
||
| async fn delete_is_prompt_when_workload_is_slow_to_handle_term( | ||
| cx: &mut Context, | ||
| ) -> testkit::Result { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this fires during the supervisor's shutdown,
BoundaryProcess::wait()maps it toTerminated("boundary lost during wait: ..."). Then the.map_err(...)?after the 5s wait inrun_sandbox_instancereturnsErr. The supervisor exits with an error and skipspublish_main_exit, the OTLP relay flush, and the gateway exit report.That's no worse than main, where it got SIGKILLed. But now that we fail fast, should the supervisor treat "boundary lost while stopping" as the workload having ended? It could record an exit status, skip
TerminateBoundary, and continue through normal teardown. Otherwise every Podman/K8s delete where the boundary goes first ends with an error-level failure from the supervisor on a routine operation.