systrap kills healthy sandboxes that the host stalled for more than 30 seconds #16160

Problem

When a systrap context doesn't answer, sleepOnStateWithTimeout interrupts its stub and kills the stub subprocess once stuckContextTimeout (30 s) of wall-clock time has passed. If the host stops the whole sandbox for longer than that (cgroup freezer, SIGSTOP, VM suspend or live migration), the stub threads are stopped too, but the wall-clock deadline keeps running. When the sandbox resumes, the first Sentry wakeup sees the deadline already passed and kills the context, so a healthy application dies with "Systrap context is stuck" right after the thaw. Low CPU quotas make this more likely, since contexts are more often waiting on their stubs when the freeze happens.

Reproduction: run sandboxes with a multi-threaded spin loop under a CFS quota, freeze their cgroup (or SIGSTOP all their processes) for 35-40 s, then release them. On master, the application was killed in 663 of 4,736 stalled sandbox-cycles (14%).

Part of the Lightspeed milestone as this crash occurs under high-density scenarios.

Proposed fix

Measure each futex sleep in that loop and, when a wakeup returns more than 1 s later than its timeout, treat the overrun as a host stall: push the deadline back by the stall and guarantee at least one more checkup interval after the sandbox runs again. The check needs to run on every wakeup, not only on ETIMEDOUT, because a stall can end in a signal wakeup. A stub that is really stuck is still killed once the sandbox has actually run for the stuck timeout. The cost is that a Sentry so overloaded that every checkup waits over 1 s for a Go P would kill a stuck stub late. A patch is available at master...EtiennePerot:gvisor:autoresearch/systrap-freeze-watchdog.