- Expédié
- 23 septembre 2026 à 18:17 UTC
- Auteur
- Kamo
- Commit
- da96018
Un ordinateur réveillé n'est accessible qu'une fois que son Service a des paramètres, et cela se produit lorsque la sonde de préparation sur 3389 passe. les DelaySecond initial étaient 180, qui KubeVirt rend 190, et openHostedComputer abandonne l'attente à 180. Donc l'onglet avant que l'invité n'ait été sondé une seule fois, à chaque niveau. A membre a dû fermer l'onglet et cliquer à nouveau, par quel point la sonde avait passé et ça a marché, ce qui est exactement la forme qui fait qu'un bug ressemble à de la flaquidité. Le commentaire original raisonné correctement et conclu à tort: un CV toute l'image de mémoire de l'invité sur un volume Longhorn, et un niveau 16Gi prend plus de Une botte froide. Mais initialDelaySeconds est quand l'examen BEGINS, pas combien de temps l'invité est donné. Une sonde tcpSocket contre un port que rien n'écoute simplement échoue, qui est l'état où se trouve déjà le module — donc une sonde précoce ne coûte rien, et un retard coûte chaque ordinateur la différence entre "ouvre" et "n'a pas". Maintenant 15s: le Service obtient des paramètres environ dix secondes après que xrdp commence à écouter, A peu près une minute dans la botte plutôt qu'après trois et demi. Worth enregistrement pour la prochaine personne lecture xrdp.log: ces sondes laissent l'aspect réel erreurs, dix secondes d'intervalle Socket 12: connexion reçue de ... [ERROR] libxrdp force read: erreur de lecture de l'en-tête [ERROR] [UIT-T X.224] Séquence de connexion : Le CR-TPDU a échoué Une sonde tcpSocket se connecte et se ferme sans parler RDP, donc c'est ce qu'une SANTÉ Le journal de bord de l'ordinateur ressemble à. Ce n'est pas une session ratée, et l'espacement de dix secondes est le dire.