بدأ هذا الموضوع باعتباره شكوى من التشغيل التلقائي للتطبيقات، لكن ردًا لاحقًا حدّد نمط فشل أعمق: إذ تعذّر تشغيل Docker نفسه لأن تجاوزًا في systemd فرض استخدام nvidia-container-runtime على مضيف كان مسار وقت التشغيل فيه غير متوافق.
تحقق أولًا مما إذا كان Docker قيد التشغيل
إذا فشلت عدة تطبيقات غير مترابطة بعد إعادة التشغيل، فتحقق من خدمة Docker قبل تعديل كل تطبيق على حدة. يوضح دليل استكشاف أخطاء عفريت Docker وإصلاحها حالات فشل بدء العفريت الناتجة عن تعارض الإعدادات وتجاوزات systemd.
تساعد متطلبات متجر تطبيقات ZimaOS في تحديد التطبيقات التي تعتمد على Docker، بينما يوضح تطبيق Docker الأول سير العمل المعتاد للحاويات في ZimaOS. وتكون المشكلة التي تؤثر في عدة حاويات في الوقت نفسه أقرب إلى أن تكون في طبقة العفريت/وقت التشغيل، لا تسعة أخطاء مستقلة في التطبيقات.
سياسة إعادة التشغيل ليست الطبقة الوحيدة
توضح سياسات إعادة تشغيل Docker أن سياسات إعادة التشغيل تتحكم فيما يفعله العفريت بالحاويات المتوقفة. لكنها لا تفيد إذا تعذّر على عفريت Docker نفسه بدء التشغيل بصورة صحيحة.
كان إصلاح وقت تشغيل NVIDIA خاصًا بالنظام
عطّل أحد المساهمين تجاوزًا في systemd خاصًا بـ Docker، كان يضيف صراحةً nvidia-container-runtime. وبعد إعادة التشغيل، عاد Docker إلى العمل، لكن دعم وحدة معالجة الرسومات NVIDIA لم يعد مكوّنًا عبر ذلك التجاوز.
يوصي دليل NVIDIA Container Toolkit حاليًا بتهيئة Docker باستخدام nvidia-ctk runtime configure --runtime=docker ثم إعادة تشغيل Docker. وهذا سياق مهم: لا ينبغي اعتبار إعادة تسمية ملف تجاوز من موضوع قديم في المجتمع الطريقة الحديثة الشاملة لتهيئة وقت تشغيل NVIDIA أو إزالته.
تحقق من المساحة الحرة قبل تعديل ملفات النظام
حاول مستخدم لاحق إعادة تسمية التجاوز، فتلقى الرسالة No space left on device. وهذا سبب جذري مختلف يجب حله أولًا. توفّر تغييرات ZimaOS 1.5 سياقًا لإصدارات تغييرات ZimaOS، بينما يكون سير عمل استكشاف أخطاء ZimaOS وإصلاحها مفيدًا عند ظهور عطل أوسع على مستوى المضيف بعد التحديث.
ترتيب تشخيصي أكثر أمانًا
- تحقق مما إذا كان Docker نشطًا، وافحص سجلاته الأخيرة.
- تأكد من أن قرص النظام غير ممتلئ.
- تحقق من سياسات إعادة تشغيل الحاويات فقط بعد التأكد من سلامة العفريت.
- إذا أشارت السجلات إلى تحميل وقت تشغيل NVIDIA، فافحص إعداد وقت التشغيل الحالي قبل تغييره.
- انسخ أي تجاوز مخصص في systemd احتياطيًا قبل تعديله.
الخلاصة
لا يثبت الموضوع الأصلي أن كل مشكلة تشغيل تلقائي في ZimaOS 1.4.3 كانت لها الأسباب نفسها. ففي أحد الأنظمة، منع تجاوز لوقت تشغيل NVIDIA في Docker العفريت من بدء التشغيل بصورة طبيعية؛ وفي نظام آخر، كشف الإصلاح المقترح امتلاء قرص النظام. شخّص حالة عفريت Docker والتخزين قبل تطبيق حل التجاوز التاريخي.
