การอภิปรายล่าสุดเกี่ยวกับการใช้ systemd-inhibit เพื่อป้องกันระบบ Linux เข้าสู่โหมดสลีประหว่างเซสชัน SSH ระยะไกลได้จุดประกายการถกเถียงในหมู่ผู้ใช้เกี่ยวกับแนวทางที่ดีที่สุดในการจัดการพลังงานบนระบบเดสก์ท็อปที่ใช้สำหรับงานพัฒนา
การสนทนานี้มีจุดศูนย์กลางอยู่ที่ปัญหาทั่วไปที่นักพัฒนาซอฟต์แวร์ที่ใช้คอมพิวเตอร์เดสก์ท็อปจากระยะไกลต้องเผชิญ เมื่อทำงานผ่านการเชื่อมต่อ SSH การตั้งค่าสลีปอัตโนมัติของระบบสามารถขัดจังหวะเซสชัน ทำให้ผู้ใช้ต้องปลุกเครื่องและเชื่อมต่อใหม่ ในขณะที่วิธีแก้ปัญหาหนึ่งเกี่ยวข้องกับการใช้ systemd-inhibit กับกระบวนการพื้นหลัง สมาชิกชุมชนได้แสดงความกังวลเกี่ยวกับแนวทางนี้และเสนอทางเลือกอื่น
การแก้ปัญหาชั่วคราว เทียบกับ วิธีแก้ปัญหาที่เหมาะสม
ผู้ใช้หลายคนชี้ให้เห็นว่าการแก้ปัญหาด้วย systemd-inhibit เป็นเพียงการแก้ไขชั่วคราว แทนที่จะแก้ไขสาเหตุหลัก ปัญหาที่แท้จริงอยู่ที่ตรรกะที่ไม่สมบูรณ์ของ systemd-logind ในการจัดการเซสชัน SSH แม้ว่า systemd จะติดตามเซสชัน SSH ผ่านฐานข้อมูลการเข้าสู่ระบบแล้ว แต่มันไม่ได้พิจารณาเซสชันระยะไกลที่ใช้งานอยู่อย่างเหมาะสมเมื่อตัดสินใจเรื่องการระงับระบบ ซึ่งหมายความว่าระบบจะปฏิบัติต่อเซสชัน SSH ที่ใช้งานอยู่เหมือนกับเดสก์ท็อปที่ไม่มีการใช้งาน ส่งผลให้เกิดการระงับระบบที่ไม่พึงประสงค์
หมายเหตุ: systemd-logind คือบริการระบบที่จัดการการเข้าสู่ระบบของผู้ใช้และการตัดสินใจเรื่องการจัดการพลังงาน
ส่วนประกอบทางเทคนิคที่เกี่ยวข้อง:
- systemd-logind: จัดการเซสชันผู้ใช้และการตัดสินใจเรื่องพลังงาน
- pam_systemd.so: โมดูล PAM สำหรับติดตามเซสชัน
- systemd-inhibit: เครื่องมือสำหรับบล็อกการดำเนินการจัดการพลังงาน
- การติดตามเซสชัน SSH: อยู่ใน
/run/systemd/users/,/run/systemd/sessions/ - Power Management Assertions: API พื้นฐาน (คล้ายกับ caffeinate ใน macOS)
แนวทางทางเลือกได้รับการสนับสนุน
สมาชิกชุมชนเสนอวิธีแก้ปัญหาที่สะอาดกว่าหลายแนวทาง ทางเลือกยอดนิยมหนึ่งเกี่ยวข้องกับการกำหนดค่าแล็ปท็อปให้ไม่เข้าสู่โหมดระงับเมื่อเชื่อมต่อกับแหล่งจ่ายไฟ ซึ่งช่วยขจัดความจำเป็นในการแทรกแซงด้วยตนเองระหว่างงานที่ใช้เวลานาน เช่น การคอมไพล์หรือการทดสอบ คนอื่นๆ แนะนำให้ใช้ autossh ซึ่งจะเชื่อมต่อเซสชัน SSH ใหม่โดยอัตโนมัติหลังจากการขัดจังหวะเครือข่ายหรือเหตุการณ์การปลุกระบบ
ผมแค่ใช้ autossh จาก CLI และมันจะเชื่อมต่อใหม่หากแล็ปท็อปของผม (หรือเครื่องระยะไกล) ตื่นขึ้นมาอีกครั้ง
ผู้ใช้บางคนสนับสนุนการปิดใช้งานฟีเจอร์สลีปอัตโนมัติทั้งหมด โดยเลือกการจัดการพลังงานด้วยตนเอง แนวทางนี้ปฏิบัติต่อคอมพิวเตอร์ว่าเป็นแบบใช้งานเต็มที่หรือปิดเครื่องสมบูรณ์ หลีกเลี่ยงความซับซ้อนในการจัดการสถานะพลังงานที่แตกต่างกัน
วิธีแก้ปัญหาทางเลือกที่มีการหารือ:
- autossh: เชื่อมต่อเซสชัน SSH ใหม่โดยอัตโนมัติหลังจากการขัดจังหวะ
- การเปลี่ยนแปลงนโยบายพลังงาน: กำหนดค่าไม่ให้หยุดทำงานเมื่อเสียบสายไฟ AC
- systemd user service: แปลงคำสั่ง inhibit ให้เป็นเซอร์วิสที่เหมาะสม
- ปิดการใช้งานโหมดสลีปทั้งหมด: จัดการพลังงานด้วยตนเองเท่านั้น
- D-Bus API: เรียกใช้ระบบโดยตรงแทนการใช้เครื่องมือบรรทัดคำสั่ง
การปรับปรุงทางเทคนิคและวิธีแก้ปัญหาชั่วคราว
การอภิปรายเผยให้เห็นการปรับปรุงทางเทคนิคหลายประการสำหรับแนวทางเดิม ผู้ใช้แนะนำให้แปลงคำสั่ง systemd-inhibit ให้เป็นบริการผู้ใช้ systemd ที่เหมาะสม ซึ่งจะช่วยขจัดความจำเป็นในการติดตาม process ID ด้วยตนเอง วิธีนี้จะช่วยให้สามารถใช้คำสั่งเริ่มและหยุดง่ายๆ ผ่าน systemctl แทนที่จะจัดการกระบวนการพื้นหลัง
ข้อเสนอแนะอื่นเกี่ยวข้องกับการเขียนโปรแกรมเฉพาะที่เรียก D-Bus API โดยตรง หลีกเลี่ยงความซับซ้อนของกระบวนการที่ซ้อนกัน แนวทางนี้จะให้การจัดการทรัพยากรที่สะอาดกว่าและการทำงานที่เชื่อถือได้มากขึ้น
หมายเหตุ: D-Bus คือระบบสำหรับการสื่อสารระหว่างกระบวนการที่ใช้โดยสภาพแวดล้อมเดสก์ท็อป Linux หลายตัว
โครงสร้างคำสั่ง systemd-inhibit:
--no-ask-password: ข้ามการแจ้งให้ยืนยันตัวตน--what=idle: ระบุสิ่งที่ต้องการยับยั้ง (idle, sleep, shutdown)--who="username": ระบุผู้ใช้หรือแอปพลิเคชัน--why="reason": ให้คำอธิบายสำหรับการยับยั้ง- การรันคำสั่ง:
sh & disownสร้างกระบวนการทำงานในเบื้องหลัง
ความท้าทายในการจัดการพลังงานในวงกว้าง
การถกเถียงนี้เน้นย้ำถึงความตึงเครียดที่ดำเนินอยู่ในการจัดการพลังงาน Linux ระหว่างกรณีการใช้งานที่แตกต่างกัน ในขณะที่การสลีปอัตโนมัติทำงานได้ดีสำหรับการใช้งานแล็ปท็อปทั่วไป แต่มันสร้างปัญหาสำหรับผู้ใช้ที่ต้องการให้ระบบของตนพร้อมใช้งานสำหรับการเข้าถึงจากระยะไกล การอภิปรายชี้ให้เห็นว่าการรวมที่ดีขึ้นระหว่างบริการ SSH และการจัดการพลังงานของ systemd สามารถแก้ปัญหาเหล่านี้ได้โดยไม่ต้องใช้วิธีแก้ปัญหาชั่วคราวจากผู้ใช้
ผู้เข้าร่วมบางคนสังเกตว่าปัญหานี้สะท้อนถึงความแตกต่างทางปรัชญาในวงกว้างระหว่างแนวทาง Unix แบบดั้งเดิมและระบบที่ใช้ systemd สมัยใหม่ ความท้าทายอยู่ที่การสร้างสมดุลระหว่างการจัดการพลังงานอัตโนมัติกับความยืดหยุ่นที่จำเป็นสำหรับรูปแบบการใช้งานที่หลากหลาย
การอภิปรายของชุมชนแสดงให้เห็นว่าแม้จะมีวิธีแก้ปัญหาทางเทคนิคอยู่ แต่ปัญหาพื้นฐานต้องการการประสานงานที่ดีขึ้นระหว่างบริการ SSH และระบบจัดการพลังงานเพื่อให้การเข้าถึงจากระยะไกลที่ราบรื่นโดยไม่ต้องเสียสละประสิทธิภาพด้านพลังงาน