إن تشغيل عملية Jellyfin ليس دليلًا على أن الخدمة جاهزة. فقد يكون مستمع الويب موجودًا بينما يكون تركيب الوسائط مفقودًا، أو يتعذر على وكيل عكسي الوصول إلى الحاوية، أو يكون جهاز العتاد غير متاح، أو يكون DNS معطّلًا، أو يكون مسار مطلوب للقراءة فقط.
للاستعادة، ابحث عن أول تبعية تفشل قبل ظهور العَرَض الذي يراه المستخدم، بدلًا من إعادة تشغيل Jellyfin مرارًا. جمّد الحالة الحالية، وصنّف كل تبعية على أنها مطلوبة أو اختيارية، واختبرها من حدود تشغيل Jellyfin الفعلية، ثم أعد تشغيل الحزمة بدءًا من أدنى طبقة فاشلة وصولًا إلى الأعلى.
حدّد ما يحتاج إليه Jellyfin قبل اعتباره جاهزًا
أدرج تبعيات الإجراء الذي يفشل: مسارات الإعدادات وقاعدة البيانات الدائمة، وتركيبات الوسائط، ومساحة التخزين المؤقت والتحويل، وDNS المحلي، والوكيل العكسي أو النفق، وجهاز GPU، وأي إضافة أو خدمة خارجية يتطلبها سير العمل فعليًا. لا تضع كل موفّر بيانات وصفية اختياري في الفئة نفسها التي تضع فيها قاعدة بيانات التطبيق.
غالبًا ما يُخلط بين ترتيب بدء الحاويات والجاهزية. ينتظر نمط التبعية المقيّدة بفحص الصحة العملي حتى تصبح التبعية قابلة للاستخدام، لا حتى تبدأ فحسب. طبّق التمييز نفسه حتى عند تشغيل Jellyfin بشكل أصلي: فحالة العملية وجاهزية الخدمة تجيبان عن سؤالين مختلفين.
أنشئ شرط نجاح بسيطًا لكل تبعية إلزامية. ينجح التركيب عندما يظهر الملف المعروف المتوقع في المسار المتوقع؛ وينجح مسار الوكيل عندما يتمكن من الحصول على استجابة صالحة من الخدمة الخلفية؛ وينجح GPU عندما يتمكن Jellyfin من فتحه أثناء تحويل حقيقي؛ وتنجح الحالة الدائمة عندما تُحمّل المستخدمون والمكتبات دون تهيئة.
سجّل أول فشل قبل أن تخفيه سياسات إعادة التشغيل
سجّل وقت بدء Jellyfin، وحالة الصحة، وسجل خروج العملية، وسجلات المضيف والحاوية، وحالة التركيبات، وأخطاء نظام الملفات، وحل أسماء DNS، وأخطاء الوكيل. إذا كانت سياسة إعادة التشغيل تنشئ حلقة، فأوقف الحلقة مؤقتًا بما يكفي لالتقاط محاولة بدء واحدة واضحة.
الفشل الذي يظهر أولًا أهم من الخطأ الأعلى ضجيجًا الذي يظهر لاحقًا. فقد يتسبب تركيب مفقود في أخطاء المكتبة، وقد يتسبب مسار إعدادات للقراءة فقط في فشل قاعدة البيانات، وقد يجعل فشل DNS عدة إضافات تُصدر شكاوى في الوقت نفسه. ويمكن لإعادة تشغيل الخدمة الأساسية أن تضاعف هذه الرسائل الثانوية دون إصلاح الحدود الأصلية.
يوفّر سير عمل التبعية الأولى الفاشلة الحالي الانضباط نفسه في الترتيب عندما تجعل محاولات البدء المتكررة من الصعب رؤية الحدث الجذري.
اختبر كل تبعية مطلوبة من سياق تشغيل Jellyfin
لا تثبت التبعية من خلال صدفة المضيف فقط. إذا كان Jellyfin يعمل داخل حاوية، فتحقق من التركيب واسم DNS والمنفذ والأذونات والجهاز من داخل تلك الحاوية أو من حاوية تشخيص مكافئة متصلة بالشبكة نفسها وتعمل ضمن حدود الهوية نفسها.
يختبر فحص جاهزية الخدمة المفيد العملية التي يحتاج إليها العملاء فعليًا بدلًا من فحص سطحي للعملية. وبالنسبة إلى Jellyfin، قد يعني ذلك قراءة مسار الإعدادات، وسرد ملف وسائط معروف، وفتح المستمع المتوقع، وإكمال طلب API محلي واحد.
إذا كانت التبعية اختيارية، فاجعل فشلها يتدهور بسلاسة بدلًا من أن يحظر الخادم بأكمله. وإذا كانت إلزامية، فأصلحها أولًا وتحقق منها بشكل مستقل. لا توسّع الامتيازات أو تنتقل إلى استخدام شبكة المضيف لمجرد تعذر الوصول إلى تبعية واحدة؛ حدّد ما إذا كان الفشل متعلقًا بالمسار أو الأذونات أو حل الأسماء أو المنفذ أو الجاهزية.
أعِد التبعيات بالترتيب الذي يستهلكها به Jellyfin
أعد التخزين والحالة الدائمة قبل أن يكتب التطبيق فيهما، ثم شبكة الخدمات المحلية، ثم Jellyfin، ثم الوكيل العكسي أو الدخول عن بُعد، وأخيرًا التكاملات الخارجية الاختيارية. يعتمد الترتيب الدقيق على الحزمة، لكن القاعدة هي ألا يهيّئ المستهلك نفسه باستخدام بديل فارغ أو غير صحيح لتبعية مفقودة. توضّح أنماط Compose التي تجمع فحوصات الصحة مع سلوك إعادة التشغيل سبب وجوب أن تتبع إعادة التشغيل التلقائية الجاهزية القابلة للرصد، لا أن تحل محلها.
إذا تأخر تركيب الشبكة، فأوقف Jellyfin قبل فحص مجلد بديل فارغ. وإذا ظهر مسار الإعدادات المستعاد فارغًا، فتوقف قبل أن ينشئ معالج الإعداد حالة جديدة. وإذا كانت تسريعات الأجهزة مفقودة، فاحصر اختبار التشغيل على ملف مضبوط بدلًا من السماح لعدة عملاء بتشغيل تحويلات برمجية غير متوقعة.
عندما تكون خدمة واحدة فقط هي المالكة للحالة التالفة، يمكن أن يحافظ حد استعادة الخدمة الواحدة على التبعيات المشتركة السليمة بدلًا من استبدال الحزمة بأكملها بسبب فشل واحد.
أثبت الاستعادة بالإجراء الأصلي للمستخدم وبإعادة تشغيل تبعية واحدة
بعد أن تصبح الحزمة سليمة، كرّر الإجراء نفسه الذي فشل: تسجيل الدخول، أو تصفح المكتبة، أو التشغيل المباشر، أو التحويل الإجباري، أو الوصول عبر الوكيل البعيد، أو الفحص. ثم أعد تشغيل التبعية التي فشلت سابقًا عمدًا، وراقب ما إذا كان Jellyfin سيعيد المحاولة أو يتدهور أو يصبح غير متاح بالطريقة المتوقعة.
لا تُعد الخدمة مستعادة إلا عندما تعود التبعية الإلزامية إلى حالة معروفة، ويرى Jellyfin المسارات الدائمة الصحيحة، ولا يتم إنشاء حالة بديلة فارغة، ويستمر سلوك المستخدم الطبيعي خلال دورة إعادة تشغيل أخرى. إن ظهور حالة حاوية خضراء دون هذه الفحوصات لا يزال مجرد نتيجة على مستوى العملية.
وثّق التبعية، وشرط نجاحها، وترتيب بدء التشغيل، وسلوك الاستعادة، وشرط الإيقاف. وبذلك تتحول الحادثة التالية من مشكلة عامة من نوع «Jellyfin يعمل لكنه معطّل» إلى تبعية محددة ومسؤولة ذات اختبار جاهزية قابل للتكرار.
الدعم والنصائح
المزيد للقراءة

هل ينبغي لـ Jellyfin استخدام حساب مشترك واحد أم حسابات منزلية منفصلة؟
اختر حسابات منزلية لـ Jellyfin وفقًا لحدود الهوية والوصول والرقابة الأبوية والاسترداد التي تحتاجها.

لماذا يظل استخدام ذاكرة Jellyfin مرتفعًا بعد اكتمال العمل؟
افصل نمو عملية Jellyfin عن ذاكرة التخزين المؤقت في Linux، ولا تُجرِ تحقيقًا إلا عندما تستمر الذاكرة في الارتفاع أو تتسبب في ضغط فعلي.

علامات تحوّل تخطيط تخزين Jellyfin إلى خطر على الاسترداد
راجع أدوار تخزين Jellyfin، وافصل الحالة الحية عن النسخ الاحتياطية والبيانات القابلة لإعادة البناء، ثم أثبت صحة التخطيط بإجراء استعادة.

