المساعدة في الاستعادة - تعطل النظام عند منتصف الليل

إعادة خبز جميع المشاركات المطابقة لنمط معين

إعجاب واحد (1)

للأسف لم ينجح ذلك، ولم يتغير عنوان URL بعد إعادة بناء HTML ولا يزال يؤدي إلى صفحة\n\u003e عفوًا! هذه الصفحة غير موجودة أو خاصة.\n\n\nأي أفكار أو اقتراحات أخرى؟

هل نجحت إعادة البناء من تجربة المستخدم أم لا؟

لم ينجح النقر على زر “إعادة بناء HTML”. لم يتغير الرابط ولا يزال يؤدي إلى صفحة الخطأ.

هناك مشكلة ثانية لاحظتها بعد الاستعادة. ألقيت نظرة على سجلات الأخطاء ولاحظت هذا. الرابط ليس هو نفسه الموجود في المنشور الذي أعدت بناءه:
فشل في معالجة الاستجابة المختطفة بشكل صحيح : Errno::ENOENT : لا يوجد ملف أو دليل @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico

الشيء الغريب هو أنه عندما أضع عنوان URL أعلاه في المتصفح، فإنه يقدم الأيقونة بالفعل.

إليك تتبع المكدس

رسالة (تم الإبلاغ عن 5 نسخ)

فشل في معالجة الاستجابة المختطفة بشكل صحيح : Errno::ENOENT : لا يوجد ملف أو دليل @ rb_sysopen - /XXXXX.s3.dualstack.us-east-1.amazonaws.com/optimized/1X/46728e07f9819907d1b18387bf02ea7fc25c7981_2_32x32.ico

تتبع المكدس

/var/www/discourse/app/controllers/static_controller.rb:160:in read' /var/www/discourse/app/controllers/static_controller.rb:160:in block (2 levels) in favicon’
/var/www/discourse/lib/distributed_memoizer.rb:16:in block in memoize' /var/www/discourse/lib/distributed_mutex.rb:33:in block in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:29:in synchronize' /var/www/discourse/lib/distributed_mutex.rb:29:in synchronize’
/var/www/discourse/lib/distributed_mutex.rb:14:in synchronize' /var/www/discourse/lib/distributed_memoizer.rb:12:in memoize’
/var/www/discourse/app/controllers/static_controller.rb:138:in block in favicon' /var/www/discourse/lib/hijack.rb:56:in instance_eval’

إذًا لم تكن بحاجة إلى معرفة كيفية إعادة البناء من سطر الأوامر.

لست متأكدًا، ولكن يبدو أنه يعامل ذلك كاسم ملف بدلاً من دلو، ولكن سأحتاج إلى النظر في المصدر لمعرفة ذلك على وجه اليقين.

أي أفكار/آراء أخرى حول كيفية إصلاح الروابط المعطلة /short-url؟

حدث هذا لي أيضًا، على خادم Oracle Cloud. أصيبت النواة بالذعر، وكذلك أنا. اعتقدت أنني انتهيت. ولكن بعد حوالي ست أو ثماني عمليات إعادة تشغيل من وحدة تحكم السحابة، بعضها كان عمليات إعادة تشغيل “اسحب القابس”، وبعد حوالي نصف ساعة من الانتظار، تم تشغيل الخادم لفترة كافية لي لتعديل grub.cfg والعودة إلى النواة السابقة.

تمكنت من إنقاذ مثيلي بذلك. بعد يوم، تم تقديم تحديث نواة جديد آخر، وعندها أصبحت أكثر يقينًا بأن نظريتي حول مشكلة النواة كانت صحيحة. ووجدت وصف الخطأ لتأكيد ذلك. نعم، سيء جدًا.

ابتكرت خدعة Grub غبية، كما أسميها، سأحاول إيجاد وقت لنشرها قريبًا، حتى يتمكن المرء من تجنب مثل هذه الكارثة في المستقبل.

حظًا موفقًا في استعادتك، @RBoy. يجب أن أقول إن هذا الموضوع يسبب لي اضطرابًا في المعدة بعد كارثتي الوشيكة الخاصة في الأسبوع الماضي - متى كان ذلك، الأربعاء؟

بالمناسبة، قلت إنك استعدت الوصول إلى خادمك القديم. إذا كنت لا تزال تحتفظ به أو يمكنك الوصول إليه مرة أخرى - بالنسبة لي استغرق الأمر بعض عمليات إعادة التشغيل الصعبة وبعض الانتظار - حسنًا، ادخل وقم بالترقية مرة أخرى، حيث توجد نواة جديدة أخرى لا تحتوي على الخطأ. أو ارجع إلى النواة السابقة.

إعجاب واحد (1)