Skip to content

fix: wait for network restore before exec in snapshot clones #211

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.

Sign up for GitHub

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

Closed
claude-claude wants to merge 1 commit into from
Closed

fix: wait for network restore before exec in snapshot clones #211

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions src/commands/snapshot.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -825,6 +825,16 @@ pub async fn cmd_snapshot_run(args: SnapshotRunArgs) -> Result<()> {

tokio::time::sleep(VSOCK_POLL_INTERVAL).await;
}

// After snapshot restore, fc-agent needs time to complete network initialization:
// - Detect restore-epoch change (polls every 100ms)
// - Execute handle_clone_restore(): flush ARP, send NDP NA for IPv6
// Without this delay, container exec fails with "no such container" because
// the container's network isn't fully ready (IPv6 NDP not announced to slirp4netns).
// 300ms allows: 100ms max for restore-epoch detection + 200ms for network setup.
info!("waiting 300ms for fc-agent to complete network restore after snapshot clone");
tokio::time::sleep(Duration::from_millis(300)).await;

let exit_code = crate::commands::exec::run_exec_in_vm(
&vsock_socket,
&cmd_args,
Expand Down
Loading