أواجه نفس المشكلة… لدي Droplet يعمل بنظام Ubuntu 20.04. حاولت ترقية Docker من داخل Discourse أولاً ولكنه استمر في إعطاء رمز خطأ 137. لذلك حاولت إعادة بناء Discourse من سطر الأوامر وتوقف عند The database is ready to accept connections. لم يكن Ctrl+C يفعل شيئًا، لذا أغلقت SSH وفتحت واحدة جديدة وبدأت Discourse مرة أخرى وكانت لا تزال تعمل ولكن لم يتم تحديثها. أعدت تشغيل الـ Droplet وحاولت ترقية Docker مرة أخرى من Discourse وهذه المرة نجحت! لذلك حاولت إعادة بناء Discourse مرة أخرى ولكنها لا تزال متوقفة في نفس المكان. أغلقت SSH مرة أخرى وفتحت وبدأت Discourse مرة أخرى ولكن الآن أحصل على شاشة Oops! لذا الآن موقع Discourse الخاص بي معطل والطريقة الوحيدة التي تمكنت بها من التعافي من شاشة Oops سابقًا هي إعادة بناء التطبيق وهو ما لا أستطيع فعله!
لذا أنا الآن في حيرة من أمري لأن خبرتي في Discourse و Droplet محدودة ولا أعرف ما يمكنني فعله الآن. docker_manager هو المكون الإضافي الوحيد المستخدم في ملف app.yml الخاص بي، لذا يمكنني فقط افتراض أن الخطأ ناتج عن كون Docker إصدارًا أحدث ولا يتوافق مع إصدار Discourse الخاص بي؟ لا أعرف. آخر مرة قمت فيها بتحديث Discourse كانت في يناير، لذا فهو ليس قديمًا جدًا…
لذا فإن موقعي معطل حتى يتم حل هذه المشكلة… إلا إذا قمت بتشغيل Droplet جديد وإعادة إعداد كل شيء مرة أخرى واستعادة نسخة Discourse الاحتياطية التي قمت بها؟ هل هذا هو خياري الوحيد في هذه المرحلة؟
الخطأ 137 يعني نفاد الذاكرة. سأحاول إضافة المزيد من الذاكرة المتبادلة (swap). إذا كان لديك 1 جيجابايت فقط من ذاكرة الوصول العشوائي (RAM)، فقد أقوم بتغيير حجمها إلى 2 جيجابايت وربما يكون لديك أيضًا 3 أو 4 جيجابايت من الذاكرة المتبادلة.
قد تحاول تشغيل:
./launcher start app
لكنني أشك في أن قاعدة البيانات قد انتقلت بعيدًا جدًا بالنسبة للحاوية القديمة.
مرحباً، نفس الخطأ هنا. الحل البديل حاليًا هو فرض معلمة الإصدار في app.yml إلى v3.3.0. Arch AMD64، Ubuntu 18.04. من الغريب أن إصدارًا فرعيًا فشل، وتم التحديث إلى v3.3.0 دون مشكلة الأسبوع الماضي
لكل من يواجه هذه المشكلة ويرغب في منحي إمكانية الوصول إلى خادمه، يرجى إرسال رسالة خاصة لي حتى أتمكن من تصحيح المشكلة على خادم يعاني منها. لقد جربت طرقًا متعددة ولم أتمكن من تكرار هذه المشكلة، مما يجعل من الصعب دفع إصلاح.
لكل من يعاني من هذه المشكلة مع تعطل Discourse، وجدت أنه يمكنك على الأقل تشغيل الإصدار القديم للمنتدى عن طريق إعادة تشغيل الجهاز الافتراضي ثم تشغيل ./launcher start app. لن يعمل هذا الأمر بعد محاولة إعادة البناء دون إعادة تشغيل المثيل / الجهاز الافتراضي الخاص بك.
سأتمكن من ترقية إصدار Ubuntu على الجهاز الافتراضي المتأثر لدينا يوم الاثنين، لذا سأبقي الجميع على اطلاع بالنتائج.
**/var/discourse**# ./launcher start app
تم اكتشاف بنية x86_64.
تحذير: ملف containers/app.yml قابل للقراءة من قبل الجميع. يمكنك تأمين هذا الملف عن طريق تشغيل: chmod o-rwx containers/app.yml
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=techoforum.com -e DISCOURSE_DEVELOPER_EMAILS=techoforumd@gmail.com -e DISCOURSE_SMTP_ADDRESS=smtp.sendgrid.net -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=apikey -e DISCOURSE_SMTP_PASSWORD=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 -e DISCOURSE_SMTP_DOMAIN=gmail.com -e DISCOURSE_NOTIFICATION_EMAIL=techoforumd@gmail.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h discourseonubuntu2004-s-1vcpu-1gb-sfo3-01-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f8:99:7d:c3:d6 local_discourse/app /sbin/boot
تعذر العثور على الصورة 'local_discourse/app:latest' محليًا
docker: استجابة خطأ من الخادم: فشل الوصول إلى الصورة 'local_discourse/app'، المستودع غير موجود أو قد يتطلب 'docker login': تم رفض الوصول: تم رفض الوصول إلى المورد.
راجع 'docker run --help'.
هذا يبدو وكأنه مشكلة في ذاكرة الوصول العشوائي (RAM). كم لديك من ذاكرة الوصول العشوائي ومساحة التبديل (swap)؟ أود إضافة جيجابايت أو اثنين من مساحة التبديل (وربما إضافة ذاكرة وصول عشوائي إذا كان لديك 1 جيجابايت فقط)
كم لديك من ذاكرة الوصول العشوائي ومساحة التبديل على تلك الأنظمة؟ ما هو ناتج الأمر
free -h
وذاكرة الوصول العشوائي ستفسر سبب عدم قدرة @tgxworld على تكرار المشكلة.
أنا متأكد تمامًا من أن ذاكرة الوصول العشوائي/التبديل هي المشكلة.
بالمناسبة، لأي شخص يواجه هذه المشكلة، يمكنك التحايل عليها في الوقت الحالي عن طريق إضافة base_image: discourse/base:2.0.20240708-0023 إلى أعلى ملف containers/app.yml.
قاعدة البيانات على خادمنا الإنتاجي كبيرة جدًا، لكن بيئة التطوير صغيرة جدًا. هذا هو الاختلاف الحقيقي الوحيد بين الأجهزة الافتراضية التي تمت ترقيتها بنجاح وتلك المتأثرة (في حالتي).
يا إلهي! لماذا لم أقرأ هذا الحل من قبل. لقد نجح معي أيضًا.
إذًا ما هو الحل للمضي قدمًا؟ هل نحتاج إلى الاستمرار في تحديد هذه الصورة الأساسية في المستقبل أيضًا أو تغييرها للحصول على صورة محدثة؟
