Ĉu vim frostas super SSH? Kontrolu stty antaŭ ol kulpigi la VPN
Frostinta redaktilo super SSH kutime estas problemo de terminala stato, ne rompita tunelo. Legu stty sur la ĝusta pseŭdoterminalo, poste riparu nur tiun.
Tiaj sesioj restas konektitaj dum la redaktilo startas, poste la ekrano ĉesas ĝisdatiĝi eĉ kvankam la SSH-procezo klare vivas. Tajpado produktas nenion, Ctrl-C ŝajnas fari nenion, kaj la evidenta konkludo estas ke la VPN faligis ion. Plej ofte la tunelo estas en ordo kaj la fora pseŭdoterminalo estas en stato kiun neniu intencis, ĉar eĥo, kanonika enigo kaj fluo-kontrolo loĝas en la terminalo kaj ne en la reto. Trovi kiun el tiuj tri moviĝis estas tasko de du komandoj.
La frostiĝo loĝas en la terminalo, ne en la tunelo
Pseŭdoterminalo portas pli ol bitokojn. Ĝi tenas flagojn de linia disciplino kiuj decidas ĉu enigo estas eĥata, ĉu legadoj atendas novan linion, ĉu certaj signoj generas signalojn kaj ĉu eligo povas esti haltigita per rega signo. Interaga redaktilo ŝaltas tiun terminalon al kruda reĝimo por la daŭro kaj devus restarigi la antaŭajn agordojn ĉe eliro. Kiam la restarigo ne okazas, la ŝelo al kiu vi revenas ne estas la ŝelo kiun vi lasis, eĉ se la konekto neniam rompiĝis.
Komparu terminalojn antaŭ ol konkludi ion. Dua sesio kun la sama redaktilo pruvas ke la kliento kaj la vojo povas fari la laboron; ĝi diras nenion pri la terminalo kies flagoj estas rompitaj.
Legu la agordojn sur la terminalo kiu frostis
Unue identigu la aparaton, poste legu ambaŭ formojn de ĝia stato. La legebla formo montras kio estas agordita, kaj la maŝina formo estas tiu kiun vi povas reenigi poste.
tty
stty -a
stty -g
Tri flagogrupoj klarigas la plej multajn el tiuj raportoj. Eĥaj agordoj decidas ĉu klavopremoj entute aperas, do terminalo kun eĥo malŝaltita aspektas morta dum la ŝelo ricevas ĉiun signon. Kanonika reĝimo decidas ĉu programo vidas enigon unu linion samtempe, do terminalo lasita en kanonika reĝimo igas aplikacion en kruda reĝimo ŝajni ignori klavojn ĝis Enter. Fluo-kontrolaj agordoj decidas ĉu la terminalo obeas la signojn XON kaj XOFF, kaj tiu grupo produktas la plej konvinkan falsan frostiĝon el la tri.
Registru la eligon antaŭ ol ŝanĝi ion, precipe kiam la sesio portas proprajn klavligojn de kiuj iu dependas. La maŝina formo estas la plej sekura registro, kun la kondiĉo ke ĝi dependas de la efektivigo kaj devus esti restarigita de la sama speco de sistemo kiu produktis ĝin.
Riparu tiun terminalon, ne la sesion en kiu vi tajpas
La norma riparo restarigas la sanan profilon kiun listigas la manlibra paĝo, kaj ĝi tuŝas nur unu terminalon. Se la redaktilo ankoraŭ tenas nekonservitan laboron en tiu terminalo, lasu ĝin ĝis la laboro estos konservita.
El alia ŝelo, celigu eksplicite la frostintan aparaton por ke la terminalo en kiu vi laboras restu netuŝita.
stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane
Malplena ekrano kun difektita afiŝo estas aparta problemo de rompita linia disciplino, kaj la programo reset traktas ĝin elsendante terminalajn pravalorizajn sekvencojn. Provu unue la statan riparon, ĉar ĝi ŝanĝas agordojn kiujn vi povas inspekti, dum la reset-sekvenco reskribas la ekranon kaj klarigas nenion pri tio kiel ĝi rompiĝis.
La kaptilo Ctrl-S malantaŭ konvinka frostiĝo
Kiam programara fluo-kontrolo estas ŝaltita kaj la kutimaj signoj estas asignitaj, Ctrl-S diras al la terminalo ĉesi sendi eligon kaj Ctrl-Q diras al ĝi rekomenci. La sesio restas viva la tutan tempon, unu sola Ctrl-Q ofte estas la tuta riparo, kaj nenio aperas en iu ajn protokolo, kaj tiel ĉi tiu frostiĝo postvivas tiom da eskaladoj.
Inspektu la faktajn agordojn anstataŭ supozi ilin. La komencaj kaj haltaj signoj povas esti reasignitaj aŭ malŝaltitaj, kaj terminalo kun fluo-kontrolo malŝaltita ne reagos al iu el ili.
Se la stato revenas, aŭ se SSH mem haltas
Ripetiĝanta malbona stato indikas ion kio ŝanĝas la flagojn sen restarigi ilin: startdosiero, ĉirkaŭa skripto, multigilo kiu restarigas la malĝustan fenestron, aŭ aplikaĵo kiu mortas tenante la krudan reĝimon. Aldonu kondiĉan kontrolon kiu raportas la staton anstataŭ senkondiĉa restarigo, ĉar ĝenerala restarigo kaŝas la kaŭzon kaj povas superregi intencajn agordojn.
Kiam ankaŭ ordinara SSH-trafiko haltas, aŭ la riparo ŝanĝas nenion, la terminalo ĉesas esti la suspektato.
ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com
Halto kiu aperas nur dum grandaj transigoj sugestas MTU-problemon sur la vojo, dum tiu kiu ankaŭ englutas unuopajn klavopremojn indikas la vojon aŭ la servilon kaj ne la pakgrandon. Tenu la terminalajn pruvojn aparte de la retaj pruvoj, ĉar funkcianta redaktilo en dua sesio ne estas pruvo ke la unua terminalo iam estis sana.