- Name
- lúc 18:17 23 tháng 9, 2026 UTC
- Tác giả
- Kamo
- Cam kết
- da96018
A woken computer is only reachable once its Service has endpoints, and that happens when the readiness probe on 3389 first passes. initialDelaySeconds was 180, which KubeVirt renders as 190, and openHostedComputer gave up waiting at 180. So the tab timed out BEFORE the guest had been probed even once — every time, on every tier. A member had to close the tab and click again, by which point the probe had passed and it worked, which is exactly the shape that makes a bug look like flakiness. The original comment reasoned correctly and concluded wrongly: a resume does read a whole guest memory image off a Longhorn volume, and a 16Gi tier does take longer than a cold boot. But initialDelaySeconds is when probing BEGINS, not how long the guest is given. A tcpSocket probe against a port nothing is listening on simply fails, which is the state the pod is already in — so an early probe costs nothing, and a late one costs every computer the difference between "opens" and "did not". Now 15s: the Service gets endpoints about ten seconds after xrdp starts listening, roughly a minute into boot rather than after three and a half. Worth recording for the next person reading xrdp.log: those probes leave real-looking errors in it, ten seconds apart — Socket 12: connection received from ... [ERROR] libxrdp_force_read: header read error [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU failed A tcpSocket probe connects and closes without speaking RDP, so that is what a HEALTHY computer's log looks like. It is not a failed session, and the ten-second spacing is the tell.