vim zamarza przez SSH? Sprawdź stty, zanim obwinisz VPN

Takie sesje pozostają połączone, gdy edytor się uruchamia, a potem ekran przestaje się odświeżać, choć proces SSH jest wyraźnie żywy. Pisanie nic nie daje, Ctrl-C wygląda, jakby nic nie robił, a oczywisty wniosek jest taki, że VPN coś zgubił. Najczęściej tunel jest w porządku, a zdalny pseudoterminal jest w stanie, którego nikt nie zamierzył, bo echo, tryb kanoniczny i sterowanie przepływem żyją w terminalu, a nie w sieci. Ustalenie, który z tych trzech się przesunął, to zadanie dwóch poleceń.

Zamrożenie żyje w terminalu, nie w tunelu

Pseudoterminal niesie więcej niż bajty. Trzyma flagi dyscypliny wiersza, które decydują, czy wejście jest odbijane, czy odczyty czekają na nowy wiersz, czy pewne znaki generują sygnały i czy wyjście można zatrzymać znakiem sterującym. Edytor interaktywny przełącza ten terminal na czas działania w tryb surowy i powinien przy wyjściu przywrócić poprzednie ustawienia. Gdy przywrócenie nie następuje, powłoka, do której wracasz, nie jest powłoką, którą opuściłeś, nawet jeśli połączenie nigdy się nie zerwało.

Porównaj terminale, zanim cokolwiek stwierdzisz. Druga sesja z tym samym edytorem dowodzi, że klient i trasa potrafią wykonać pracę; nie mówi nic o terminalu, którego flagi są zepsute.

Odczytaj ustawienia na terminalu, który zamarzł

Najpierw zidentyfikuj urządzenie, potem odczytaj obie postacie jego stanu. Postać czytelna pokazuje, co jest ustawione, a postać maszynowa to ta, którą możesz później wczytać z powrotem.

tty
stty -a
stty -g

Trzy grupy flag wyjaśniają większość tych raportów. Ustawienia echa decydują, czy naciśnięcia klawiszy w ogóle się pojawiają, więc terminal z wyłączonym echem wygląda na martwy, podczas gdy powłoka odbiera każdy znak. Tryb kanoniczny decyduje, czy program widzi wejście wiersz po wierszu, więc terminal pozostawiony w trybie kanonicznym sprawia, że aplikacja w trybie surowym wydaje się ignorować klawisze do Enter. Ustawienia sterowania przepływem decydują, czy terminal słucha znaków XON i XOFF, i ta grupa daje najbardziej przekonujące fałszywe zamrożenie z trzech.

Zapisz wyjście, zanim cokolwiek zmienisz, zwłaszcza gdy sesja niesie własne przypisania klawiszy, na których ktoś polega. Postać maszynowa jest najbezpieczniejszym zapisem, z zastrzeżeniem, że zależy od implementacji i powinna być przywrócona przez ten sam rodzaj systemu, który ją utworzył.

Napraw ten jeden terminal, a nie sesję, w której piszesz

Standardowa naprawa przywraca zdrowy profil wymieniony na stronie podręcznika i dotyczy tylko jednego terminala. Jeśli edytor nadal trzyma niezapisane pliki w tym terminalu, zostaw go w spokoju, aż praca zostanie zapisana.

Z innej powłoki wskaż wyraźnie zamrożone urządzenie, aby terminal, w którym pracujesz, pozostał nietknięty.

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

Pusty ekran z uszkodzonym wyświetlaniem to inny problem niż zepsuta dyscyplina wiersza, a program reset radzi sobie z nim, wysyłając sekwencje inicjalizacji terminala. Najpierw wypróbuj naprawę stanu, bo zmienia ustawienia, które możesz sprawdzić, podczas gdy sekwencja reset przepisuje ekran i nic nie wyjaśnia, jak się zepsuł.

Pułapka Ctrl-S za przekonującym zamrożeniem

Gdy programowe sterowanie przepływem jest włączone, a zwykłe znaki przypisane, Ctrl-S mówi terminalowi, aby przestał wysyłać wyjście, a Ctrl-Q mówi mu, aby kontynuował. Sesja pozostaje żywa przez cały czas, jedno Ctrl-Q często wystarcza za całą naprawę, a w żadnym logu nic się nie pojawia, i tak to zamrożenie przeżywa tyle eskalacji.

Sprawdź rzeczywiste ustawienia, zamiast je zakładać. Znaki startu i zatrzymania można przypisać ponownie lub wyłączyć, a terminal z wyłączonym sterowaniem przepływem nie zareaguje na żaden z nich.

Jeśli stan wraca albo sam SSH się zacina

Powracający zły stan wskazuje na coś, co zmienia flagi bez ich przywracania: plik startowy, skrypt opakowujący, multiplekser resetujący niewłaściwe okno albo aplikację, która umiera, trzymając tryb surowy. Dodaj warunkowe sprawdzenie, które zgłasza stan, zamiast bezwarunkowego resetu, bo ogólny reset ukrywa przyczynę i może nadpisać celowe ustawienia.

Gdy zwykły ruch SSH też się zatyka albo naprawa nic nie zmienia, terminal przestaje być podejrzanym.

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

Zacięcie pojawiające się tylko przy dużych transferach sugeruje problem MTU na trasie, a takie, które połyka też pojedyncze naciśnięcia, wskazuje na trasę lub serwer, a nie na rozmiar pakietu. Trzymaj dowody z terminala osobno od dowodów z sieci, bo działający edytor w drugiej sesji nie jest dowodem, że pierwszy terminal był kiedykolwiek zdrowy.