แก้ไขปัญหาเซิร์ฟเวอร์ SUSE Linux ค้างระหว่างการรีบูตขณะปิดระบบ systemd

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

คู่มือนี้ใช้ตัวอย่างสมมติตลอดทั้งเล่ม: เซิร์ฟเวอร์ชื่อlab-sles01ใช้ระบบปฏิบัติการ SUSE Linux Enterprise Server และเกิดอาการหยุดชะงักระหว่างการรีบูตพร้อมข้อความคล้ายกับA stop job is running for backup.serviceตัวอย่างนี้เป็นเพียงภาพประกอบวิธีการวินิจฉัยเท่านั้น ไม่ใช่รายงานการทดสอบจริงหรือข้อกล่าวอ้างที่ว่า SUSE รุ่นใดรุ่นหนึ่งมีข้อบกพร่องในบริการชื่อ แต่อย่างbackup.serviceใด

วิธีแก้ไขสี่ขั้นตอนโดยสรุป

ขั้นตอนที่ 1: บันทึกตำแหน่งที่การปิดระบบหยุดลงอย่างแม่นยำ

ระหว่างการรีบูตตามแผน ให้สังเกตคอนโซลภายในเครื่อง คอนโซลเสมือน คอนโซล BMC/IPMI หรือคอนโซลไฮเปอร์ไวเซอร์ บรรทัดที่ระบุชื่อหน่วยจะมีความเป็นประโยชน์มากกว่าคำอธิบายทั่วไป เช่น “systemd ค้าง” lab-sles01สมมติว่าคอนโซลแสดงว่า systemd backup.serviceยังคงหยุดทำงานอยู่ ในขณะที่หน่วยอื่นๆ ปิดตัวลงไปแล้ว

ตัวอย่างประกอบ: คอนโซลการปิดระบบระบุbackup.serviceว่าเป็นหน่วยที่ systemd ยังคงรออยู่

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

คำแนะนำเกี่ยวกับ systemd ในปัจจุบันของ SUSE ระบุว่า การรีบูตหรือปิดเครื่องเป็นเวลานานอาจเกิดจากบริการที่ไม่หยุดทำงาน และแนะนำให้ตรวจสอบงาน systemd ดูได้ที่SUSE Linux Enterprise Server 16.0: Introduction to systemd Basics

ขั้นตอนที่ 2: ใช้บันทึกการบูตก่อนหน้าหลังจากที่เซิร์ฟเวอร์กลับมาทำงานแล้ว

หลังจากเครื่องบูตขึ้นมาอีกครั้ง ให้ตรวจสอบการปิดเครื่องที่เพิ่งเกิดขึ้น SUSE จะบันทึกค่าออฟเซ็ตการบูตไว้ในบันทึก (journal): boot 0คือการบูตปัจจุบัน, -1คือการบูตครั้งก่อน และอื่นๆ เริ่มจาก:

sudo journalctl --list-boots
sudo journalctl -b -1

สำหรับวารสารขนาดใหญ่ การเรียงลำดับแบบย้อนกลับจะช่วยให้ค้นหาข้อความสุดท้ายได้เร็วขึ้น:

sudo journalctl -b -1 -r

ตัวอย่างประกอบ: บันทึกการบูตครั้งก่อนแสดงให้เห็นว่าบริการสำรองข้อมูลสมมุติได้รับสัญญาณ SIGTERM และต่อมาเกิดการหมดเวลา

มองหาวลีต่างๆ เช่นStopping, stop job, timed out, Failed with result, Unmounting, Dependency failed, หรือข้อความจากหน่วยงานที่ต้องสงสัยนั้นเอง คุณสามารถจำกัดขอบเขตการค้นหาให้แคบลงได้เมื่อทราบชื่อหน่วยงานแล้ว:

sudo journalctl -b -1 -u backup.service

เอกสารของ SUSE journalctl -b -1เกี่ยวกับการวิเคราะห์การบูตครั้งก่อนอยู่ในเอกสารบันทึกการบูต SLES 15 SP7หากjournalctl --list-bootsไม่มีข้อมูลการบูตครั้งก่อน อย่าสรุปเอาเองจากประวัติที่หายไป ตรวจสอบวิธีการกำหนดค่าการจัดเก็บข้อมูล journald และใช้คอนโซลหรือการบันทึกระยะไกลสำหรับการจำลองปัญหาครั้งต่อไป

ขั้นตอนที่ 3: ระบุว่าตัวบล็อกนั้นเป็นบริการ การติดตั้ง ตัวยับยั้ง หรือฮุกการปิดระบบล่าช้า

หากคุณสามารถจำลองปัญหาได้ในระหว่างช่วงเวลาการบำรุงรักษา โปรดเตรียมคอนโซลการจัดการสำรองไว้ด้วย ก่อนที่การเชื่อมต่อจะขาดหาย ให้เรียกใช้คำสั่งต่อไปนี้:

sudo systemctl list-jobs
sudo systemctl status backup.service

ตัวอย่างประกอบ: backup.serviceมีงานหยุดที่กำลังทำงานอยู่ ในขณะที่เป้าหมายการรีบูตกำลังรออยู่ด้านหลัง

คำแนะนำการดีบัก systemd ต้นทางอธิบายว่างานที่แสดงเป็นrunningต้องเสร็จสิ้นก่อนที่งานที่เกี่ยวข้องซึ่งแสดงเป็นwaitingจะสามารถดำเนินการต่อไปได้ SUSE ยังแนะนำให้ใช้systemctl list-jobsคำสั่งนี้เมื่อการปิดเครื่องหรือรีบูตใช้เวลานานเกินไป ซึ่งทำให้คำสั่งนี้มีประโยชน์อย่างยิ่งเมื่อเซิร์ฟเวอร์ไม่ได้หยุดทำงานโดยสมบูรณ์และ PID 1 ยังคงตอบสนองอยู่

หากบริการหยุดทำงานช้าเกินไป

ตรวจสอบคำจำกัดความของหน่วยและการทำงานเมื่อปิดระบบ:

sudo systemctl cat backup.service
sudo systemctl status backup.service
sudo journalctl -u backup.service -b

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

หากเกี่ยวข้องกับการเมานต์หรือระบบไฟล์เครือข่าย

ตรวจสอบหาการดำเนินการยกเลิกการเมานต์ที่ล้มเหลว และระบุแหล่งที่มาของการเมานต์:

findmnt
systemctl list-units --type=mount
sudo journalctl -b -1 | grep -Ei 'unmount|umount|mount|nfs|cifs'

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

หากคำขอรีบูตถูกระงับ

ก่อนที่ระบบจะเริ่มต้น คุณสามารถแสดงรายการตัวยับยั้ง systemd ที่ทำงานอยู่ได้:

systemd-inhibit --list

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

หากระบบค้างหลังจากที่บริการล่มไปแล้ว

หากระบบค้างในช่วงท้ายๆ จำเป็นต้องตรวจสอบด้วยวิธีอื่น systemd จะรันไฟล์ปฏิบัติการภายใต้ไดเร็กทอรีนั้น/usr/lib/systemd/system-shutdown/ก่อนการรีบูตหรือปิดเครื่องครั้งสุดท้าย และรอจนกว่าไฟล์เหล่านั้นจะทำงานเสร็จ หากบันทึกและคอนโซลแสดงว่าบริการปกติหยุดทำงานไปแล้ว และการค้างเกิดขึ้นในขั้นตอนการปิดเครื่องขั้นสุดท้าย ให้ตรวจสอบไดเร็กทอรีนั้นและฮุกที่ผู้จำหน่ายติดตั้งไว้เอกสารบริการปิดเครื่องของ systemdอธิบายพฤติกรรมนี้ไว้แล้ว

ขั้นตอนที่ 4: แก้ไขส่วนประกอบ จากนั้นทดสอบการรีบูตตามปกติ

กลับไปที่สถานการณ์สมมติlab-sles01สมมติว่าบันทึกแสดงให้เห็นว่าบริการนั้นbackup.serviceไม่สนใจการยุติการทำงานตามปกติหลังจากกระบวนการสำรองข้อมูลเสร็จสมบูรณ์แล้ว ทางเลือกแรกคือการแก้ไขบริการหรือคำสั่งหยุดการทำงาน หากทราบว่าบริการนั้นปลอดภัยที่จะยุติการทำงานหลังจากช่วงเวลาที่จำกัด การตั้งค่า systemd แบบต่อหน่วยสามารถจำกัดระยะเวลาที่ systemd รอได้

สร้างการแทนที่แทนการแก้ไขหน่วยผู้ขายภายใต้/usr/lib/systemd/system:

sudo systemctl edit backup.service

ตัวอย่างเช่น:

[Service]
TimeoutStopSec=30s

จากนั้นให้โหลดการกำหนดค่าหน่วยของ systemd ใหม่:

sudo systemctl daemon-reload

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

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

เมื่อคุณพอใจกับการเปลี่ยนแปลงแล้ว ให้ลองรีบูตเครื่องตามปกติ:

sudo systemctl reboot

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

คุณควรใช้การรีบูตแบบบังคับเมื่อใด?

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

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

sudo systemctl reboot --force

หลีกเลี่ยงการใช้การปิดเปิดsystemctl reboot --force --forceเครื่องเสมือน (virtual power-cycle) หรือการรีเซ็ตเครื่อง (physical reset) เป็นวิธีแก้ปัญหาปกติ การกระทำเหล่านั้นอาจลบหลักฐานที่คุณต้องการและอาจเป็นอันตรายต่อการเขียนข้อมูลที่กำลังดำเนินการอยู่เอกสาร systemctl ต้นฉบับได้ แยกความแตกต่างระหว่างพฤติกรรมการใช้คำสั่งเดียว (single-force) และสองคำสั่ง (double-force) ไว้อย่างชัดเจน

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

ใช้คอนโซลการบำรุงรักษาและบูตเข้าสู่โหมดกู้คืน เอกสารของ SUSE อธิบายวิธีการเพิ่มsystemd.unit=rescue.targetคำสั่งลงในบรรทัดคำสั่งเคอร์เนลจากตัวแก้ไข GRUB โหมดกู้คืนจะให้เซสชัน root พร้อมระบบไฟล์ในเครื่องและบริการหลัก ในขณะที่เครือข่ายจะไม่ทำงาน ซึ่งสามารถช่วยคุณปิดใช้งานหรือซ่อมแซมบริการหรือการกำหนดค่าการเมานต์ที่มีปัญหาได้

โปรดดูคู่มือการดูแลระบบ SLES 15 SP7สำหรับขั้นตอนการกู้คืนระบบอย่างเป็นทางการ สำหรับระบบที่ปัญหาปรากฏขึ้นเฉพาะหลังจากมีการเปลี่ยนแปลงแพ็กเกจ เคอร์เนล ไดรเวอร์ หรือหน่วยเก็บข้อมูลบางอย่าง โปรดตรวจสอบประวัติการบำรุงรักษา SUSE ที่เกี่ยวข้องก่อนทำการเปลี่ยนแปลงค่าหมดเวลาอย่างถาวร

ตารางการตัดสินใจอย่างรวดเร็ว

สรุปแล้ว

สำหรับเซิร์ฟเวอร์ SUSE Linux ที่ค้างอยู่ที่ขั้นตอนการปิดระบบของ systemd วิธีแก้ไขที่ยั่งยืนคือการระบุว่า systemd กำลังรออะไรอยู่ และแก้ไขหน่วยงานนั้นหรือส่วนประกอบที่เกี่ยวข้อง บันทึกข้อความการปิดระบบ ตรวจสอบjournalctl -b -1ใช้systemctl list-jobsและsystemctl statusเพื่อแยกตัวบล็อก แล้วค่อยเปลี่ยนค่าหมดเวลาต่อบริการหรือการกำหนดค่าการเมานต์ เก็บวิธีการรีบูตแบบบังคับไว้สำหรับสถานการณ์การกู้คืน ไม่ใช่สำหรับการดำเนินการตามปกติ