systemctl บอกว่า systemd ไม่ใช่ PID 1: แล้วต้องทำอย่างไรต่อ?
ข้อความเรื่อง PID 1 พูดถึงสภาพแวดล้อม ไม่ใช่ OpenVPN ตรวจสอบว่าอะไรทำงานเป็น PID 1 เปิด systemd ในที่ที่รองรับ แล้วจึงอ่านข้อผิดพลาดจริง
การรัน systemctl start openvpn-client@office แล้วได้ข้อความว่าระบบไม่ได้บูตด้วย systemd ดูเหมือนความล้มเหลวของบริการ แต่ไม่ใช่ความล้มเหลวของบริการเลย: systemctl ที่คุณเรียกใช้ไม่พบผู้จัดการที่ทำงานอยู่ให้คุยด้วย ดังนั้นจึงยังไม่ได้ตรวจสอบอะไรเกี่ยวกับ OpenVPN เลย sudo ไม่ได้สร้างผู้จัดการ และการติดตั้งไฟล์ unit ก็ไม่ได้สร้างเช่นกัน คำสั่งกับเครื่องมาจากคนละโลก และข้อผิดพลาดคือที่เดียวที่ทำให้เรื่องนี้ปรากฏ
เริ่มจากถามว่าโปรเซสใดถือ PID 1 อยู่ในที่ที่คำสั่งทำงาน เพราะคำตอบนั้นเป็นตัวตัดสินว่ามี unit อยู่หรือไม่
ข้อผิดพลาดบอกชื่อสภาพแวดล้อม ไม่ใช่ OpenVPN
systemctl เป็นไคลเอนต์ ไม่ใช่ผู้จัดการ มันเชื่อมต่อกับผู้จัดการระบบผ่าน socket และเมื่ออีกฝั่งไม่มีผู้จัดการ มันก็พิมพ์ข้อความที่ผู้คนเอาไปแปะในฟอรัม ps -p 1 -o pid=,comm= แสดงว่าอะไรทำงานเป็น PID 1 จริง ๆ และคำตอบมักเป็นเชลล์ ตัวห่อ init หรือจุดเริ่มต้นของคอนเทนเนอร์เอง ในสถานการณ์นั้นไฟล์ unit อาจถูกต้องสมบูรณ์แต่ไม่เคยถูกอ่านเลย การรันคำสั่งซ้ำในฐานะ root เปลี่ยนเพียงข้อมูลรับรองของไคลเอนต์
อ่านข้อความทั้งหมดก่อนบรรทัดแรก ข้อผิดพลาดจากผู้จัดการเอง เช่น unit ที่หายไปหรือเงื่อนไขที่ล้มเหลว หมายความว่าคุณไปถึงผู้จัดการแล้ว ส่วนข้อผิดพลาดนี้หมายความว่ายังไปไม่ถึง
WSL: การเปิด systemd คือการเปลี่ยนคอนฟิก
WSL ได้รับการสนับสนุน systemd ในรุ่นหลัง ๆ แต่ฟีเจอร์นี้เปิดทีละดิสทริบิวชัน และทำงานเฉพาะที่ WSL รุ่นที่ติดตั้งรองรับเท่านั้น wsl --version ฝั่ง Windows แสดงว่าคุณมีอะไร และไฟล์ /etc/wsl.conf ของดิสทริบิวชันมี [boot] ส่วนที่มี systemd=true แก้ไฟล์นั้นโดยไม่ลบส่วนที่มีอยู่แล้ว จากนั้นรีสตาร์ตอินสแตนซ์ WSL เพื่อให้การเปลี่ยนแปลงมีผล wsl --shutdown หยุดดิสทริบิวชันที่ทำงานอยู่ทั้งหมด จึงควรบันทึกงานไว้ก่อน
หลังเปิดใหม่แล้ว ให้ยืนยันผู้จัดการก่อนแตะ unit ของ OpenVPN: ps -p 1 -o comm= ควรแสดง systemd การเปิด systemd ไม่ได้ให้โปรไฟล์ ข้อมูลรับรอง หรือชื่ออินสแตนซ์ ดังนั้นข้อผิดพลาดถัดไปจะเกี่ยวกับสิ่งใดสิ่งหนึ่งเหล่านี้ ไม่ใช่ PID 1
คอนเทนเนอร์รันจุดเริ่มต้นของตัวเอง ไม่ใช่ unit
คอนเทนเนอร์ปกติเริ่มสิ่งที่จุดเริ่มต้นหรือคำสั่งกำหนด และไม่ใช่เครื่องที่บูตด้วย systemd ไม่ว่าคุณจะติดตั้งแพ็กเกจใด การเพิ่ม systemctl ลงในอิมเมจทำให้คุณได้ไคลเอนต์ที่ไม่มีอะไรให้เชื่อมต่อ สำหรับ Community OpenVPN รูปแบบที่รองรับมักเป็นโปรเซสที่ทำงานอยู่เบื้องหน้า openvpn --config /path/to/client.conf เริ่มโดยจุดเริ่มต้นและถูกดูแลจากภายนอก เจ้าของนั้นจัดการการเริ่มต้น สัญญาณ และการปิด และควรเป็นสิ่งเดียวที่จัดการทันเนล
อย่าเปิดสำเนาแบบโต้ตอบข้างจุดเริ่มต้นที่จัดการทันเนลนั้นอยู่แล้ว เพราะ สองโปรเซสจะแย่งอุปกรณ์และเส้นทางกัน โปรเซส init ขนาดเล็กในคอนเทนเนอร์เก็บกวาดโปรเซสลูกและส่งต่อสัญญาณ แต่ไม่ได้เปลี่ยนอิมเมจให้เป็นโฮสต์ที่มี unit
ถ้าการติดตั้งต้องการ systemd ในคอนเทนเนอร์จริง ๆ ก็ต้องใช้อิมเมจที่ออกแบบมาเพื่อสิ่งนั้นโดยเฉพาะ ไม่ใช่การเพิ่มสิทธิ์พิเศษไปเรื่อย ๆ จนกว่า systemctl จะเลิกบ่น
อ่านข้อผิดพลาดถัดไปเมื่อมีผู้จัดการแล้ว
เมื่อผู้จัดการจริงเริ่มบริการ ข้อผิดพลาดที่มีประโยชน์ก็เริ่มขึ้น ความล้มเหลวของสิทธิ์อุปกรณ์ ข้อผิดพลาดในการแยกวิเคราะห์คอนฟิก ข้อมูลรับรองที่หายไป และเพียร์ที่เข้าถึงไม่ได้ คือปัญหาที่แตกต่างกันสี่อย่างที่ข้อความเรื่อง PID 1 ไม่เคยทดสอบ อ่านตามลำดับที่ unit สร้างขึ้น โดยใช้ journalctl -u openvpn-client@office -n 50 บนโฮสต์ systemd หรือรันไคลเอนต์ในเบื้องหน้าในที่ที่ไม่มีผู้จัดการ การรันในเบื้องหน้ายังเป็นวิธีที่เร็วที่สุดในการยืนยันว่าโปรไฟล์เองทำงานได้
แยกสองสภาพแวดล้อมไว้ในบันทึกของคุณ: โฮสต์ที่รันทันเนล และที่ที่คุณพิมพ์คำสั่ง