มีไฟล์ PID แต่ไม่มีอุโมงค์: OpenVPN เคยทำงานจริงหรือไม่

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

เริ่มจากบริการ ไม่ใช่จากไฟล์

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

อ่านยูนิตหรือสคริปต์ที่พิมพ์ข้อความนั้น แล้วสังเกตสามสิ่ง: พาธที่มันตรวจสอบ ประเภทบริการที่มันประกาศ และไม่ว่ามันรับผิดชอบการเขียนไฟล์หรือไม่ ยูนิตสมัยใหม่สามารถใช้การกำกับดูแลแบบง่ายหรือแบบแจ้งเตือนและไม่แตะไฟล์ PID เลย ในขณะที่สคริปต์ init เก่าอาจสร้างไฟล์เอง การคัดลอกการตรวจสอบจากรูปแบบหนึ่งไปยังอีกรูปแบบหนึ่งก่อให้เกิดการปฏิเสธแบบนี้พอดี ค้นหาว่าใช้รูปแบบใดก่อนตีความสิ่งใด

จากนั้นเท่านั้นคำถามจึงกลายเป็นว่าอินสแตนซ์กำลังทำงานจริงหรือไม่

ตรวจสอบว่าตัวระบุนั้นเป็นของอินสแตนซ์ของคุณหรือไม่

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

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

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

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

ตัวเริ่มสัญญาอะไรไว้เกี่ยวกับไฟล์

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

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

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

การปิดที่สะอาดเทียบกับการออกที่ถูกขัดจังหวะ

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

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

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

หยุดลบไฟล์ตามนิสัย

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

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

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