vim ค้างผ่าน SSH? ตรวจสอบ stty ก่อนโทษ VPN

เซสชันแบบนี้ยังเชื่อมต่ออยู่ขณะเอดิเตอร์เริ่มทำงาน จากนั้นหน้าจอหยุดอัปเดตแม้โปรเซส SSH ยังมีชีวิตชัดเจน การพิมพ์ไม่เกิดอะไรขึ้น Ctrl-C ดูเหมือนไม่ทำอะไร และข้อสรุปที่ชัดเจนคือ VPN ทำอะไรบางอย่างหลุด ส่วนใหญ่ทันเนลปกติดีและเทอร์มินัลเทียมระยะไกลอยู่ในสถานะที่ไม่มีใครตั้งใจ เพราะ echo อินพุตแบบแคนอนิคัลและการควบคุมการไหลอาศัยอยู่ในเทอร์มินัล ไม่ใช่ในเครือข่าย การหาว่าหนึ่งในสามตัวนั้นขยับไปคืองานสองคำสั่ง

การค้างอยู่ในเทอร์มินัล ไม่ใช่ในทันเนล

เทอร์มินัลเทียมบรรทุกมากกว่าไบต์ มันเก็บแฟล็กวินัยของบรรทัดที่ตัดสินว่าอินพุตถูกสะท้อนหรือไม่ การอ่านรอขึ้นบรรทัดใหม่หรือไม่ อักขระบางตัวสร้างสัญญาณหรือไม่ และเอาต์พุตหยุดได้ด้วยอักขระควบคุมหรือไม่ เอดิเตอร์แบบอินเทอร์แอกทีฟสลับเทอร์มินัลนั้นเป็นโหมดดิบตลอดช่วงเวลา และควรคืนค่าที่ตั้งไว้ก่อนหน้าตอนออก เมื่อการคืนค่าไม่เกิดขึ้น เชลล์ที่คุณกลับมาคือไม่ใช่เชลล์ที่คุณจากไป แม้การเชื่อมต่อจะไม่ขาดเลยก็ตาม

เปรียบเทียบเทอร์มินัลก่อนสรุปอะไร เซสชันที่สองที่รันเอดิเตอร์เดียวกันพิสูจน์ว่าไคลเอนต์และเส้นทางทำงานได้ แต่ไม่บอกอะไรเกี่ยวกับเทอร์มินัลที่แฟล็กเสีย

อ่านค่าที่ตั้งบนเทอร์มินัลที่ค้าง

ระบุอุปกรณ์ก่อน แล้วอ่านสถานะทั้งสองรูปแบบ รูปแบบที่อ่านได้แสดงว่าอะไรถูกตั้งไว้ และรูปแบบเครื่องคือสิ่งที่คุณป้อนกลับได้ภายหลัง

tty
stty -a
stty -g

สามกลุ่มแฟล็กอธิบายรายงานเหล่านี้ส่วนใหญ่ การตั้งค่า echo ตัดสินว่าการกดคีย์ปรากฏหรือไม่ เทอร์มินัลที่ปิด echo จึงดูเหมือนตายขณะเชลล์รับทุกอักขระ โหมดแคนอนิคัลตัดสินว่าโปรแกรมเห็นอินพุตทีละบรรทัดหรือไม่ เทอร์มินัลที่ถูกทิ้งไว้ในโหมดแคนอนิคัลจึงทำให้แอปโหมดดิบดูเหมือนเพิกเฉยต่อคีย์จนถึง Enter การตั้งค่าควบคุมการไหลตัดสินว่าเทอร์มินัลเชื่อฟังอักขระ XON และ XOFF หรือไม่ และกลุ่มนั้นสร้างการค้างปลอมที่น่าเชื่อที่สุดในสามอย่าง

บันทึกเอาต์พุตก่อนเปลี่ยนอะไร โดยเฉพาะเมื่อเซสชันมีคีย์ผูกแบบกำหนดเองที่ใครบางคนพึ่งพา รูปแบบเครื่องเป็นบันทึกที่ปลอดภัยที่สุด โดยมีข้อแม้ว่าขึ้นกับการใช้งานและควรถูกคืนค่าโดยระบบชนิดเดียวกับที่สร้างมัน

ซ่อมเทอร์มินัลตัวนั้น ไม่ใช่เซสชันที่คุณกำลังพิมพ์

การซ่อมมาตรฐานคืนโปรไฟล์ที่ดีต่อสุขภาพตามที่หน้าคู่มือระบุ และมีผลกับเทอร์มินัลเดียวเท่านั้น ถ้าเอดิเตอร์ยังถืองานที่ยังไม่บันทึกในเทอร์มินัลนั้น ปล่อยไว้จนกว่างานจะถูกบันทึก

จากเชลล์อื่น เล็งอุปกรณ์ที่ค้างอย่างชัดเจนเพื่อให้เทอร์มินัลที่คุณทำงานอยู่ไม่ถูกแตะต้อง

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

หน้าจอว่างที่มีการแสดงผลเสียเป็นปัญหาคนละอย่างจากการวินัยของบรรทัดที่เสีย และโปรแกรม reset จัดการโดยส่งลำดับการเริ่มต้นของเทอร์มินัล ลองซ่อมสถานะก่อน เพราะมันเปลี่ยนค่าที่คุณตรวจสอบได้ ขณะที่ลำดับ reset เขียนหน้าจอใหม่และไม่อธิบายว่ามันเสียอย่างไร

กับดัก Ctrl-S เบื้องหลังการค้างที่น่าเชื่อ

เมื่อเปิดการควบคุมการไหลด้วยซอฟต์แวร์และอักขระปกติถูกกำหนดไว้ Ctrl-S บอกเทอร์มินัลให้หยุดส่งเอาต์พุต และ Ctrl-Q บอกให้ดำเนินต่อ เซสชันยังมีชีวิตตลอดเวลา Ctrl-Q ครั้งเดียวมักเป็นการซ่อมทั้งหมด และไม่มีอะไรปรากฏในล็อกใด ๆ นี่คือวิธีที่การค้างนี้รอดจากการยกระดับมามากมาย

ตรวจสอบค่าจริงแทนการสันนิษฐาน อักขระเริ่มและหยุดสามารถกำหนดใหม่หรือปิดใช้งานได้ และเทอร์มินัลที่ปิดการควบคุมการไหลจะไม่ตอบสนองต่อทั้งสอง

ถ้าสถานะกลับมาหรือ SSH เองติดขัด

สถานะเสียที่เกิดซ้ำบ่งชี้ถึงสิ่งหนึ่งที่เปลี่ยนแฟล็กโดยไม่คืนค่า เช่น ไฟล์เริ่มต้น สคริปต์ห่อ มัลติเพล็กเซอร์ที่รีเซ็ตหน้าต่างผิด หรือแอปที่ตายขณะถือโหมดดิบ เพิ่มการตรวจสอบแบบมีเงื่อนไขที่รายงานสถานะแทนการรีเซ็ตแบบไม่มีเงื่อนไข เพราะการรีเซ็ตแบบเหมารวมซ่อนสาเหตุและอาจเขียนทับค่าที่ตั้งใจไว้

เมื่อทราฟิก SSH ปกติก็ติดขัด หรือการซ่อมไม่เปลี่ยนอะไร เทอร์มินัลก็ไม่ใช่ผู้ต้องสงสัยอีกต่อไป

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

การติดขัดที่เกิดเฉพาะระหว่างการถ่ายโอนขนาดใหญ่บ่งชี้ปัญหา MTU ตามเส้นทาง ส่วนที่กลืนการกดคีย์เดี่ยว ๆ ด้วยชี้ไปที่เส้นทางหรือเซิร์ฟเวอร์ ไม่ใช่ขนาดแพ็กเก็ต แยกหลักฐานของเทอร์มินัลออกจากหลักฐานของเครือข่าย เพราะเอดิเตอร์ที่ทำงานในเซสชันที่สองไม่ใช่หลักฐานว่าเทอร์มินัลแรกเคยปกติ