vim bị treo qua SSH? Kiểm tra stty trước khi đổ lỗi cho VPN

Những phiên như thế này vẫn kết nối khi trình soạn thảo khởi động, rồi màn hình ngừng cập nhật dù tiến trình SSH rõ ràng vẫn sống. Gõ không ra gì, Ctrl-C có vẻ không làm gì, và kết luận hiển nhiên là VPN đã đánh rơi thứ gì đó. Phần lớn thời gian đường hầm vẫn tốt và pseudo-terminal từ xa đang ở trạng thái không ai định trước, vì echo, đầu vào chuẩn tắc và điều khiển luồng sống trong terminal chứ không phải trong mạng. Tìm ra cái nào trong ba thứ đó đã dịch chuyển là việc của hai lệnh.

Sự treo nằm trong terminal, không phải trong đường hầm

Một pseudo-terminal mang nhiều thứ hơn byte. Nó giữ các cờ kỷ luật dòng quyết định liệu đầu vào có được echo, liệu các lần đọc có chờ dòng mới, liệu một số ký tự có tạo tín hiệu, và liệu đầu ra có thể bị dừng bởi ký tự điều khiển. Trình soạn thảo tương tác chuyển terminal đó sang chế độ thô trong suốt thời gian và được cho là sẽ khôi phục cài đặt trước đó khi thoát. Khi việc khôi phục không xảy ra, shell bạn quay về không phải shell bạn đã rời, dù kết nối chưa bao giờ bị ngắt.

So sánh các terminal trước khi kết luận bất cứ điều gì. Một phiên thứ hai chạy cùng trình soạn thảo chứng minh rằng client và đường đi có thể làm việc đó; nó không nói gì về terminal có cờ bị hỏng.

Đọc cài đặt trên terminal đã treo

Xác định thiết bị trước, rồi đọc cả hai dạng trạng thái của nó. Dạng đọc được cho biết điều gì đã đặt, và dạng máy là dạng bạn có thể nạp lại sau này.

tty
stty -a
stty -g

Ba nhóm cờ giải thích phần lớn các báo cáo này. Cài đặt echo quyết định liệu các lần nhấn phím có hiện ra hay không, nên terminal tắt echo trông như chết trong khi shell nhận từng ký tự. Chế độ chuẩn tắc quyết định liệu chương trình có thấy đầu vào từng dòng một, nên terminal bị để ở chế độ chuẩn tắc khiến ứng dụng ở chế độ thô có vẻ như bỏ qua các phím cho đến Enter. Cài đặt điều khiển luồng quyết định liệu terminal có tuân theo các ký tự XON và XOFF, và nhóm đó tạo ra sự treo giả thuyết phục nhất trong ba.

Ghi lại đầu ra trước khi thay đổi bất cứ điều gì, đặc biệt khi phiên mang các liên kết phím tùy chỉnh mà ai đó dựa vào. Dạng máy là bản ghi an toàn nhất, với lưu ý rằng nó phụ thuộc vào cách triển khai và nên được khôi phục bởi cùng loại hệ thống đã tạo ra nó.

Sửa chính terminal đó, không phải phiên bạn đang gõ

Bản sửa chuẩn khôi phục hồ sơ lành mạnh mà trang hướng dẫn liệt kê, và nó chỉ ảnh hưởng đến một terminal. Nếu trình soạn thảo vẫn giữ công việc chưa lưu trong terminal đó, hãy để yên cho đến khi công việc được lưu.

Từ một shell khác, nhắm rõ ràng vào thiết bị đã treo để terminal bạn đang làm việc vẫn nguyên vẹn.

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

Màn hình trống với hiển thị hỏng là vấn đề khác với kỷ luật dòng bị hỏng, và chương trình reset xử lý bằng cách phát ra các chuỗi khởi tạo terminal. Hãy thử sửa trạng thái trước, vì nó thay đổi cài đặt bạn có thể kiểm tra, trong khi chuỗi reset viết lại màn hình và không giải thích gì về cách nó hỏng.

Bẫy Ctrl-S đằng sau một sự treo thuyết phục

Khi điều khiển luồng phần mềm được bật và các ký tự thông thường được gán, Ctrl-S bảo terminal ngừng gửi đầu ra và Ctrl-Q bảo nó tiếp tục. Phiên vẫn sống suốt thời gian, một Ctrl-Q thường là toàn bộ bản sửa, và không có gì xuất hiện trong bất kỳ nhật ký nào, và đó là cách sự treo này sống sót qua bao nhiêu lần leo thang.

Kiểm tra cài đặt thực tế thay vì giả định. Các ký tự bắt đầu và dừng có thể được gán lại hoặc vô hiệu hóa, và terminal tắt điều khiển luồng sẽ không phản ứng với cả hai.

Nếu trạng thái quay lại, hoặc chính SSH bị kẹt

Trạng thái xấu lặp lại chỉ ra một thứ gì đó thay đổi cờ mà không khôi phục chúng: tệp khởi động, script bọc, bộ ghép kênh đặt lại nhầm cửa sổ, hoặc ứng dụng chết trong khi giữ chế độ thô. Thêm kiểm tra có điều kiện báo cáo trạng thái thay vì đặt lại vô điều kiện, vì đặt lại toàn bộ che giấu nguyên nhân và có thể ghi đè cài đặt có chủ đích.

Khi lưu lượng SSH bình thường cũng kẹt, hoặc bản sửa không thay đổi gì, terminal không còn là nghi phạm nữa.

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

Một sự kẹt chỉ xuất hiện khi truyền lớn gợi ý vấn đề MTU trên đường đi, còn cái nuốt cả những lần nhấn phím đơn lẻ chỉ vào đường đi hoặc máy chủ chứ không phải kích thước gói. Giữ bằng chứng terminal tách khỏi bằng chứng mạng, vì một trình soạn thảo hoạt động trong phiên thứ hai không phải bằng chứng rằng terminal đầu tiên từng khỏe mạnh.