[WaylandYang]

These came out of comparing Sandstorm with other sandboxes on a bare-metal machine with KVM (2× Xeon E5-2637 v2, 16 threads, 31 GB). Each one was found by tracing a number that did not add up.

• Gateway waits for a sandbox that is still starting (gateway.rs). A request for a sandbox whose program was not listening yet was held while the gateway retried, backing off from 50 ms up to 500 ms. That held the first answer of an app64 300–370 ms after the program was already listening; on the same machine, Docker with the same runsc answered 6 ms after listen. Retries now start at 5 ms and stop doubling at 50 ms. New test: a program that starts listening at 400 ms must be answered within 600 ms (it fails with the old backoff). Sandstorm on gVisor, cold app64: 941 → 616 ms, now ahead of Docker + gVisor (660 ms).
• Firecracker cold start, 1.95 s → 0.64 s (web) and 2.1 s → 0.96 s (app64). Fixing each cause exposed the next:
  • The guest kernel probed for an i8042 controller that Firecracker does not emulate. Firecracker's recommended i8042 boot options are now set, and asserted in boot_args' test.
  • The agent imported numpy in PID 1 before starting the template's program. It now imports numpy on first eval, and reads the version from package metadata.
  • The gateway's connect waited a full second for the kernel to resend a dropped SYN. It now sends a fresh SYN every 50 ms (connect_upstream).
  • The main one: the netns's first packet to a guest that was still booting triggered an ARP request that got no answer, and the kernel asked again only a second later. tcpdump showed every SYN leaving together at +1,101 ms. The guest's MAC is fixed, so its neighbour entry is now permanent too (ip neigh … nud permanent in ensure_tap, which pooled namespaces also get).
  • The tap now has a fixed MAC as well. A restored guest keeps the seed's tap in its ARP cache, and while the netns ARPed for the guest, the guest refreshed that entry from the request. With the guest's entry pinned, nothing asks any more, so warm starts took 43 s until the stale entry expired. With a fixed tap MAC, warm starts are back to 133 / 183 ms.
  • quiet on the kernel command line. Every byte printed to ttyS0 costs a VM exit through the emulated serial port, and a boot printed 273 lines. Web 861 → 652 ms, app64 1,167 → 1,066 ms.
  • The agent now starts the template's program first, using posix_spawn before importing anything else, so the program no longer waits behind the agent's own startup on the single vCPU. Web 652 → 636 ms, app64 1,066 → 964 ms.
  • Tried and dropped: two vCPUs per guest. Web went 636 → 597 ms and app64 was unchanged, at the cost of a second vCPU thread in every VM.
• Guest hostname (sandstorm-init.sh). The kernel names a guest after its IP, and Python's HTTPServer resolves the hostname before it listens. With no resolver reachable, that waited out a timeout: 20 s per Firecracker sandbox on bm. The init now names the guest sandbox and writes that name to /etc/hosts.
• Overlapping gateway port ranges (main.rs). Two master-and-node processes on one machine both allocated gateway ports from 20000, so the second sandbox on a taken port never became reachable. A master-and-node now records its range under /run/sandstorm/gateway-ports and refuses to start if it overlaps a running process's range, naming that process and the --port-min and --port-max flags to fix it.

Tests

• Linux (the bare-metal machine): cargo test 208 passed, clippy clean, and agent unittest 32 passed.
• macOS: the same, except the three detach_tests that also fail on unmodified dev there.

Each change was also checked on the machine itself: the port refusal message, tcpdump before and after the neighbour entry, and start times before and after.

🤖 Generated with Claude Code