ปลดล็อก Zypper อย่างปลอดภัยบน SUSE Linux Enterprise
ค้นหาโปรเซสที่กำลังล็อกแพ็กเกจของ Zypper อยู่ แยกแยะความขัดแย้งของโปรเซสออกจากแพ็กเกจที่ถูกล็อก และลองอัปเดตอีกครั้งโดยไม่ต้องลบไฟล์ล็อกโดยไม่รู้สาเหตุ
หาก SUSE Linux Enterprise แจ้งว่า Zypper ถูกล็อกโดยกระบวนการอื่น ให้รอให้การอัปเดตซอฟต์แวร์ การดำเนินการแพ็กเกจ YaST หรือการบำรุงรักษาอัตโนมัติที่กำลังทำงานอยู่เสร็จสิ้นก่อน ตรวจสอบว่ากระบวนการจัดการแพ็กเกจใดเป็นเจ้าของงานนั้นก่อนที่จะหยุดอะไรก็ตาม หากไม่มีการดำเนินการแพ็กเกจใด ๆ และการล็อกยังคงอยู่ ให้ตรวจสอบสถานะที่ค้างอยู่โดยไม่ต้องลบไฟล์ล็อกโดยพลการ จากนั้นลองใช้งาน Zypper อีกครั้ง การล็อกแพ็กเกจที่สร้างขึ้นด้วย YaST zypper addlockเป็นปัญหาที่แตกต่างออกไปและต้องการวิธีแก้ไขที่แตกต่างกัน
Zypper และเครื่องมือจัดการแพ็กเกจพื้นฐานจะปกป้องการทำธุรกรรมแพ็กเกจจากการเปลี่ยนแปลงที่ซ้ำซ้อน การรีเฟรช แพทช์ การติดตั้ง งานซอฟต์แวร์ YaST หรือการอัปเดตตามกำหนดเวลาอาจป้องกันการทำธุรกรรมครั้งที่สองได้ชั่วคราว กลไกการล็อกนี้เป็นกลไกการประสานงาน การปลดล็อกในขณะที่ RPM หรือ Zypper ยังคงเปลี่ยนแปลงแพ็กเกจอยู่อาจทำให้ฐานข้อมูลแพ็กเกจหรือระบบอยู่ในสถานะที่ไม่สอดคล้องกัน
ความแตกต่างที่ได้รับการยืนยัน:การล็อกกระบวนการจะป้องกันการดำเนินการแพ็กเกจพร้อมกัน ในขณะที่การล็อกแพ็กเกจจะป้องกันไม่ให้แพ็กเกจที่ระบุชื่อถูกเลือกสำหรับการติดตั้ง อัปเกรด หรือลบ เอกสารของ SUSE อธิบายการล็อกแพ็กเกจว่าเป็นคุณสมบัติแยกต่างหากคู่มือการบรรจุภัณฑ์ RPM ของ SUSE อธิบายการล็อกแพ็กเกจของ Zypperหากข้อผิดพลาดระบุถึงกระบวนการอื่นหรือบอกว่าตัวจัดการแพ็กเกจกำลังยุ่งอยู่ ให้เริ่มต้นด้วยการตรวจสอบกระบวนการด้านล่าง หากระบุว่าแพ็กเกจใดแพ็กเกจหนึ่งถูกล็อกหรือถูกยกเว้น ให้เรียกใช้sudo zypper locksและตรวจสอบกฎแพ็กเกจที่แสดงแทน
รอสักครู่หากเพิ่งเริ่มการอัปเดต การติดตั้ง หรือการรีเฟรชที่เก็บข้อมูล บนเซิร์ฟเวอร์ ให้ตรวจสอบกับผู้ดูแลระบบหรือเจ้าของระบบอัตโนมัติการบำรุงรักษาก่อน เนื่องจากงานแก้ไขข้อบกพร่องในพื้นหลังอาจไม่แสดงเทอร์มินัลให้เห็น
ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'
มองหา task ของ Zypper, RPM, YaST หรือ PackageKit ที่แท้จริง แล้วจดบันทึก PID, เวลาที่ใช้ไป และคำสั่ง นิพจน์ grep จะหลีกเลี่ยงการจับคู่คำสั่งค้นหาโดยตรงสำหรับ Zypper และ RPM รายการกระบวนการเป็นเพียงภาพรวม ดังนั้นหากผลลัพธ์ไม่ชัดเจน ให้ลองทำซ้ำหลังจากรอสักครู่ ตัวอย่างด้านล่างเป็นมุมมองเทอร์มินัลที่แสดงให้เห็น ไม่ใช่รายงานจากเครื่องจริง

สิ่งที่ยังไม่แน่ชัด:การเห็นกระบวนการทำงานไม่ได้หมายความว่ามันติดขัดเสมอไป การทำธุรกรรมแพ็กเกจอาจกำลังดาวน์โหลดเมตาเดต้า หรือรอพื้นที่จัดเก็บ หรือที่เก็บข้อมูล อย่าหยุดมันเพียงเพราะคำสั่งเงียบไป หากมันกำลังดำเนินการอยู่ ให้รอจนเสร็จสิ้น แล้วจึงเรียกใช้คำสั่ง Zypper เดิมอีกครั้งในภายหลัง
การติดตั้งบนเดสก์ท็อปอาจใช้ PackageKit ในขณะที่เซิร์ฟเวอร์แบบจัดการอาจทำการอัปเดตตามกำหนดเวลาผ่านตัวจับเวลา systemd หรือ SUSE Manager ตรวจสอบเฉพาะบริการที่มีอยู่บนโฮสต์ของคุณเท่านั้น:
systemctl status packagekit
systemctl list-timers --all
หากไม่มี PackageKit ระบบ systemd จะแจ้งว่าไม่พบอุปกรณ์ดังกล่าว ซึ่งไม่ได้หมายความว่า Zypper เสียหาย หากเปิดใช้งานอยู่ ให้ตรวจสอบรายการบันทึกการทำงานล่าสุดและยืนยันว่าไม่มีการติดตั้งหรืออัปเดตใด ๆ กำลังดำเนินการอยู่ก่อนที่จะพิจารณาหยุดการทำงาน
sudo journalctl -u packagekit --since "30 minutes ago"
เมื่อการดำเนินการ PackageKit ที่ได้รับการยืนยันเสร็จสิ้นแล้ว แต่บริการยังคงทำงานอยู่และกำลังบล็อก Zypper ให้ประสานงานกับบุคคลหรือระบบอัตโนมัติที่จัดการการอัปเดต ในโฮสต์ที่จำเป็นต้องหยุดบริการ ให้ใช้คำสั่ง `packagekit.json` sudo systemctl stop packagekitจากนั้นตรวจสอบด้วยsystemctl status packagekitคำสั่ง `packagekit.json` อย่าปิดใช้งานบริการหรือหยุดตัวจับเวลาการอัปเดตที่ไม่เกี่ยวข้องเพื่อเป็นการแก้ไขปัญหาทั่วไป ชื่อและกำหนดการอัปเดตขึ้นอยู่กับส่วนประกอบที่ติดตั้งในระบบและนโยบายการจัดการ

ไฟล์ล็อกที่ค้างอยู่สามารถเกิดขึ้นได้หลังจากเซสชันถูกขัดจังหวะ การรีบูต หรือภารกิจการจัดการล้มเหลว แต่การมีอยู่ของไฟล์ล็อกเพียงอย่างเดียวไม่ได้ระบุสาเหตุ เอกสารสำหรับผู้ใช้ของ SUSE ไม่ได้ให้คำแนะนำสากลในการลบไฟล์ล็อกสำหรับทุกเวอร์ชันและการกำหนดค่าของ SLES ควรหลีกเลี่ยงคำสั่งต่างๆ เช่น คำสั่งrmที่ใช้กับเส้นทางที่คาดเดา และอย่าใช้kill -9กับ PID ที่ไม่รู้จัก ไฟล์ล็อกสามารถถูกสร้างขึ้นใหม่หรือถูกแทนที่ได้ในขณะที่ธุรกรรมกำลังทำงานอยู่ และการลบไฟล์ล็อกไม่ได้หยุดกระบวนการที่เป็นเจ้าของธุรกรรมนั้น
ตรวจสอบรายการกระบวนการอีกครั้ง ตรวจสอบบันทึกบริการที่เกี่ยวข้อง และตรวจสอบให้แน่ใจว่าไม่มีการดำเนินการแพ็กเกจใด ๆ กำลังดำเนินการอยู่ หากคุณสามารถระบุไฟล์ PID หรือเส้นทางล็อกที่ล้าสมัยได้ ให้ตรวจสอบเจ้าของไฟล์และยืนยันกับขั้นตอนที่ระบุไว้สำหรับแพ็คเกจบริการ SLES หรือคำแนะนำการสนับสนุนที่แน่นอนก่อนที่จะเปลี่ยนแปลง สำหรับระบบที่ใช้งานจริง ให้บันทึกข้อผิดพลาดและบันทึกอย่างละเอียด และปฏิบัติตามกระบวนการสนับสนุน SUSE ขององค์กรของคุณ นี่คือจุดที่รายละเอียดเฉพาะที่มีความสำคัญ: ข้อความแสดงข้อผิดพลาด แพ็คเกจบริการ SLES เครื่องมือเดสก์ท็อปที่ติดตั้ง และเอเจนต์การจัดการ อาจเปลี่ยนแปลงการดำเนินการกู้คืนที่ถูกต้องได้
เมื่อการดำเนินการที่แข่งขันเสร็จสิ้นแล้ว ให้รีเฟรชข้อมูลเมตาของที่เก็บข้อมูล:
sudo zypper refresh
การรีเฟรชที่สำเร็จยืนยันว่า Zypper สามารถเข้าถึงที่เก็บข้อมูลได้แล้ว และการล็อกกระบวนการจะไม่ขัดขวางคำสั่งนั้นอีกต่อไป หากงานเดิมของคุณคือการแก้ไขระบบ โปรดดูตัวอย่างการเปลี่ยนแปลงที่เสนอไว้ก่อนที่จะนำไปใช้:
sudo zypper patch --dry-run
ตรวจสอบแพ็กเกจและการดำเนินการในผลลัพธ์ การทดสอบแบบจำลอง (Dry run) คือการตรวจสอบการวางแผน ซึ่งจะไม่ติดตั้งการอัปเดตที่ระบุไว้ เมื่อคาดว่าจะมีการนำเสนอข้อเสนอและช่วงเวลาการบำรุงรักษาของคุณอนุญาต ให้เรียกใช้คำสั่งดังกล่าวsudo zypper patchเอกสาร SUSE SLES 15 SP7 ครอบคลุมการจัดการซอฟต์แวร์ผ่านบรรทัดคำสั่ง รวมถึงการติดตั้งและถอนการติดตั้งซอฟต์แวร์ พฤติกรรมของคำสั่งและตัวเลือกที่มีให้ใช้งานอาจแตกต่างกันไปในแต่ละเวอร์ชัน โปรดดูเอกสารการจัดการซอฟต์แวร์ SLES 15 SP7และ ข้อมูลอ้างอิง Zypper ของ SUSE


zypper locksเมื่อมีการล็อกแพ็กเกจที่ระบุชื่อไว้อย่างชัดเจนเท่านั้น ห้ามลบกฎของแพ็กเกจเพื่อล้างธุรกรรมที่กำลังทำงานอยู่ปัญหาจะได้รับการแก้ไขเมื่อsudo zypper refreshกระบวนการเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาดเกี่ยวกับการล็อก และสามารถเรียกใช้คำสั่งที่ต้องการได้ สำหรับการแก้ไข ให้ตรวจสอบsudo zypper patch --dry-runและยืนยันการดำเนินการที่เสนอไว้ก่อนที่จะนำไปใช้ หากการล็อกกลับมาอีกครั้ง ให้บันทึกข้อผิดพลาดที่แน่นอน รายการกระบวนการ สถานะบริการที่เกี่ยวข้อง เอาต์พุตบันทึกเหตุการณ์ล่าสุด และเวอร์ชัน SLES จากนั้นตรวจสอบกระบวนการหรือเครื่องมือการจัดการที่ทำให้เกิดการล็อกขึ้นอีกครั้ง แทนที่จะลบสถานะการล็อกซ้ำๆ
ค้นหาโปรเซสที่กำลังล็อกแพ็กเกจของ Zypper อยู่ แยกแยะความขัดแย้งของโปรเซสออกจากแพ็กเกจที่ถูกล็อก และลองอัปเดตอีกครั้งโดยไม่ต้องลบไฟล์ล็อกโดยไม่รู้สาเหตุ
ลงทะเบียน SLE HA, บูตสแตรปโหนด SLES 15 จากนั้นเพิ่มการป้องกัน, โควรัม และทรัพยากรบริการที่ผ่านการทดสอบก่อนที่จะพึ่งพาการสลับระบบเมื่อเกิดข้อผิดพลาด
ตรวจสอบหาสาเหตุของข้อผิดพลาดในการรีเฟรชของ Zypper ว่ามาจาก SUSE, RMT หรืออุปกรณ์ปลายทางของบุคคลที่สาม จากนั้นใช้การแก้ไขปัญหาฝั่งเซิร์ฟเวอร์หรือแคชที่ถูกต้องโดยไม่ต้องปิดใช้งานการอัปเดตที่จำเป็น
แก้ไขข้อผิดพลาดเกี่ยวกับพื้นที่ thin-pool ของ SUSE LVM โดยการตรวจสอบการใช้งานข้อมูลและเมตาเดต้า ขยายพูลอย่างปลอดภัย และป้องกันการหยุดทำงานซ้ำซ้อน
ตรวจสอบว่า Btrfs ถูกตั้งค่าเป็นโหมดอ่านอย่างเดียวโดยเจตนา พื้นที่เหลือน้อย หรือกำลังปกป้องข้อมูลหลังเกิดข้อผิดพลาด จากนั้นเลือกวิธีการกู้คืนที่เหมาะสมกับสาเหตุ
เตรียมช่องสัญญาณจำลอง สร้างคีย์การเปิดใช้งาน และบูตสแตรปไคลเอ็นต์ SLES 15 โดยไม่ต้องเข้าถึงอินเทอร์เน็ตโดยตรง ในขณะที่ยังคงรักษาการเชื่อมต่อที่จำเป็นสำหรับการเช็คอินของผู้จัดการไว้
แก้ไขข้อผิดพลาดในการเปิดใช้งาน XIO ของ YaST ผ่าน SSH ตรวจสอบการส่งต่อ X11 และ xauth และสลับไปใช้ส่วนติดต่อ ncurses เมื่อไม่จำเป็นต้องใช้หน้าต่างระยะไกล
ค้นหาสแนปช็อต Btrfs ก่อนการอัปเดต ทดสอบในโหมดอ่านอย่างเดียว และทำให้การกู้คืนเป็นแบบถาวรด้วย Snapper พร้อมทั้งทำความเข้าใจว่าข้อมูลใดบ้างที่อยู่นอกเหนือการย้อนกลับแบบรูท
ส่งบันทึกระบบ SLES ไปยังตัวเก็บรวบรวม rsyslog ระยะไกลผ่าน TLS ที่มีการตรวจสอบสิทธิ์ พร้อมด้วยการตรวจสอบใบรับรอง การบัฟเฟอร์เมื่อระบบขัดข้อง และการทดสอบการส่งมอบ
ใช้บันทึก RAM, swap, kernel และ Zypper เพื่อระบุแรงดันหน่วยความจำที่แท้จริง ป้องกันสถานะของแพ็กเกจ และเลือกวิธีการลองอัปเกรด SLES ที่ปลอดภัยยิ่งขึ้น