มีบางอย่างเริ่มยูนิต OpenVPN ซ้ำๆ: หาต้นตอให้ได้

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

ระบุชื่อยูนิตที่แน่นอนก่อน

เริ่มจากชื่อยูนิตใน journal ไม่ใช่จากชื่อไฟล์โปรไฟล์ อินสแตนซ์อาจชื่อ openvpn@, openvpn-client@, openvpn-server@ หรืออะไรที่เฉพาะกับดิสทริบิวชัน และการเดาชื่อจะพาคุณไปยังเทมเพลตที่ผิด เอาต์พุตสถานะระบุชื่อยูนิตที่ทำงานจริง และนั่นคือชื่อเดียวที่สำคัญตรงนี้ คัดลอกให้ตรงทุกตัวอักษรรวมถึงส่วนต่อท้ายใดๆ

คำสั่งต่อไปนี้อธิบายยูนิตนั้นโดยไม่เปลี่ยนอะไรเลย systemctl show รายงานพาธของแฟรกเมนต์ พาธต้นทาง สถานะไฟล์ยูนิต drop-in ใดๆ และสิ่งที่กระตุ้นมัน list-dependencies --reverse แสดงว่ายูนิตที่โหลดอยู่ใดชี้มาที่มัน ทั้งสองเป็นคำสั่งอ่านอย่างเดียว จึงควรรันก่อนตั้งสมมติฐาน

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

อ่านเทมเพลตเพื่อรู้ชื่อไฟล์

ยูนิตอินสแตนซ์คือส่วนขยายของเทมเพลต และเทมเพลตเป็นตัวกำหนดว่าจะอ่านไฟล์คอนฟิกูเรชันใด (อ่านไฟล์คอนฟิกูเรชันใด) บรรทัดคำสั่งที่ลงท้ายด้วยตัวแทนเฉพาะอินสแตนซ์จะถูกแปลงเป็นชื่ออินสแตนซ์บวกส่วนต่อท้าย ถ้าส่วนต่อท้ายเป็น .conf และอินสแตนซ์ชื่อ old ไฟล์คือ old.conf ถ้าตั้งชื่ออินสแตนซ์เป็น old.conf เทมเพลตเดิมจะขอ old.conf.conf

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

อ่านเทมเพลตที่ใช้งานจริง ไม่ใช่ไฟล์ที่คุณจำได้ว่าแก้ไข drop-in สามารถแทนที่บรรทัดคำสั่ง และสิ่งที่รันตอนบูตคือฉบับแทนที่นั้น

ตามรอยว่ามันเข้ามาในทรานแซกชันการบูตได้อย่างไร

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

เอาต์พุตที่สร้างใต้ /run/systemd/generator เป็นผลผลิต ไม่ใช่ต้นตอ การแก้ไขจะอยู่ได้เพียงถึงการสร้างครั้งถัดไป การแก้ที่ทำตรงนั้นจึงดูสำเร็จแล้วก็ย้อนกลับ

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

ลบการเปิดใช้งาน ไม่ใช่แค่โปรเซส

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

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

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

ตรวจสอบด้วยการรีบูต ไม่ใช่ด้วยหน้าจอสถานะ

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

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