ทำไมยูนิต VPN จึงเริ่มก่อนเครือข่ายแล้วตายในภายหลัง

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

เป้าหมายคือจุดนัดพบ ไม่ใช่ผู้จัดการ

network-online.target ไม่รู้ว่าเครือข่ายคืออะไร มันคือจุดประสานงานที่รวบรวมบริการซึ่งควรเลื่อนการเริ่มระบบออกไปจนกว่าลิงก์จะใช้งานได้ และมอบหมายคำจำกัดความให้ผู้จัดการเครือข่ายที่ครอบครองเครื่อง ในเดสก์ท็อปและเซิร์ฟเวอร์ส่วนใหญ่ นั่นหมายถึงบริการรอที่จัดหาโดย NetworkManager หรือ systemd-networkd ถ้าไม่เปิดทั้งสองอย่าง เป้าหมายก็ไม่มีอะไรให้รอ จึงเสร็จสิ้นในทันทีที่มีบางสิ่งดึงมันเข้ามา ซึ่งอาจเกิดขึ้นนานก่อนที่ DHCP จะตอบ บรรทัดลำดับในยูนิตของคุณซื่อสัตย์และยังคงไร้ประโยชน์

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

อ่านการบูตครั้งล่าสุดแทนไฟล์ยูนิต

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

เพิ่มการรอ แล้วจึงเพิ่มการลองใหม่

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

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

[Service]
Restart=on-failure
RestartSec=15

ทำไมการนอนหลับแบบคงที่จึงเป็นกับดัก

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

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

เมื่อลำดับถูกต้องแต่ชื่อยังคงล้มเหลว

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

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