KamoCRM

Start probing at 15s, not 190 — nothing could open on its first wake

FixKlusterServices
관련 상품
2026년 9월 23일 오후 6:17 UTC
이름 *
Kamo
뚱 베어
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.

모든 변경 사항

배송을 보는 것과 같이?

모든 것이 자신의 작업 공간에서 도착합니다. 무료 플랜을 시작하고 이 페이지를 다시 한 달에 읽으십시오.

무료 영원히 시작가격 비교