nordvpn แจ้งว่าเข้าถึงเดมอนไม่ได้: socket กลุ่ม หรือ unit?

การรัน nordvpn แล้วได้ข้อความเกี่ยวกับเดมอนที่เข้าถึงไม่ได้นั้นเป็นการบ่นแคบ ๆ ที่มักมาถึงตอนที่คุณสายไปแล้ว มันไม่ได้บอกอะไรว่าอุโมงค์ทำงานหรือไม่ เพราะ CLI เป็นเพียงส่วนหน้าฉาก: มันคุยกับโปรเซสเบื้องหลังผ่าน Unix socket และข้อความหมายความว่าการสนทนานั้นไม่ได้เกิดขึ้น จงเดินจากคำสั่งออกไปด้านนอกแล้วหยุดที่สิ่งแรกที่พิสูจน์แล้วว่าไม่จริง

เริ่มจากจุดที่ข้อผิดพลาดปรากฏ

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

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

ตรวจสอบ unit ก่อนสิ่งอื่นใด

ถามผู้จัดการบริการว่าเดมอนทำงานอยู่หรือไม่ แล้วเริ่มและเปิดใช้งานในขั้นตอนเดียวถ้าไม่ได้ทำงาน:

systemctl status nordvpnd
sudo systemctl enable --now nordvpnd
nordvpn version

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

การแสดงรายการไฟล์ unit ตัดสินเรื่องนี้ได้ด้วยคำสั่งเดียว และคุ้มค่าที่จะทำก่อนสรุปสิ่งใดเกี่ยวกับการติดตั้ง:

systemctl list-unit-files 'nordvpn*'
service --status-all

รีลีสได้ส่งบริการภายใต้ชื่อ unit มากกว่าหนึ่งชื่อ ดังนั้น build ที่ใช้ nordvpn แทน nordvpnd จะสร้างสำเนาที่สมบูรณ์ของข้อผิดพลาดนี้ในขณะที่มีบริการที่แข็งแรงทำงานอยู่ติด ๆ กัน

socket และกลุ่มของมันเป็นตัวกำหนดการเข้าถึง

แม้เดมอนจะทำงานอยู่ การเชื่อมต่ออาจถูกปฏิเสธเพราะสิทธิ์ ตัวติดตั้งสร้างกลุ่ม nordvpn และ socket ก็มีเจ้าของตามนั้น ผู้ใช้ที่อยู่นอกกลุ่มจึงถูกปฏิเสธในขณะที่บริการสมบูรณ์ดี

sudo usermod -aG nordvpn "$USER"
newgrp nordvpn

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

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

ls -l /run/nordvpn
id

โปรเซสที่ยังมีชีวิตไม่ใช่หลักฐานว่าเป็น socket ที่ถูกต้อง เดมอนที่ถูกเริ่มโดยผู้จัดการอื่น หรือแพ็กเกจเก่าที่ผูก socket ชื่ออื่น ก็รายงานเหมือนกัน การแสดงรายการไดเรกทอรีแยกกรณีเหล่านั้นได้ในบรรทัดเดียว จึงดีกว่าการติดตั้งใหม่

โปรเซสต่อผู้ใช้ในการแพ็กเกจแบบเก่า

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

บน init ที่ไม่ใช่ systemd การจัดวางที่บันทึกไว้ในเอกสารแบ่งบทบาท: บริการระบบทำงานภายใต้ชื่อหนึ่ง และโปรเซสฝั่งผู้ใช้ทำงานภายใต้บัญชีเป้าหมายด้วย chpst -u <user> ตรวจสอบว่าการติดตั้งของคุณใช้การจัดวางแบบใดจริง ๆ ก่อนเพิ่มสคริปต์เริ่มต้นที่สมมติอีกแบบหนึ่ง

จะรู้ได้อย่างไรว่าคุณทำเสร็จแล้ว

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

sudo systemctl stop nordvpnd
sudo systemctl enable --now nordvpnd
sudo systemctl start nordvpnd
nordvpn version

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

หาก socket ยังหายอยู่ อ่านเจอร์นัลของ unit เพื่อดูว่าทำไมมันหยุด แล้วตรวจสอบว่า /run/nordvpn มีอยู่และบัญชีบริการเขียนที่นั่นได้ โปรเซสที่ลุกขึ้นแล้วตายทันทีจะบันทึกเหตุผลไว้ในเจอร์นัลนั้น และการอ่านหนึ่งบรรทัดเร็วกว่าการติดตั้งใหม่