แก้ไขปัญหา “Zypper ถูกล็อกโดยกระบวนการอื่น” ใน SUSE Linux Enterprise

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

ขั้นแรก ให้ตรวจสอบว่าคุณกำลังเห็นตัวล็อกแบบใด

การล็อกกระบวนการและการล็อกแพ็กเกจนั้นแตกต่างกัน การล็อกกระบวนการจะป้องกันไม่ให้ธุรกรรมการจัดการแพ็กเกจสองรายการเปลี่ยนแปลงระบบพร้อมกัน ในทางตรงกันข้าม การล็อกแพ็กเกจเป็นกฎของผู้ดูแลระบบที่ป้องกันไม่ให้แพ็กเกจที่เลือกถูกติดตั้ง อัปเกรด หรือลบ SUSE ได้จัดทำเอกสารเกี่ยวกับการล็อกแพ็กเกจแยกต่างหากzypper locksคำสั่งจะแสดงรายการกฎแพ็กเกจเหล่านั้น แต่ไม่ได้ระบุถึงกระบวนการที่ถือการล็อกธุรกรรมอยู่

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

เลือกคำตอบที่เหมาะสมกับสถานการณ์

1. ค้นหากระบวนการที่ยึดล็อกไว้

เรียกใช้การตรวจสอบแบบอ่านอย่างเดียวนี้จากเทอร์มินัล:

ps -eo pid,ppid,stat,etime,user,cmd | grep -E '[z]ypper|[y]ast|[p]ackagekit|[r]pm|[z]md'

ผลลัพธ์อาจแสดงให้เห็นถึงการอัปเดตผ่านบรรทัดคำสั่ง, YaST, ไคลเอ็นต์ PackageKit หรือกระบวนการจัดการ เช่น ไคลเอ็นต์เอเจนต์ของ SUSE Manager ชื่อกระบวนการเพียงอย่างเดียวไม่เพียงพอที่จะตัดสินใจว่าปลอดภัยที่จะหยุดหรือไม่ เพราะงานติดตั้งแพ็กเกจที่กำลังทำงานอยู่อาจกำลังทำงานที่สำคัญอยู่ ตรวจสอบเวลาที่ผ่านไป สถานะของกระบวนการ กระบวนการหลัก และหน้าต่างการอัปเดตใดๆ ที่คุณทราบ หากคุณไม่ใช่ผู้ใช้ root ให้ขอให้ผู้ดูแลระบบทำการตรวจสอบหรือยืนยันเจ้าของกระบวนการ

หากข้อผิดพลาดรายงานหมายเลข PID ให้ตรวจสอบกระบวนการนั้นโดยเฉพาะ แทนที่จะพึ่งพาการค้นหาข้อความเพียงอย่างเดียว:

ps -p 1234 -o pid,ppid,stat,etime,user,cmd

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

2. ตัดสินใจว่าจะรอหรือหยุดงานนั้น

รอจนกว่าการทำธุรกรรมจะเสร็จสมบูรณ์

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

หยุดเฉพาะงานที่คุณสามารถระบุและหยุดได้อย่างปลอดภัยเท่านั้น

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

3. ตรวจสอบเครื่องมือซอฟต์แวร์สำหรับการทำงานอัตโนมัติและแบบกราฟิก

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

บนเวิร์กสเตชัน ศูนย์ซอฟต์แวร์หรือเซสชัน YaST อาจใช้ไลบรารีการจัดการแพ็กเกจเดียวกันกับ Zypper ปิดหรือยุติการทำงานของซอฟต์แวร์ผ่านแอปพลิเคชันนั้น อย่าคิดว่า “PackageKit” จะมีอยู่ในการติดตั้ง SLES ทุกครั้ง ตรวจสอบกระบวนการจริงก่อนที่จะพยายามใช้คำสั่งบริการ การปิดใช้งานตัวอัปเดตทั่วโลกอาจขัดขวางการบำรุงรักษาความปลอดภัยที่คาดหวัง ดังนั้นควรเปลี่ยนนโยบายนั้นเฉพาะเมื่อเจ้าของระบบตั้งใจที่จะทำเช่นนั้นเท่านั้น

4. หาก PID ที่บันทึกไว้ไม่ได้ทำงานอีกต่อไป

หากข้อผิดพลาดระบุ PID ให้ตรวจสอบอีกครั้งด้วยps -p PIDคำสั่ง `git log` หากไม่มีกระบวนการใดอยู่ ให้ลองใช้คำสั่ง Zypper เดิมอีกครั้งหนึ่ง ไลบรารีบางเวอร์ชันสามารถตรวจจับได้ว่ากระบวนการที่บันทึกไว้ได้สิ้นสุดลงแล้วและล้างสถานะชั่วคราว แต่พฤติกรรมอาจแตกต่างกันไปตามรุ่นและวิธีที่คำสั่งก่อนหน้านี้สิ้นสุดลง อย่าลบไฟล์ล็อกด้วยตนเอง/run/zypp.pidหรือไฟล์ล็อกอื่นเพียงเพราะไม่มี PID เอกสาร AutoYaST ของ SUSE เตือนไว้อย่างชัดเจนว่าการทำลายการล็อกการจัดการแพ็กเกจนั้นเป็นความเสี่ยงของผู้ใช้เอง

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

5. ใช้คำสั่งวินิจฉัยที่ถูกต้อง

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

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

เมื่อใดควรยกระดับปัญหา

หากการล็อกกลับมาเกิดขึ้นอีกครั้งหลังจากการรีบูตทุกครั้ง กระบวนการทำงานค้างระหว่างการอัปเดตที่สำคัญ ฐานข้อมูลแพ็กเกจรายงานข้อผิดพลาดเพิ่มเติม หรือระบบได้รับการจัดการจากส่วนกลาง ให้ติดต่อผู้ดูแลระบบของคุณ โปรดระบุคำสั่งที่ใช้โดยละเอียด ข้อความแสดงข้อผิดพลาดทั้งหมด PID เวอร์ชัน SLES หรือ Service Pack และผลลัพธ์ของการตรวจสอบกระบวนการแบบอ่านอย่างเดียว SUSE จะบันทึกข้อมูลไว้/var/log/zypper.logในไฟล์บันทึกของ Zypper ซึ่งผู้ดูแลระบบสามารถตรวจสอบรายการในช่วงเวลาที่เกิดความล้มเหลวได้ หลีกเลี่ยงการเผยแพร่บันทึกต่อสาธารณะหากมีชื่อโฮสต์ รายละเอียดที่เก็บข้อมูล ชื่อผู้ใช้ หรือเส้นทางภายใน

ตรวจสอบว่า Zypper สามารถใช้งานได้อีกครั้งแล้วหรือไม่

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

เอกสารอ้างอิงอย่างเป็นทางการจาก SUSE

• คู่มือการดูแลระบบ SLES 15 SP6: การจัดการซอฟต์แวร์ด้วยเครื่องมือบรรทัดคำสั่ง
• คำถามที่พบบ่อยเกี่ยวกับ AutoYaST ใน SLES 15 SP6: Zypper และการล็อกฐานข้อมูล RPM
• คู่มือการดูแลระบบ SLES 15 SP7: การแก้ไขปัญหาและไฟล์บันทึก
• เอกสารประกอบโครงการ libzypp