Vries vim oor SSH? Kyk eers na stty voordat jy die VPN blameer

Sessies soos hierdie bly gekonnekteer terwyl die redigeerder begin, en dan hou die skerm op met opdateer selfs al is die SSH-proses duidelik lewendig. Tik lewer niks op nie, Ctrl-C lyk of dit niks doen nie, en die ooglopende gevolgtrekking is dat die VPN iets laat val het. Die meeste van die tyd is die tonnel heeltemal reg en is die afgeleë pseudoterminaal in 'n toestand wat niemand beplan het nie, want echo, kanonieke invoer en vloeibeheer woon in die terminaal en nie in die netwerk nie. Om uit te vind watter van daardie drie geskuif het, is 'n taak van twee opdragte.

Die vriesing sit in die terminaal, nie in die tonnel nie

'n Pseudoterminaal dra meer as net grepe. Dit hou lynbeheervlae wat besluit of invoer weergegee word, of lesings op 'n nuwe reël wag, of sekere karakters seine genereer, en of uitset deur 'n beheerkarakter gestop kan word. 'n Interaktiewe redigeerder skakel daardie terminaal vir die duur na rou modus en behoort die vorige instellings by uitgang te herstel. Wanneer die herstel nie gebeur nie, is die dop waarna jy terugkeer nie die dop wat jy verlaat het nie, selfs al het die verbinding nooit gebreek nie.

Vergelyk terminale voordat jy enigiets aflei. 'n Tweede sessie wat dieselfde redigeerder laat loop, bewys dat die kliënt en die pad die werk kan doen; dit sê niks oor die terminaal wie se vlae stukkend is nie.

Lees die instellings op die terminaal wat gevries het

Identifiseer eers die toestel en lees dan albei vorme van sy toestand. Die leesbare vorm wys wat ingestel is, en die masjienvorm is die een wat jy later kan terugvoer.

tty
stty -a
stty -g

Drie vlaggroepe verduidelik die meeste van hierdie verslae. Echo-instellings besluit of toetsaanslae hoegenaamd verskyn, so 'n terminaal met echo af lyk dood terwyl die dop elke karakter ontvang. Kanoniese modus besluit of 'n program invoer een reël op 'n slag sien, so 'n terminaal wat in kanoniese modus gelaat is, laat 'n toepassing in rou modus lyk of dit sleutels ignoreer tot Enter. Vloeibeheer-instellings besluit of die terminaal XON- en XOFF-karakters gehoorsaam, en daardie groep lewer die mees oortuigende valse vriesing van die drie.

Teken die uitset aan voordat jy enigiets verander, veral wanneer die sessie pasgemaakte sleutelbindings dra waarop iemand staatmaak. Die masjienvorm is die veiligste rekord, met die voorbehoud dat dit implementasie-spesifiek is en deur dieselfde soort stelsel wat dit gemaak het, herstel moet word.

Herstel daardie een terminaal, nie die sessie waarin jy tik nie

Die standaardherstel bring die sane-profiel terug wat die handleiding lys, en dit raak net een terminaal. As die redigeerder nog ongestoorde werk in daardie terminaal hou, laat dit staan tot die werk gestoor is.

Vanuit 'n ander dop rig jy die gevriesde toestel eksplisiet aan sodat die terminaal waarin jy werk onaangeraak bly.

stty -F /dev/pts/7 -a
stty -F /dev/pts/7 sane

'n Leë skerm met 'n beskadigde vertoning is 'n aparte probleem van gebreekte lynbeheer, en die reset-program pak dit aan deur terminaal-inisialiseringsreekse uit te stuur. Probeer eers die toestandherstel, want dit verander instellings wat jy kan inspekteer, terwyl die reset-reeks die skerm herskryf en niks verduidelik oor hoe dit gebreek het nie.

Die Ctrl-S-put agter 'n oortuigende vriesing

Wanneer sagteware-vloeibeheer geaktiveer is en die gewone karakters toegewys is, sê Ctrl-S vir die terminaal om op te hou uitset stuur en sê Ctrl-Q vir dit om te hervat. Die sessie bly deurgaans lewendig, 'n enkele Ctrl-Q is dikwels die hele herstel, en niks verskyn in enige log nie, en dit is hoe hierdie een so baie eskalasies oorleef.

Inspekteer die werklike instellings in plaas daarvan om dit te aanvaar. Die begin- en stop-karakters kan hertoegewys of gedeaktiveer word, en 'n terminaal met vloeibeheer af sal op nie een van die twee reageer nie.

As die toestand terugkom, of SSH self vasval

'n Herhaalde slegte toestand dui op iets wat die vlae verander sonder om dit te herstel: 'n beginlêer, 'n omhulsel-skrip, 'n multiplekser wat die verkeerde venster herstel, of 'n toepassing wat sterf terwyl dit rou modus hou. Voeg 'n voorwaardelike kontrole by wat die toestand rapporteer in plaas van 'n onvoorwaardelike herstel, want 'n breë herstel verberg die oorsaak en kan doelbewuste instellings oorheers.

Wanneer gewone SSH-verkeer ook vasval, of die herstel niks verander nie, hou die terminaal op om die verdagte te wees.

ssh -vvv [email protected]
ping -M do -s 1400 -c 3 host.example.com

'n Vasval wat net tydens groot oordragte verskyn, dui op 'n pad-MTU-probleem, terwyl een wat ook enkele toetsaanslae insluk, op die pad of die bediener dui eerder as op pakketgrootte. Hou die terminaal-bewyse apart van die netwerk-bewyse, want 'n werkende redigeerder in 'n tweede sessie is nie bewys dat die eerste terminaal ooit gesond was nie.