มีวิธีการป้องกันการแช่แข็ง tmux เมื่อข้อความจำนวนมากถูกส่งออกไปยังสถานี?

38

ในเซสชั่น tmux ภายใน xterm เมื่อโปรแกรมสร้าง ouput จำนวนมาก (เช่นcat very_long_fileเซสชั่นทั้งหมดในการแช่แข็งในขณะที่แม้ว่าฉันกด Ctrl-C ไม่มีอะไรถูกขัดจังหวะน่าจะเป็นเพราะ tmux ถูกแช่แข็งและจะไม่ส่งต่อ Ctrl-C ไป โปรแกรมสร้างเอาต์พุตมีวิธีใดในการป้องกันสิ่งนี้

tmux

— ecerulm
แหล่งที่มา

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

— chepner

1

บานหน้าต่างแยก tmux ในแนวนอน (เช่น Cb%) มีความไวต่อปัญหานี้มากกว่าบานหน้าต่างเต็มหรือบานหน้าต่างแยกตามแนวตั้ง นอกจากนี้การเรียกใช้ Cb d และการติดตั้งซ้ำจะ "ยกเลิกการตรึง" โปรแกรมแม้ว่าจะเป็นการชั่วคราวเท่านั้น ไม่มีวิธีแก้ปัญหาจริงๆเว้นแต่คุณจะยินดีที่จะขุดลงในการกำหนดค่า tmux

— RussellStewart

15

ทางออกที่ถูกต้องคือดูที่ตัวเลือก c0- * เพื่อ tmux เพื่อลองและ จำกัด อัตราเอาต์พุต เหตุผลที่ปัญหานี้เกิดขึ้นเนื่องจากข้อมูลที่ส่งไปยังเทอร์มินัลเร็วกว่าที่สามารถแสดงได้ดังนั้นการ จำกัด อัตราเป็นวิธีเดียว

— ThomasAdam
แหล่งที่มา

c0-change-trigger และ c0-change-interval ดูเหมือนจะแก้ปัญหาได้ การตั้งค่าเริ่มต้นนั้นเพียงพอสำหรับฉัน

— ecerulm

setw -g c0-change-interval 100และsetw -g c0-change-trigger 250ไม่สร้างความแตกต่างให้ฉัน ฉันใช้ tmux-1.8 ฉันทำอะไรผิดหรือเปล่า?

— solotim

@solotim ธิการใน 1.9a tmux ฉัน แต่ฉันเพิ่มเข้าไปในของฉันset-window-option -g ... .tmux.conf

— polym

5

เห็นได้ชัดว่าสิ่งเหล่านี้ถูกลบใน tmux 2.2 :(

— Martin C. Martin

20

ฉันยังคงมีปัญหานี้ใน tmux 1.6-2 บน Ubuntu 12.10 วิธีแก้ปัญหาหนึ่งที่ฉันพบคือการแยกออกจากเซสชัน (คำนำหน้า + d) จากนั้นใส่กลับเข้าไปใหม่ ( tmux attachซึ่งเป็นตัวเลือกที่ดีสำหรับนามแฝงเชลล์ด่วน) ดูเหมือนว่า tmux ตอบสนองได้จริงภายใต้ประทุน - คุณสามารถยืนยันได้ว่ากระบวนการของคุณถูกฆ่าทันทีด้วย ctrl-c --- เป็นเพียงแค่รูปวาดที่กำลังบล็อก การปลดจะทำงานได้ทันทีและเมื่อคุณใส่กลับเข้าไปภาพวาดนั้นจะถูกข้ามไปจนสุด

— แจ็คโอคอนเนอร์
แหล่งที่มา

วิธีแก้ปัญหาที่ดี ดูเหมือนว่าในความเป็นจริงทุกอย่างทำงานได้แม้การสลับระหว่างการแยกมันก็ไม่ได้ดึง

— jmiserez

1

นี่ควรจะเป็นอย่างtmux attachนั้นใช่ไหม

— pandubear

โอ๊ะคุณพูดถูก คงที่

— Jack O'Connor

2

tmux attachและถ้าคุณไม่สามารถถอดออกเช่นไม่แน่ใจว่าของแมโครเพียงแค่เปิดสถานีหน้าต่างใหม่และ

— mahemoff

5

เท่าที่ฉันรู้ว่ามันไม่มีทางที่จะป้องกันมันในรุ่นปัจจุบันได้ แต่งานบางอย่างกำลังดำเนินอยู่ คุณสามารถค้นหาแพทช์บางอย่างเกี่ยวกับรายชื่อผู้รับจดหมาย tmux ของhttp://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689

คำหลักที่ดีในการค้นหาเว็บคือ "การควบคุมการไหล"

— piec
แหล่งที่มา

2

เหตุใดแพตช์จึงไม่ผ่านการตรวจสอบในสาขาหลัก ปัญหานี้เป็นสาเหตุที่สำคัญที่สุดที่ฉันยังคงใช้ gnu_screen

— solotim

5

น่าเสียดายที่ตัวเลือก c0- * สำหรับการ จำกัด อัตราถูกลบออกจาก tmux เวอร์ชัน 2.1 ( changelog ) เท่าที่ฉันรู้วิธีเดียวที่จะกำหนดอัตรา จำกัด เองคือการอัปเดตตัวแปรที่มีอิทธิพลต่อรหัสต้นทาง (tmux.h):

" READ_SIZE คือขนาดข้อมูลสูงสุดที่จะเก็บจาก pty (ลายน้ำที่มีค่าสูงของเหตุการณ์) READ_BACKOFF คือปริมาณข้อมูลที่รอการส่งออกไปยัง tty ก่อนที่ pty การอ่านจะถูกสำรองก่อน READ_TIME คือระยะเวลาที่จะถอยกลับก่อน อ่านครั้งถัดไป (เป็นไมโครวินาที) หาก tty อยู่เหนือ READ_BACKOFF "

ที่ซึ่งคุณจะพบค่าเริ่มต้น: (จาก tmux v2.2):

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100

— gospes
แหล่งที่มา

1

ใน tmux v2.3 ตัวแปรที่ระบุไม่มีอยู่

— bergercookie

4

คำตอบhttps://superuser.com/a/589896/311481 ใช้งานได้ดี ฉันใช้ค่าต่อไปนี้:

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

เคล็ดลับอื่น: ถ้าคุณใช้ ssh ภายใน tmux ให้ใช้ mosh แทน: http://mosh.mit.edu/มันจะทำงานได้อย่างชาญฉลาดขึ้นเพื่อแสดงผลลัพธ์ของโปรแกรม มันพยายามที่จะแสดงสถานะหน้าจอสุดท้ายที่ลดลงตัวกลางเมื่อเหมาะสม ดังนั้น tmux จะไม่หยุดถ้าเอาต์พุตจำนวนมากถูกสร้างขึ้นภายในบานหน้าต่างด้วยเซสชัน mosh ภายใน

ซึ่งแตกต่างจาก SSH โปรโตคอล UDP ของ mosh จะจัดการกับการสูญหายของแพ็กเก็ตได้อย่างสวยงามและตั้งค่าอัตราเฟรมตามเงื่อนไขเครือข่าย Mosh ไม่ได้เติมบัฟเฟอร์ของเครือข่ายดังนั้น Control-C จะทำงานเพื่อหยุดกระบวนการหลบหนี

เนื่องจาก SSP [สถานะการซิงโครไนซ์โพรโทคอลที่ mosh ใช้] ทำงานที่ชั้นวัตถุและสามารถควบคุมอัตราการซิงโครไนซ์ (กล่าวอีกนัยหนึ่งคืออัตราเฟรม) จึงไม่จำเป็นต้องส่งทุกไบต์ที่ได้รับจากแอปพลิเคชัน นั่นหมายความว่า Mosh สามารถควบคุมเฟรมเพื่อที่จะไม่เติมบัฟเฟอร์เครือข่ายรักษาการตอบสนองของการเชื่อมต่อและทำให้แน่ใจว่า Control-C ทำงานได้อย่างรวดเร็วเสมอ โปรโตคอลที่ต้องส่งทุกไบต์ไม่สามารถทำได้

— user2683246
แหล่งที่มา

0

ลองจำลองเทอร์มินัลที่แตกต่างกัน บน RedHat 6.5 konsole (KDE) ไม่มีปัญหาการเยือกแข็ง (tmux 2.3 และ master); อย่างไรก็ตาม xterm และ gnome-terminal ทั้งคู่พบว่าการแช่แข็งไม่ดี

— Kko
แหล่งที่มา

tmux 2.2 ทำงานได้ดีโดยไม่มีปัญหาจุดเยือกแข็งในตัวจำลองเทอร์มินัลทั้งสามตัว

— kko