بعد ترقية Discourse مثيلي Ubuntu الخاص بي ميت

الدعم
1

بعد استخدام مثيلات AWS EC2 Linux/Ubuntu بنجاح لسنوات، واجهت اليوم مشكلة لم أستطع حلها:

لقد قمت بترقية Discourse عبر عنوان URL /admin/upgrade. بدا أن العملية قد اكتملت بنجاح.

لسوء الحظ، بعد ذلك، تعطلت الخادم تمامًا.

لا يوجد وصول عبر HTTP، ولا وصول عبر SSH.

لقد جربت بالفعل إيقاف تشغيل الجهاز وتشغيله مرة أخرى عبر واجهة AWS EC2 الرسومية على الويب، لكن دون جدوى.

حاليًا، من المستحيل الاتصال عبر SSH بالجهاز، سواء باستخدام Putty أو عبر نافذة طرفية الاتصال المستندة إلى الويب في AWS EC2.

أنا في حيرة من أمري وقد انتظرت بالفعل عدة ساعات.

يُظهر أيضًا مراقبة EC2 أن الحمل على الخادم ليس مرتفعًا:

image
image1348×1272 85.7 KB

عندما حدث هذا في الأسابيع/الأشهر الماضية (حوالي مرتين أو ثلاث مرات في المجموع)، كان إعادة تشغيل الجهاز عبر واجهة EC2 الرسومية تجعل الجهاز يعمل مجددًا، لكن هذه المرة لم يحدث ذلك.

سؤالي

هل لديكم أي إرشادات حول كيفية جعل الجهاز قابلاً للوصول عبر SSH مرة أخرى؟

(أعلم أن هذه المشكلة على الأرجح ليست متعلقة بـ Discourse، ولكن نظرًا لأنها حدثت مباشرة بعد ترقية Discourse، ربما واجه مستخدمون آخرون نفس السلوك ولديهم بعض النصائح لي)

2

قد ترغب في التحقق من استخدام مساحة القرص.

تحدث العديد من الأعراض التي تصفها عندما يكون نظام الملفات ممتلئًا.

أتمنى أن يكون ذلك مفيدًا.

3

شكرًا لك.

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

4

يجب أن تتمكن من التحقق من ذلك عبر لوحة تحكم EC2 أو لوحة الإدارة الخاصة بك؛ لكنني لست مستخدمًا لـ AWS، وبالتالي لا يمكنني المساعدة بشكل أكبر.

5

بعد إعادة تشغيل أخرى وانتظار بعض الوقت، عاد النظام مرة أخرى، من العدم مرة أخرى.

بالنسبة لي، يبدو أن القرص يحتوي على مساحة فارغة كافية.

نظام الملفات      الحجم  المستخدم  المتاح النسبة% مرفوع على
udev            2.0G     0  2.0G   0% /dev
tmpfs           394M  876K  393M   1% /run
/dev/xvda1       97G   31G   67G  31% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/loop1       18M   18M     0 100% /snap/amazon-ssm-agent/1566
/dev/loop0       98M   98M     0 100% /snap/core/10185
/dev/loop2       29M   29M     0 100% /snap/amazon-ssm-agent/2012
/dev/loop3       98M   98M     0 100% /snap/core/10126
overlay          97G   31G   67G  31% /var/lib/docker/overlay2/5a799ab040002ad2ddec94ae85bcbe987543651a0d9478ddc12ab12715da7340/merged
tmpfs           394M     0  394M   0% /run/user/1000
6

أخبار رائعة @uwe_keim

إلى الأمام وإلى الأعلى!

7

لأي شخص مهتم، تابعت سؤالي هنا:

من المحتمل أن تظهر المزيد من التفاصيل خلال الساعات/الأيام القادمة هناك.