إصلاح مشكلة "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. لا يكفي اسم العملية وحده لتحديد ما إذا كان من الآمن إيقافها، فقد تكون مهمة الحزمة قيد التشغيل تقوم بعمل مهم. تحقق من الوقت المنقضي، وحالة العملية، والعملية الأصلية، وأي نافذة تحديث تعرفها. إذا لم تكن مستخدمًا بصلاحيات الجذر، فاطلب من مسؤول النظام تشغيل الفحص أو تأكيد مالك العملية.

إذا أبلغ الخطأ عن معرّف العملية (PID)، فافحص تلك العملية تحديدًا بدلاً من الاعتماد فقط على البحث النصي:

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

استبدل 1234برقم تعريف العملية (PID) من رسالتك. يُنصح عمومًا بالسماح للعمليات التي تستخدم وحدة المعالجة المركزية، أو تُغير حالتها، أو تنتمي إلى خدمة تحديث معروفة، بالانتهاء. إذا كان الأمر عبارة عن أمر طرفي قمت بتشغيله بنفسك، فارجع إلى تلك النافذة الطرفية واقرأ موجه الأوامر أو مخرجات التقدم الحالية.

2. قرر ما إذا كنت ستنتظر أم ستتوقف عن إنجاز مهمة ما

انتظر حتى تصبح المعاملة نشطة

إذا كانت الحزم قيد التنزيل أو التثبيت، أو كان الأمر ينتظر تأكيدًا، فإن الانتظار هو الخيار الأقل خطورة. قد يستغرق تحديث الحزمة وقتًا أطول على وحدات التخزين البطيئة، أو مع دفعات التحديث الكبيرة، أو على الأنظمة التي تحتوي على العديد من الحزم. عند الانتهاء، أعد محاولة تنفيذ الأمر الأصلي مرة واحدة. إذا لم يُحرز أي تقدم لفترة طويلة بشكل غير معتاد، فدوّن مُعرّف العملية (PID) والوقت، ثم تحقق من سجلات الطرفية أو خدمة التحديث ذات الصلة قبل اتخاذ أي إجراء.

أوقف فقط المهمة التي يمكنك تحديدها ومقاطعتها بأمان

إذا بدأتَ الأمر الآخر وما زال في نافذة تفاعلية، فأجب عليه أو ألغِه باستخدام الخيار المعتاد في النافذة. بالنسبة لبرنامج تحديث سطح المكتب، استخدم خيار الإلغاء أو الإغلاق الخاص به إن وُجد. لا تستخدمه kill -9كاختصار. قد يؤدي الإنهاء المفاجئ إلى مقاطعة عملية RPM أو ترك النظام في حالة تحتاج إلى إصلاح إضافي. على خادم الإنتاج، نسّق مع مسؤول التحديث واتبع إجراءات الصيانة المعتمدة بدلاً من إيقاف عملية غير مألوفة.

3. تحقق من أدوات البرامج الآلية والرسومية

في أنظمة SLES المُدارة، قد يتم تشغيل التحديثات بواسطة مسؤول النظام، أو مُجدول التحديثات، أو خادم الإدارة المركزي. تحقق من جدول صيانة مؤسستك وحالة أي مهمة تحديث قبل بدء عملية أخرى. إذا ظهر القفل بشكل متكرر في نفس الوقت، قارن الطوابع الزمنية مع المهام المُجدولة. قد يكون الحل الأمثل هو إعادة جدولة الصيانة اليدوية أو تنسيق فترة تحديث واحدة، وليس تعطيل خدمة الإدارة.

على محطة العمل، قد يستخدم مركز البرامج أو جلسة YaST نفس مكتبة إدارة الحزم التي يستخدمها Zypper. أغلق أو أنهِ عملية البرنامج من خلال ذلك التطبيق. لا تفترض وجود "PackageKit" في كل تثبيت SLES؛ تحقق من العملية الفعلية قبل محاولة تنفيذ أوامر الخدمة. قد يؤدي تعطيل أداة التحديث بشكل عام إلى منع الصيانة الأمنية المتوقعة، لذا لا تُغير هذه السياسة إلا إذا كان مالك النظام ينوي القيام بذلك.

4. إذا لم يعد معرّف العملية المسجل قيد التشغيل

إذا أشار الخطأ إلى مُعرّف عملية (PID)، فتحقق منه مرة أخرى ps -p PID. إذا لم تكن هناك عملية موجودة، فأعد محاولة تنفيذ أمر Zypper الأصلي مرة واحدة. تستطيع بعض إصدارات المكتبة اكتشاف انتهاء عملية مُسجلة وتنظيف الحالة المؤقتة، ولكن قد يختلف السلوك باختلاف الإصدار وكيفية انتهاء الأمر السابق. لا تقم بإزالة ملف القفل يدويًا /run/zypp.pidأو أي ملف قفل آخر لمجرد عدم وجود مُعرّف العملية. تُحذّر وثائق AutoYaST من SUSE صراحةً من أن كسر قفل إدارة الحزم يقع على مسؤولية المستخدم.

إذا استمر الخطأ بعد إعادة المحاولة، فتوقف واجمع معلومات الخطأ بالتحديد، وحزمة خدمة SLES، والوقت، وسجل التحديثات الأخيرة. قد تُزيل إعادة التشغيل المُتحكَّم بها حالةً مؤقتة، ولكن لا تُجدولها إلا بعد التأكد من عدم وجود أي عملية حزمة نشطة وبعد التحقق من تأثيرها على الخدمات قيد التشغيل. في الأنظمة الحيوية، اطلب من المسؤول أو دعم SUSE مراجعة الحالة أولاً.

5. استخدم أمر التشخيص الصحيح

zypper psيُعدّ هذا الأمر مفيدًا بعد تغييرات الحزم، ولكنه يُساء فهمه غالبًا. في دليل إدارة SLES، يسرد هذا الأمر العمليات التي لا تزال تستخدم ملفات حُذفت أو استُبدلت أثناء الترقيع أو التحديث أو إزالة الحزم. وهو ليس الأمر المُستخدم لمعرفة من يملك قفل معاملة Zypper حاليًا. استخدم الأمر ps`pid` مع مُعرّف العملية (PID) من رسالة القفل الخاصة بتلك المهمة.

وبالمثل، zypper locksيعرض هذا الأمر أقفال مستوى الحزمة. من المفيد التحقق مما إذا كانت حزمة معينة لا تزال غير متاحة بعد إزالة قفل العملية، ولكن هذا لن يحرر قفل معاملة نشط. هذا التمييز مهم: فحذف قفل حزمة أو تغيير اختيار حزمة لا يمكن أن يُصلح عملية أخرى لا تزال تستخدم مدير الحزم.

متى يجب التصعيد

أبلغ مسؤول النظام إذا تكرر القفل بعد كل إعادة تشغيل، أو إذا تعطلت عملية أثناء تحديث هام، أو إذا أبلغت قاعدة بيانات الحزم عن أخطاء إضافية، أو إذا كان النظام مُدارًا مركزيًا. أرفق الأمر الدقيق، ونص الخطأ الكامل، ومعرّف العملية (PID)، وإصدار SLES أو حزمة الخدمة، ومخرجات فحص العملية للقراءة فقط. تُوثّق SUSE هذه المشكلة /var/log/zypper.logفي ملف سجل Zypper؛ ويمكن للمسؤول مراجعة الإدخالات المتعلقة بوقت حدوث العطل. تجنّب مشاركة السجلات علنًا إذا كانت تحتوي على أسماء مضيفين، أو تفاصيل مستودع، أو أسماء مستخدمين، أو مسارات داخلية.

تأكد من توفر تطبيق Zypper مرة أخرى

بعد اكتمال المعاملة المعروفة، أو بعد أن يحل المسؤول مشكلة تعطل النظام، نفّذ أمرًا للقراءة فقط، مثل `package.json` zypper --versionأو `package.json` zypper repos. إذا اكتمل الأمر بنجاح دون ظهور تحذير القفل، فأعد محاولة تنفيذ أمر الحزمة المطلوب خلال فترة تحديث معتمدة. راجع التغييرات المقترحة من Zypper قبل التأكيد. يجب أن يكتمل الأمر بنجاح دون مقاطعة عملية إدارة الحزم الثانية؛ إذا ظهرت رسالة القفل، فحدد معرّف العملية الجديد (PID) بدلاً من حذف الملفات أو تكرار المعاملة.

المراجع الرسمية لشركة SUSE

• دليل إدارة SLES 15 SP6: إدارة البرامج باستخدام أدوات سطر الأوامر
• الأسئلة الشائعة حول SLES 15 SP6 AutoYaST: Zypper وقفل قاعدة بيانات RPM
• دليل إدارة SLES 15 SP7: استكشاف الأخطاء وإصلاحها وملفات السجل
• وثائق مشروع libzypp