A vim lefagy SSH-n? Ellenőrizze az stty-t, mielőtt a VPN-t hibáztatja

Az ilyen munkamenetek kapcsolva maradnak, miközben a szerkesztő elindul, aztán a képernyő abbahagyja a frissítést, pedig az SSH-folyamat egyértelműen él. A gépelés semmit nem ad, a Ctrl-C úgy tűnik, semmit nem tesz, és a kézenfekvő következtetés az, hogy a VPN elejtett valamit. Legtöbbször az alagút rendben van, és a távoli pszeudoterminál olyan állapotban van, amit senki nem szándékozott, mert a visszhang, a kanonikus bevitel és a folyamvezérlés a terminálban él, nem a hálózatban. Kideríteni, melyik mozdult el a három közül, két parancs munkája.

A fagyás a terminálban él, nem az alagútban

A pszeudoterminál többet hordoz, mint bájtokat. Sorfegyelem-jelzőbiteket tart, amelyek eldöntik, hogy a bevitel visszhangzódik-e, hogy az olvasások új sorra várnak-e, hogy bizonyos karakterek jelet generálnak-e, és hogy a kimenet leállítható-e vezérlőkarakterrel. Az interaktív szerkesztő a teljes időtartamra nyers módba kapcsolja azt a terminált, és kilépéskor vissza kellene állítania az előző beállításokat. Amikor a visszaállítás nem történik meg, a héj, amelybe visszatér, nem az a héj, amelyet elhagyott, még ha a kapcsolat soha nem is szakadt meg.

Hasonlítsa össze a terminálokat, mielőtt bármit megállapítana. Egy második, ugyanazt a szerkesztőt futtató munkamenet bizonyítja, hogy a kliens és az útvonal képes a munkára; semmit nem mond arról a terminálról, amelynek jelzőbitjei töröttek.

Olvassa ki a beállításokat azon a terminálon, amely lefagyott

Először azonosítsa az eszközt, aztán olvassa ki állapotának mindkét formáját. Az olvasható forma megmutatja, mi van beállítva, a gépi forma pedig az, amelyet később visszaadhat.

tty
stty -a
stty -g

Három jelzőbit-csoport magyarázza e jelentések többségét. A visszhangbeállítások eldöntik, hogy a billentyűleütések egyáltalán megjelennek-e, így a kikapcsolt visszhangú terminál halottnak látszik, miközben a héj minden karaktert megkap. A kanonikus mód eldönti, hogy egy program soronként látja-e a bevitelt, így a kanonikus módban hagyott terminál miatt a nyers módú alkalmazás úgy tűnik, mintha az Enterig figyelmen kívül hagyná a billentyűket. A folyamvezérlési beállítások eldöntik, hogy a terminál engedelmeskedik-e az XON és XOFF karaktereknek, és ez a csoport állítja elő a három közül a leghitelesebb hamis fagyást.

Rögzítse a kimenetet, mielőtt bármit módosítana, különösen ha a munkamenet olyan egyéni billentyű-hozzárendeléseket hordoz, amelyektől valaki függ. A gépi forma a legbiztonságosabb feljegyzés, azzal a fenntartással, hogy megvalósításfüggő, és ugyanolyan rendszernek kell visszaállítania, amilyen létrehozta.

Azt az egy terminált javítsa, ne a munkamenetet, amelyben gépel

A szokásos javítás visszaállítja a kézikönyvoldalon felsorolt egészséges profilt, és csak egy terminált érint. Ha a szerkesztő még mentetlen munkát tart azon a terminálon, hagyja békén, amíg a munka mentésre nem kerül.

Egy másik héjból célozza meg kifejezetten a lefagyott eszközt, hogy a terminál, amelyben dolgozik, érintetlen maradjon.

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

A hibás megjelenítésű üres képernyő külön probléma a törött sorfegyelemtől, és a reset program terminál-inicializáló sorozatok kibocsátásával kezeli. Először próbálja az állapotjavítást, mert az olyan beállításokat módosít, amelyeket megvizsgálhat, míg a reset sorozat újraírja a képernyőt, és semmit nem magyaráz arról, hogyan tört el.

A Ctrl-S csapdája egy hiteles fagyás mögött

Ha a szoftveres folyamvezérlés engedélyezett és a szokásos karakterek hozzá vannak rendelve, a Ctrl-S azt mondja a terminálnak, hogy hagyja abba a kimenet küldését, a Ctrl-Q pedig hogy folytassa. A munkamenet végig életben marad, egyetlen Ctrl-Q gyakran az egész javítás, és semmi nem jelenik meg egyetlen naplóban sem, és így éli túl ez a fagyás a sok eszkalációt.

Vizsgálja meg a tényleges beállításokat, ahelyett hogy feltételezné őket. A kezdő és leállító karakterek újra hozzárendelhetők vagy letilthatók, és a kikapcsolt folyamvezérlésű terminál egyikre sem reagál.

Ha az állapot visszatér, vagy maga az SSH akad meg

Egy visszatérő rossz állapot valamire utal, ami visszaállítás nélkül módosítja a jelzőbiteket: egy indítófájl, egy burkoló szkript, egy rossz ablakot visszaállító multiplexer, vagy egy nyers módot tartva meghaló alkalmazás. Adjon hozzá feltételes ellenőrzést, amely jelenti az állapotot a feltétel nélküli visszaállítás helyett, mert az átfogó visszaállítás elrejti az okot, és felülírhat szándékos beállításokat.

Amikor a szokásos SSH-forgalom is megakad, vagy a javítás semmit nem változtat, a terminál megszűnik gyanúsnak lenni.

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

A csak nagy átvitelek alatt jelentkező akadás útvonal-MTU problémára utal, míg az, amely egyedi leütéseket is elnyel, az útvonalra vagy a kiszolgálóra mutat, nem a csomagméretre. Tartsa külön a terminál bizonyítékait a hálózati bizonyítékoktól, mert egy második munkamenetben működő szerkesztő nem bizonyítja, hogy az első terminál valaha egészséges volt.