إذا قمت بتشغيل rsync لـ /var/discourse بين قطرات في نفس مركز البيانات، يمكن أن يكون وقت التوقف عن العمل ضئيلًا جدًا، ويكون تراجعك مجرد إعادة توجيه DNS.
لا يحتاج الخادم الافتراضي الخاص الجديد إلا إلى Docker وربما مساحة تبديل.
إعجابَين (2)
مرحباً،
أواجه أيضاً هذه المشكلة عند تشغيل Red Hat Enterprise Linux 7، الذي يعمل بنواة 3.10.0. لا يعمل RHEL8 بشكل أحدث بكثير.
إعجاب واحد (1)
نفس الشيء هنا، 3.1.0.beta1 يعمل بشكل جيد على CentOS7 (3.10.0-1160.76.1.el7.x86_64)
من الواضح أن نواة التوزيع تحصل على الكثير من الإصلاحات الخلفية. كان التحقق من إصدار النواة الأصلي بهذه الطريقة يسبب مشاكل في مشاريع أخرى أيضًا. هل هناك طريقة لتجاوز هذا التحقق من سطر الأوامر؟
—تحديث—
لقد قمت بتحرير البرنامج النصي للمشغل لتجاوز التحقق - تم تحديث العديد من تثبيتات CentOS7 دون مشاكل.
5 إعجابات
هل سيتم تسليط المزيد من الضوء على هذه المشكلة؟ متطلبات النظام لا تتطلب أي إصدارات للنواة و CentOS 7/RHEL 7 ليست في نهاية عمرها الافتراضي بعد. Docker لا يتطلب نواة أحدث أيضًا. لا أعتقد أن تجاوز الفحص يدويًا هو الحل المناسب على المدى الطويل.
إعجابَين (2)
كنت على وشك ترقية منتدى قديم وحصلت على نفس الخطأ. لم يصل نظام Centos7 إلى نهاية عمره التشغيلي بعد، هل يمكنك إيجاد حل بديل لنظام Ubuntu 14.04؟
إذا كنت تعتقد أنك تستخدم أحدث نواة من مورد نظام التشغيل الخاص بك (مع إصلاحات مرتدة)، فقد ترغب في محاولة تجاوز الفحص. أعرف أنني سأفعل! هذه هي المشكلة التي تمت فيها إضافة الفحص. أعتقد أنه يمكنك فقط إزالة أو التعليق على أمر الخروج في البرنامج النصي ./launcher الخاص بك، في هذه الفقرة:
# على الأقل الحد الأدنى للإصدار
if compare_version "${kernel_min_version}" "${test}"; then
echo "خطأ: إصدار النواة ${test} غير مدعوم، يرجى الترقية إلى ${kernel_min_version} على الأقل"
exit 1
fi
إذا فشلت الترقية نتيجة لذلك، فستحتاج إلى إيجاد طريقة لتشغيل Discourse الخاص بك على نواة أحدث.
(من المحتمل جدًا أن يُنظر إلى هذه النصيحة على أنها غير مناسبة، ولكن أعتقد أن ما حدث هو أن لدينا فحصًا لرقم إصدار بدلاً من فحص لمنشأة (urandom)، وهذا النهج يمكن أن يعطي نتائج إيجابية خاطئة.)
4 إعجابات
أواجه هذه المشكلة الآن ومنتدانا معطل بسبب هذا. كيف يمكنني تعديل البرنامج النصي للمشغل والتعليق على فحص النواة (على الأقل حتى يحصل Centos7 على هذا التحديث أو نحاول نقل المنتدى إلى خادم آخر)؟
تحديث:
لقد نجحت (بالتجربة والخطأ) في تحديث المشغل وبدلاً من التعليق على النواة، وضعت إصدارًا أقل كشرط. لقد نجح الأمر بشكل جيد.
ربما هذا ليس حلاً جيدًا على المدى الطويل، لكن شركة الاستضافة لدينا أبلغتنا بالفعل أن Centos7 لن يحصل على إصدار النواة 4.4… هل يمكن لشخص ما شرح ما يعنيه هذا من الناحية العملية؟
إعجاب واحد (1)
يبدو أن Centos 7 سيحصل على تحديثات حتى منتصف عام 2024.
في مرحلة ما - ربما قبل نهاية العمر الافتراضي - سيحتاج Discourse المتطور باستمرار إلى شيء لا يمتلكه Centos 7، وستحتاج إلى ترقية نظام التشغيل الخاص بك (أو الانتقال إلى مثيل جديد بنسخة نظام تشغيل مناسبة). يبدو أن هذه النقطة لم يتم الوصول إليها بعد.
كما هو الحال دائمًا، قبل محاولة تحديث Discourse، سواء الآن أو في المستقبل، قم بعمل نسخة احتياطية من منتدياتك وخذ نسخة آمنة من تلك النسخة الاحتياطية، بالإضافة إلى نسخة آمنة من ملف app.yml الخاص بك.
إعجاب واحد (1)
ما هي النواة التي تعمل عليها والتي تعمل مع إعادة البناء التي قمت بها للتو؟
إذا كانت أقل من 4.4 وتعمل، فيبدو أن @falco قد يحتاج إلى تقليل الإصدار المطلوب مرة أخرى.
(نظرًا لأن التوزيعات ستحتوي على إصدارات خلفية للميزات والإصلاحات من النواة اللاحقة، فإن التحقق من إصدار النواة هو أداة فظة للغاية. أفهم فكرة تقليل عبء الدعم، ولكن هناك تأثير معاكس أيضًا عندما يكون فحص الأمان إيجابيًا خاطئًا. ومع تزايد شعبية Discourse، تتفاقم هذه المشكلة. من الأفضل بكثير التحقق من وجود ميزة بدلاً من التحقق من إصدار.)
إعجابَين (2)
نظامنا يعمل بما يلي:
- CentOS Linux release 7.9.2009 (Core)
- Kernel 3.10.0-1160.88.1.el7.x86_64
إعجاب واحد (1)
تحديث هذا:\nعلى الرغم من أن منتدانا يعمل الآن، إلا أننا نرى هذا الخطأ بشكل متزايد:
عفوًا
واجه البرنامج الذي يشغل منتدى المناقشة هذا مشكلة غير متوقعة. نعتذر عن الإزعاج.
تم تسجيل معلومات مفصلة حول الخطأ، وتم إنشاء إشعار تلقائي. سنلقي نظرة عليه.
لا يلزم اتخاذ أي إجراء آخر. ومع ذلك، إذا استمرت حالة الخطأ، يمكنك تقديم تفاصيل إضافية، بما في ذلك خطوات إعادة إنتاج الخطأ، عن طريق نشر موضوع مناقشة في فئة ملاحظات الموقع.
هل يمكن أن يكون هذا مرتبطًا بطريقة ما بمشكلة متطلبات الحد الأدنى للنواة؟ هذه “عدم الاستقرار” (دعنا نسميها بهذه الطريقة) أصبح ملحوظًا بشكل أكبر في الأيام/الأسابيع القليلة الماضية. يبدو أنه يأتي ويذهب، في بعض الأحيان يكون المنتدى على ما يرام، وفي بعض الأحيان لا يكون كذلك.
تحرير: لا تهتم، أعتقد أن هذا كان مرتبطًا بمشكلة postgresql (وجود عدد كبير جدًا من العمليات الجارية المرتبطة بالصور بدون حاوية، وهو ما حلته عملية تنظيف مشغل).
إعجاب واحد (1)
أنا أميل إلى الاتفاق مع هذا. هل تعتقد أن هذه فكرة جيدة @Falco؟
إعجاب واحد (1)
نعم، يتم الترحيب بطلبات السحب (PR) للكشف عنه بشكل صحيح.
إعجابَين (2)
مرحباً فالكو،
واجهت هذه المشكلة عند محاولة تحديث ديسكورس من 3.1.0.beta2 إلى 3.1.0.beta4
بدا هذا ترقية بسيطة ولكن بسبب فحص النواة، كان التحديث أكثر تعقيدًا على CentOS7. ربما في المرة القادمة يمكن لرقم إصدار مختلف أن يعكس بشكل أفضل التأثير العالي للتغييرات نسبيًا.
بالنظر إلى المناقشة، لا يمكنني حقًا معرفة أي فحص للميزة ضروري، ربما إذا كان بإمكانك توضيح ذلك، يمكن لشخص ما تقديم طلب سحب (PR).
إعجاب واحد (1)
إنه في المنشور بواسطة @Ed_S:
على Ruby 3.1 يوجد RuntimeException عند استدعاء
Random.urandomعلى المنصات حيث لم يتم تنفيذه بشكل صحيح، وهذا يشمل الأشخاص الذين يشغلون Ubuntu 14.04 بنواة 3.13.