احتوى النقاش على أكثر من مشكلة واحدة في بدء تشغيل التطبيقات
بعد الترقية من ZimaOS 1.4.1 إلى 1.4.2، وجد صاحب المنشور الأصلي أن بعض التطبيقات، بما فيها Portainer، لم تبدُ وكأنها تبدأ تلقائيًا. سياسات إعادة تشغيل Docker مثل ما لم يتم إيقافه يدويًا ودائمًا دائمًا لم يغيّر النتيجة الظاهرة، بينما أدى النقر على التطبيق في لوحة المعلومات إلى تشغيله.
ثم أبلغ مستخدمون آخرون عن أعراض ذات صلة لكنها مختلفة. وجد أحد الفرق أن الحاويات كان يمكن الوصول إليها بالفعل عبر عناوين الويب المباشرة، بينما تصرفت لوحة معلومات ZimaOS كما لو كانت متوقفة. وأكد مستخدم آخر لاحقًا أن حاويات محددة تعطلت فعلًا لأن مسارات وحدات التخزين المدعومة عبر SMB لم تكن موصّلة عند بدء تشغيل التطبيق.
الحالة الأولى: عملت الحاوية، لكن تعذّر على لوحة المعلومات فتحها
وثّق أحد المستخدمين تسلسلًا من أربع خطوات. عرضت لوحة المعلومات التطبيق أولًا على أنه متوقف، ثم حذّرت من احتمال عدم توفره. أدى اتباع الرابط المقترح إلى فتح نافذة متصفح جديدة عمل فيها التطبيق بشكل طبيعي. كما نجح لصق العنوان والمنفذ نفسيهما مباشرةً في المتصفح.
تعامل فريق IceWhale مع هذا السلوك باعتباره جزءًا من التحقيق. ولا يثبت النقاش أن تغيير سياسة إعادة تشغيل Docker يحل مشكلة حالة لوحة المعلومات هذه.
الحالة الثانية: فشل تحديث التطبيقات والإعدادات لدى مستخدم واحد
أبلغ مشارك آخر كان يشغّل الإصدار 1.4.3 عن أخطاء موجزة أثناء تحديث Radarr وSonarr، وقال إن تغييرات الإعدادات لم تُطبَّق. ولم تُجدِ إعادة تثبيت التطبيقات نفعًا في تلك البيئة. ثم ذكر المشارك لاحقًا أن تغيير مرايا السجل أتاح تطبيق تغييرات الإعدادات مجددًا، كما أعاد بشكل منفصل تعيين ملكية مجلدات التطبيقات ذات الصلة لتطابق معرّف المستخدم 1000 المُعدّ.
كانت هذه تغييرات أبلغ عنها المستخدمون، وليست حلًا شاملًا لكل حالات فشل إعادة التشغيل. وقد يؤثر تعديل إعدادات عفريت Docker أو تغيير الملكية تكراريًا في المضيف بأكمله، لذلك لا ينبغي تعميم أدلة الموضوع خارج بيئة المشارك.
الحالة الثالثة: لم يكن تخزين SMB جاهزًا عند بدء الحاويات
حدّد صاحب المنشور الأصلي لاحقًا سببًا ملموسًا لثلاث حاويات. فقد كانت وحدات التخزين الخاصة بها مرتبطة بمشاركة SMB. وأظهرت السجلات أن الحاويات حاولت البدء قبل أن يصبح نظام ملفات SMB متاحًا، ففشلت وظلت متوقفة. وقد نجح تشغيلها يدويًا لاحقًا لأن المشاركة كانت قد تم تركيبها بحلول ذلك الوقت.
وهذا يفسر سبب تغيير دائمًا إلى ما لم يتم إيقافه يدويًا لم يساعد تلك الحاويات: فلا يمكن لسياسة إعادة التشغيل أن تجعل مسار نقطة ربط غير متاح جاهزًا في وقت أبكر. وكان الاعتماد المعني هو جاهزية التخزين وترتيب بدء التشغيل.
ما الذي أكده الإصدار 1.4.3 وما لم يؤكده
طلب أحد ممثلي IceWhale من المستخدمين اختبار الإصدار 1.4.3. وقال أحد المشاركين إن سلوك لوحة المعلومات ظل كما هو، بينما ظن صاحب المنشور الأصلي في البداية أن الإصدار 1.4.3 ساعد، لكنه أعاد لاحقًا إنتاج مشكلة ترتيب بدء التشغيل المرتبطة بـ SMB. وأشار رد آخر إلى ضرورة تشغيل التطبيق أولًا حتى تعرف خدمة إدارة التطبيقات آخر حالة تشغيل له.
لذلك لا يدعم الموضوع تصريحًا عامًا بأن الإصدار 1.4.3 أصلح كل مشكلات بدء التشغيل في الإصدار 1.4.2. بل يدعم تقسيمًا تشخيصيًا: تحقق أولًا مما إذا كانت الحاوية متوقفة فعلًا، ثم افحص سجلاتها وتبعيات التخزين.
الأسئلة الشائعة
لماذا يُفتح التطبيق عبر عنوان URL لكنه يبدو متوقفًا في ZimaOS؟
ظهر ذلك النمط على أنه مشكلة في تشغيل لوحة المعلومات أو الإبلاغ عن الحالة. فقد تكون الخدمة نفسها قيد التشغيل ويمكن الوصول إليها بالفعل عبر العنوان والمنفذ المُعدَّين لها.
لماذا تفشل الحاويات التي تستخدم مشاركة SMB فقط بعد إعادة التشغيل؟
في الحالة المؤكدة، بدأت تلك الحاويات قبل أن تصبح وصلة SMB جاهزة. وقد عملت عند تشغيلها يدويًا بعد ظهور المشاركة.
هل أدى تغيير سياسة إعادة تشغيل Docker إلى حل المشكلة؟
لا. اختبر صاحب المنشور الأصلي كليهما دائمًا ودائمًا ما لم يتم إيقافه يدويًا من دون إعادة تشغيل الحاويات المتأثرة.
