قد يعمل تطبيق Jitsi Meet لفترة وجيزة ثم يُظهر خدمة أو أكثر على أنها "قيد إعادة التشغيل" في Docker Desktop أو في أي مكان آخر docker compose ps. عادةً ما يُطبّق Docker سياسة إعادة التشغيل المُكوّنة بعد انتهاء العملية. الحل الدائم هو تحديد الخدمة التي توقفت، وقراءة سجلاتها الأخيرة، وتصحيح خطأ بدء التشغيل. قد يؤدي إعادة تشغيل النظام بالكامل بشكل متكرر أو حذف وحدات التخزين الخاصة به إلى إخفاء الأدلة أو إزالة البيانات الدائمة.
شغّل برنامج Compose من المجلد الذي يحتوي على نفس ملف Compose .envالمستخدم لتشغيل هذا التثبيت. إذا كنت تستخدم عادةً ملفات Compose أو ملفات تعريف إضافية، --env-fileفقم بتضمين نفس الخيارات.
docker compose ps -aتحقق من كل خدمة على حدة. الخدمات الأساسية هي web: ، prosody، jicofo، و jvb؛ وقد تظهر خدمات اختيارية مثل jibriأو jigasi. لاحظ الخدمة التي حالتها هي Restartingأو Exited. تعطل خدمة واحدة لا يعني بالضرورة أن جميع الحاويات تعاني من نفس العطل.
اقرأ سجل الأحداث الخاص بتلك الخدمة، باستخدام الطوابع الزمنية:
docker compose logs --tail=150 --timestamps jicofoاستبدل jicofoالخدمة المتأثرة. أضفها -fلمراقبة محاولة بدء تشغيل أخرى. يوثق دليل Jitsi Docker سجلات Compose لخدماته. إذا لم يتمكن Docker من إرجاع السجلات، فتحقق مما إذا كان برنامج تشغيل التسجيل المُكوّن للحاوية يدعم قراءتها.
انتقل إلى أول خطأ واضح في كل دورة بدء تشغيل. قد تُشير الأسطر اللاحقة فقط إلى توقف العملية وأن Docker يُعيد تشغيلها. تشمل الأسباب الجذرية الشائعة ما يلي:
./gen-passwords.shالبرنامج النصي المرفق لملء القيم المطلوبة في ملف .env. احمِ هذا الملف ولا تنشر بياناته السرية في أي طلب دعم.توضح سياسة إعادة تشغيل Docker سبب عودة العملية بعد خروجها، لكنها لا توضح سبب خروجها. اعتبرها Restartingعرضًا وسجل الخدمة دليلًا.
تأكد من تعديل الملف الذي يقوم Compose بتحميله فعليًا. من الأخطاء الشائعة تغيير ملف .envبينما يقرأ Compose ملفًا آخر من دليل مختلف أو من ملف مُحدد صراحةً --env-file. تحقق من صحة الإعدادات قبل إعادة إنشاء الحاويات.
docker compose config --quietإذا أبلغ Compose عن خطأ، فقم بتصحيح ملف YAML، أو استبدال المتغيرات، أو الملف المرجعي المفقود، أو الخيار الذي يشير إليه. قد يساعد التشغيل docker compose configبدون تعديل --quietفي فحص النموذج المُحلَّل، ولكنه قد يُظهر كلمات مرور مُضافة. لا تُشارك المُخرَج غير المُنقَّح.
لتثبيت Jitsi القياسي، قارن .envمع env.exampleالإصدار نفسه وتأكد من وجود كلمات المرور الداخلية المطلوبة. إذا كنت تستخدم ملف Compose مخصصًا، فتأكد من وصول المتغيرات اللازمة إلى الخدمة الصحيحة. استخدم نص كلمة المرور المرفق بدلًا من العناصر النائبة الفارغة. عند تغيير كلمة المرور، حافظ على اتساق إعدادات المكون المطابق.
يُميّز مشروع Jitsi بين ملفات الإصدار العادية وشفرة التطوير والصور غير المستقرة. تجنّب دمج دليل Compose قديم، وعلامات صور عشوائية، وملفات من إصدار مختلف أثناء استكشاف الأخطاء وإصلاحها.
قارن إدخالات وحدة التخزين الخاصة بالخدمة مع مسارات المضيف الفعلية. CONFIGقد يؤدي خطأ إملائي أو قيمة غير متوقعة أو دليل عمل مختلف في Compose إلى استخدام النشر لدليل تكوين آخر.
تعتمد الأذونات على إصدار Jitsi. يشير الدليل إلى أنه بدءًا من الإصدار 10 stable-11146، تعمل الحاويات كمستخدم غير مميز بنظام ملفات للقراءة فقط. تُعد مجلدات التكوين مدخلات؛ أما البيانات القابلة للكتابة فتُفصل إلى storageمجلدات tmpفرعية، ويجب أن تكون قابلة للكتابة بواسطة UID/GID 1000. تستخدم الإصدارات الأقدم تخطيطًا مختلفًا. اتبع دليل الإصدار الذي تستخدمه بدلًا من إعادة استخدام وصفة أذونات لإصدار مختلف.
إذا كشف سجل النظام عن وجود دليل مفقود أو غير قابل للكتابة، فقم بإصلاح هذا المسار تحديدًا. تجنب تطبيق أوامر عامة، مثل تلك التي تُطبق chmod -R 777على دليل إعدادات Jitsi بأكمله؛ فقد يُضعف ذلك الأمان دون إصلاح المسار المُثبَّت.
يمكن لـ Docker الإبلاغ عن رمز خروج الحاوية، وحالة نفاد الذاكرة، وعدد مرات إعادة التشغيل، وخطأ البرنامج الخفي. أولاً، احصل على مُعرّف الحاوية للخدمة التي فشلت:
docker compose ps -q jicofoثم استبدل المعرّف المُعاد:
docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}} error={{.State.Error}}' CONTAINER_IDيؤكد ازدياد عدد مرات إعادة التشغيل تكرار المحاولات. في حال حدوث ذلك oom=true، تحقق من حدود ذاكرة المضيف أو الحاوية وسجلات النظام. لا يُعد رمز الخروج غير الصفري وحده تشخيصًا؛ قارنه بسجل الخدمة.
إذا بدأت الحلقة بعد التحديث، فدوّن التغييرات: ملفات الإصدار، أو علامات الصور، أو كلمة المرور، أو ربط المجلدات، أو الإعدادات المخصصة. قم بعمل نسخة احتياطية من الإعدادات والبيانات الدائمة قبل تغيير الإصدارات. استعد مجموعة متوافقة من ملفات وصور Compose أو اتبع تعليمات ترقية Jitsi. قد تمنع مشاكل الشبكة وجدار الحماية المستخدمين من الاتصال، ولكنها لا تفسر عادةً سبب توقف عملية الخدمة بشكل متكرر؛ لذا ميّز بين فشل بدء التشغيل ومشكلة اتصال الوسائط.
بعد تغيير قيمة بيئية أو تعريف Compose، أعد إنشاء الخدمة المتأثرة لتطبيق التكوين الجديد:
docker compose up -d --force-recreate jicofoاستبدل اسم الخدمة. إذا أثر تغيير في التكوين المشترك على عدة مكونات، فأعد إنشاء الخدمات ذات الصلة معًا. ثم راجع الحالة والسجلات مرة أخرى. لا يُطبَّق إعادة التشغيل العادية مع كل تغيير في Compose أو البيئة، بينما قد تؤدي إعادة إنشاء المجموعة بأكملها إلى مقاطعة الاجتماعات النشطة.
لا تستخدم docker compose down -vهذا الخيار كحلٍّ عامٍّ لحل مشكلة إعادة التشغيل المتكررة. -vفهو يُزيل وحدات التخزين المُدارة بواسطة Compose، وقد يؤدي إلى حذف بيانات كنت تنوي الاحتفاظ بها. لذا، احفظ السجلات وتحقق من نقاط التحميل قبل إزالة الحاويات أو البيانات.
تحقق من الحالة، وانتظر عدة فترات تشغيل عادية، ثم تحقق مرة أخرى:
docker compose ps
docker compose logs --tail=100 --timestamps jicofoيجب أن تبقى الخدمة المتأثرة قيد التشغيل، وأن يتوقف عدد مرات إعادة تشغيلها عن الزيادة، وأن لا يتكرر سجلها نفس الرسالة الحرج. تأكد من تحميل صفحة الويب، واختبر اجتماعًا مع عميلين. إذا استمرت الخدمات في العمل ولكن لم يتمكن المشاركون من تبادل الصوت أو الفيديو، فتحقق من إعدادات الشبكة، وقواعد جدار الحماية، وعنوان JVB المُعلن عنه في دليل Jitsi.
للحصول على معلومات مرجعية، استخدم دليل الاستضافة الذاتية لـ Jitsi Meet Docker ، ومثال متغير البيئة الخاص بالمشروع ، ووثائق سياسة إعادة تشغيل Docker ، ومرجع سجلات Compose الخاص به ، ومرجع فحص الحاوية .
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
