تخلص سلسلة المصدر هذه إلى استنتاج قوي خاص بالإصدار. فبعد ترقية ZimaBoard 832 إلى ZimaOS 1.4.3، فشل Docker في التشغيل تلقائيًا، وتعذّر على متجر التطبيقات تثبيت تطبيقات جديدة، كما تعذّر تشغيل التطبيقات الموجودة. وقال Zima-Giorgio إن الفريق كان على علم بمشكلة خدمة Docker، وقدّم أمرًا مؤقتًا لإعادة التشغيل يدويًا.
أكد صاحب المنشور الأصلي أن أمر إعادة التشغيل حلّ المشكلة الفورية، لكنه أفاد أيضًا بأن Docker كان يفشل مجددًا بعد كل إعادة تشغيل للمضيف. ويقدّم الإصدار التالي من IceWhale الحد الفاصل المفقود: فقد أصلح ZimaOS 1.4.4 رسميًا فشل بدء تشغيل Docker الناجم عن قِصر الفاصل الزمني لبدء تشغيل الخدمة.
ظهرت المشكلة مباشرة بعد الترقية إلى الإصدار 1.4.3
أفاد المستخدم في المصدر بما يلي:
- تجمّد تحديث Prowlarr؛
- تعذّر تشغيل التطبيقات الموجودة؛
- فشلت عمليات تثبيت التطبيقات الجديدة؛
- وأبلغت الواجهة عن تعذّر الاتصال بعفريت Docker.
/var/run/docker.sock، مما أدى إلى منع تثبيت التطبيقات وتشغيلها.وصفت IceWhale المشكلة بأنها معروفة في خدمة Docker
في 26 أغسطس، كتب Zima-Giorgio أن الفريق اعتبرها مشكلة معروفة في خدمة Docker، وقال إن إصلاحًا سيُطرح.
وقدّم الحل الرسمي المؤقت التالي:
sudo -i
systemctl restart docker docker.socketهذا الأمر يمثل إرشادًا تاريخيًا صالحًا من IceWhale لحالة المصدر في الإصدار 1.4.3.
أكد صاحب المنشور الأصلي نجاح إعادة تشغيل Docker يدويًا
أفاد المستخدم بأن إعادة تشغيل Docker بصلاحيات الجذر عبر واجهة سطر الأوامر حلّت المشكلة الفورية تمامًا. وهذا نجاح مؤكد من المصدر، وليس حلاً تجريبيًا.
ومع ذلك، أعاد المستخدم نفسه تشغيل ZimaBoard لاحقًا، فوجد أن Docker فشل مرة أخرى في التشغيل تلقائيًا.
كان من الممكن أن تعرض لوحة المعلومات التطبيقات على أنها قيد التشغيل عندما لم يكن Docker يعمل بشكل سليم
إعادة تشغيل Docker أعادت حالة التطبيق الفعلية
إعادة تشغيل التطبيق يدويًا لم تعالج عملية الإقلاع التالية بشكل موثوق.
ذكر Zima-Giorgio أن بعض البلاغات أشارت إلى أن بدء كل تطبيق وإعادة تشغيله يدويًا قد يساعد في عمليات إعادة التشغيل المستقبلية. اختبر صاحب المنشور الأصلي الفكرة، لكنه ظل يرى الحالة نفسها التي تشير إلى بدء تشغيل زائف بعد إعادة التشغيل.
لذلك من المهم عدم تقديم إعادة تشغيل كل تطبيق على حدة باعتبارها الإصلاح النهائي للمصدر.
أصلح ZimaOS 1.4.4 مشكلة توقيت بدء تشغيل Docker
تتضمن ملاحظات إصدار IceWhale الرسمية للإصدار 1.4.4 ما يلي:
- إصلاح لبقاء التطبيقات في حالة التحميل بعد بدء التشغيل؛
- إصلاح لعدم كفاية الفاصل الزمني لبدء تشغيل خدمة Docker، مما كان يتسبب في فشل بدء التشغيل؛
- إصلاحات إضافية لحالة التطبيقات وبطاقات التثبيت.
راجع إصلاحات بدء تشغيل Docker في ZimaOS 1.4.4 لمعرفة الحل التاريخي على مستوى المنتج.
لا ينبغي للمستخدمين الحاليين اعتبار systemctl restart حلًا دائمًا
في إصدار حديث من ZimaOS، يشير فشل برنامج Docker الخفي بشكل متكرر بعد إعادة التشغيل إلى وجود مشكلة حالية في الخدمة أو التخزين أو وقت التشغيل أو الإعدادات. قد تكون إعادة تشغيل Docker إجراءً تشخيصيًا، لكن اجمع سبب الفشل الحقيقي قبل اعتماد إعادة التشغيل اليدوية عند كل إقلاع.
تشمل الأدلة الحالية المفيدة ما يلي:
-
systemctl status docker.service; -
journalctl -u docker.service; - المساحة الخالية على قرص النظام؛
- تجاوزات إعدادات GPU/وقت التشغيل الأخيرة أو تعديلات المضيف؛
- إصدار ZimaOS الحالي بالتحديد.
قد يكون للعرض المماثل سبب جذري مختلف
أفادت مناقشة أخرى حول الإصدار 1.4.3 بفشل Docker بسبب بقاء تجاوز إعدادات مخصص لوقت تشغيل NVIDIA في تكوين systemd. وهذا سبب مختلف عن مشكلة توقيت بدء التشغيل في سلسلة المناقشة الأصلية.
لا تحذف ملفات تجاوز إعدادات الخدمة ما لم تُظهر السجلات أن تجاوز إعدادات محددًا يتسبب فعلًا في تعطل البرنامج الخفي.
الأسئلة الشائعة حول Docker Daemon 1.4.3
هل وفّرت IceWhale رسميًا طريقة لإعادة تشغيل Docker يدويًا؟
نعم. نشر Zima-Giorgio systemctl restart docker docker.socket كحل مؤقت في الإصدار 1.4.3.
هل أكد المستخدم الأصلي نجاح ذلك؟
نعم، بالنسبة إلى عملية الإقلاع الحالية. عاد الفشل بعد إعادة التشغيل.
أي إصدار وثّق إصلاح بدء التشغيل على مستوى المنتج؟
عالج ZimaOS 1.4.4 مشكلة قِصر مهلة بدء تشغيل خدمة Docker، التي كان من الممكن أن تتسبب في فشل بدء التشغيل.
