Skip to content

ephemeral run: Add timeout to status monitor to prevent indefinite hang#300

Open
gursewak1997 wants to merge 1 commit into
mainfrom
fix-monitor-timeout
Open

ephemeral run: Add timeout to status monitor to prevent indefinite hang#300
gursewak1997 wants to merge 1 commit into
mainfrom
fix-monitor-timeout

Conversation

@gursewak1997

@gursewak1997 gursewak1997 commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Previously wait_for_vm_ssh() blocked indefinitely on the vsock status monitor when boot notifications silently failed. Instead, run the vsock monitor and SSH polling concurrently; whichever succeeds first wins. This avoids the hang without sacrificing boot progress reporting on systems where vsock works.

Closes: #279

@cgwalters cgwalters left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A full 60s delay is a poor UX. I think it'd be better to do vsock and ssh polling in parallel - if vsock gives us some data, then we can stop ssh polling (until we see startup complete). But if (as in this case) vsock doesn't give us anything but we succeed at logging in through ssh - great.

Or, since vsock isn't reliable...we could just drop it.

// main loop. Without this, BufRead::lines() blocks indefinitely when the
// monitor stops emitting updates (e.g. vsock notifications silently fail).
let (tx, rx) = std::sync::mpsc::channel::<std::io::Result<String>>();
std::thread::spawn(move || {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a larger refactoring, but I think it'd be better to use async rust for this stuff.

(I wouldn't be surprised if we were calling a blocking sync function from async)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to do that as a follow-up, but keeping this PR scoped to the concurrency fix with thread+channel since the infrastructure is already sync.

@gursewak1997
gursewak1997 force-pushed the fix-monitor-timeout branch 3 times, most recently from 12f86e9 to 4c6f698 Compare July 17, 2026 20:15
Comment thread crates/kit/src/run_ephemeral_ssh.rs Outdated
debug!("Waiting for systemd to initialize...");
// Drain any available status updates from the monitor (non-blocking).
if let Some(ref rx) = monitor_rx {
while let Ok(line) = rx.try_recv() {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this is going to burn 100% of a CPU core busy polling right?

That's the kind of thing I mean in that while yes, it's a larger refactor to do async, it's also tricky to do this efficiently and properly without async.

If we're putting off that refactor, it may be cleanest to have the overall timeout and ssh subprocess polling be their own threads that writes to the channel, then this parent thread waits on events.

Previously wait_for_vm_ssh() blocked indefinitely on the vsock status
monitor when boot notifications silently failed. Instead, run the
vsock monitor and SSH polling concurrently — whichever succeeds first
wins. This avoids the hang without sacrificing boot progress reporting
on systems where vsock works.

Closes: #279

Assisted-by: AI
Signed-off-by: gursewak1997 <gursmangat@gmail.com>
@gursewak1997
gursewak1997 force-pushed the fix-monitor-timeout branch from 4c6f698 to 84e7daa Compare July 17, 2026 22:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

to-base-disk hangs at Waiting for systemd

2 participants