Nagyeyelo ang vim sa SSH? Suriin ang stty bago sisihin ang VPN

Ang mga sesyong tulad nito ay nananatiling konektado habang nagsisimula ang editor, pagkatapos ay humihinto ang pag-update ng screen kahit malinaw na buhay ang proseso ng SSH. Walang lumalabas sa pag-type, tila walang ginagawa ang Ctrl-C, at ang halatang konklusyon ay may nalaglag ang VPN. Kadalasan maayos ang tunnel at ang remote na pseudo-terminal ay nasa estadong walang sinuman ang nagplano, dahil ang echo, canonical na input at kontrol ng daloy ay naninirahan sa terminal at hindi sa network. Ang malaman kung alin sa tatlo ang gumalaw ay trabahong dalawang utos.

Ang pagyelo ay naninirahan sa terminal, hindi sa tunnel

Ang pseudo-terminal ay nagdadala ng higit pa sa bytes. Hinahawakan nito ang mga flag ng disiplina ng linya na nagpapasya kung ang input ay ine-echo, kung ang pagbasa ay naghihintay ng bagong linya, kung ang ilang karakter ay gumagawa ng signal, at kung ang output ay maaaring ihinto ng control character. Inilalagay ng interactive na editor ang terminal na iyon sa raw mode sa buong tagal at inaasahang ibalik ang dating setting sa paglabas. Kapag hindi nangyari ang pagbalik, ang shell na binabalikan mo ay hindi ang shell na iniwan mo, kahit hindi kailanman naputol ang koneksyon.

Ihambing ang mga terminal bago maghinuha ng anuman. Ang pangalawang sesyong nagpapatakbo ng parehong editor ay nagpapatunay na kaya ng client at ng landas ang trabaho; wala itong sinasabi tungkol sa terminal na sira ang mga flag.

Basahin ang mga setting sa terminal na nagyelo

Kilalanin muna ang aparato, pagkatapos ay basahin ang dalawang anyo ng kalagayan nito. Ang nababasang anyo ay nagpapakita ng nakatakda, at ang machine form ang maaari mong ibalik mamaya.

tty
stty -a
stty -g

Tatlong grupo ng flag ang nagpapaliwanag sa karamihan ng ulat na ito. Ang mga setting ng echo ay nagpapasya kung ang mga pagpindot ay lumalabas man, kaya ang terminal na patay ang echo ay mukhang patay habang tinatanggap ng shell ang bawat karakter. Ang canonical mode ay nagpapasya kung ang programa ay nakakakita ng input nang isang linya sa isang pagkakataon, kaya ang terminal na naiwan sa canonical mode ay nagpapamukha na binabalewala ng application sa raw mode ang mga key hanggang Enter. Ang mga setting ng kontrol ng daloy ay nagpapasya kung sinusunod ng terminal ang mga karakter na XON at XOFF, at ang grupong iyon ang gumagawa ng pinakamakumbinsing pekeng pagyelo sa tatlo.

Itala ang output bago baguhin ang anuman, lalo na kapag may custom na key binding ang sesyon na pinagkakatiwalaan ng isang tao. Ang machine form ang pinakaligtas na tala, may paalala na nakadepende ito sa implementasyon at dapat ibalik ng parehong uri ng system na gumawa nito.

Ayusin ang terminal na iyon, hindi ang sesyong tinatype mo

Ibinabalik ng karaniwang pagkukumpuni ang malusog na profile na nakalista sa pahina ng manwal, at isang terminal lamang ang apektado. Kung may hawak pa ang editor ng hindi na-save na trabaho sa terminal na iyon, hayaan ito hanggang ma-save ang trabaho.

Mula sa ibang shell, direktang i-target ang nagyelong aparato upang manatiling hindi nagalaw ang terminal na pinagtatrabahuhan mo.

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

Ang blangkong screen na may sirang display ay hiwalay na problema sa sirang disiplina ng linya, at hinaharap ito ng programang reset sa pamamagitan ng paglalabas ng mga terminal initialization sequence. Subukan muna ang pagkukumpuni ng estado, dahil binabago nito ang mga setting na maaari mong siyasatin, samantalang ang reset sequence ay nagsusulat muli ng screen at walang ipinaliwanag kung paano ito nasira.

Ang bitag ng Ctrl-S sa likod ng nakakumbinsing pagyelo

Kapag naka-enable ang software flow control at nakatalaga ang mga karaniwang karakter, sinasabi ng Ctrl-S sa terminal na itigil ang pagpapadala ng output at sinasabi ng Ctrl-Q na magpatuloy. Nananatiling buhay ang sesyon sa buong panahon, isang Ctrl-Q lang ang madalas na buong pagkukumpuni, at walang lumalabas sa anumang log, at ganoon na lamang nakakaligtas ang pagyelong ito sa napakaraming pag-escalate.

Siyasatin ang tunay na mga setting sa halip na ipagpalagay. Maaaring muling italaga o i-disable ang mga karakter ng simula at hinto, at ang terminal na patay ang kontrol ng daloy ay hindi tutugon sa alinman sa dalawa.

Kung bumalik ang estado, o mismo ang SSH ay natigil

Ang paulit-ulit na masamang estado ay tumutukoy sa isang bagay na nagbabago ng mga flag nang hindi ibinabalik ang mga ito: startup file, wrapper script, multiplexer na nagre-reset ng maling window, o application na namamatay habang hawak ang raw mode. Magdagdag ng kondisyonal na pagsusuri na nag-uulat ng estado sa halip na walang kondisyong pag-reset, dahil ang pangkalahatang pag-reset ay nagtatago ng dahilan at maaaring magpawalang-bisa ng sinadyang setting.

Kapag natigil din ang ordinaryong trapiko ng SSH, o walang binabago ang pagkukumpuni, hindi na suspect ang terminal.

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

Ang paghinto na lumalabas lamang sa malalaking paglilipat ay nagmumungkahi ng problema sa MTU sa landas, samantalang ang isa na lumulunok din ng indibidwal na pagpindot ay tumutukoy sa landas o server at hindi sa laki ng packet. Panatilihing hiwalay ang ebidensya ng terminal sa ebidensya ng network, dahil ang editor na gumagana sa pangalawang sesyon ay hindi patunay na ang unang terminal ay malusog kailanman.