تعطل آخر في Discourse: "bootstrap failed with exit code 5"

أهلاً بالمجتمع! يؤسفني أن نلتقي في هذه الظروف. ديسكورس غير متصل بالإنترنت بعد ترقية فاشلة.

نفس القصة كما في:

Discourse offline after failed upgrade "bootstrap failed with exit code 5"

تمت محاولة الترقية إلى v3.2.0.beta3

ما زلت على Ubuntu 16.04.

لحسن الحظ، لدي صور Docker السابقة (آمل ذلك)، لكنني لست متأكدًا مما يجب فعله لاستعادة الخدمات. أستخدم أيضًا DigitalOcean.

خطأ

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle install --retry 3 --jobs 4' failed with return #<Process::Status: pid 448 exit 5>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle config --local deployment true'", "su discourse -c 'bundle config --local without \\\"development test\\\"'", "su discourse -c 'bundle install --retry 3 --jobs 4'"]}
bootstrap failed with exit code 5
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
e9fead51a802981ae53f85f54dc8bf7bf9fae5c1dab3e06e0d77ea0930ffb261

هل يمكن لأحد المساعدة؟

بينما لدي الصور القديمة، لقد قمت بإزالة أحدث صورة…

docker rmi 51421f454322 -f

لدي الحاويات القديمة، ولكن عندما أحاول تشغيل ./launcher start app، يبدو أنه يفضل تلك الصورة المحذوفة.

root@hostname:/var/discourse# ./launcher start app
WARNING: Docker version 17.05.0-ce deprecated, recommend upgrade to 17.06.2 or newer.
x86_64 arch detected.
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml

starting up existing container
+ /usr/bin/docker start app
app

root@hostname:/var/discourse# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                                      NAMES
afeec2777503        51421f454322        \"/sbin/boot\"        3 hours ago         Up 5 seconds        0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app
root@hostname:/var/discourse# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
discourse/base      2.0.20231218-0429   984f729957df        12 days ago         3.14GB

هل هناك طريقة للمتابعة بمعرف الصورة 984f729957df؟

الشيء الأسهل هو المتابعة وتشغيل قطرة جديدة ونسخ /var/discourse إليها وإعادة البناء هناك. هذا سيحل المشكلة بدلاً من تخفيفها.

هناك أمر مشغل يمنحك أمر docker الذي قد يساعد. يمكنك البحث في البرنامج النصي للمشغل للعثور على اسمه (لكنني على هاتفي).

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

يبدو أنك تقترح: ./launcher start-cmd app

إنه يُخرج الكثير، بدءًا بـ + true run --shm-size=512m -d --restart=always...

بمحاولة جريئة، جربت:
docker + true run 984f729957df --shm-size=512m -d --restart=always ... دون جدوى.

container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH"
docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"--shm-size=512m\": executable file not found in $PATH".

نرحب بأي مساعدة يمكنك تقديمها. شكرا لك.

نعم. شيء من هذا القبيل. لا أعرف كيف أفعل ذلك. ربما تكون قد حذفت الصورة الوحيدة القابلة للاستخدام.

توصيتي لا تزال هي تشغيل قطرة جديدة ونسخ الأشياء. إذا كنت أحد عملائي، فهذا ما سأفعله.

شكراً على الاقتراح. لست من محبي عمليات الترحيل غير المخطط لها، ولكن يبدو أن هذا هو المخطط له. سأفترض أنك تشير إلى هذا؟ Move a Discourse site to another VPS with rsync

هل ستكون هناك أي تعليمات إضافية إذا قمنا بتمكين DO Spaces (تخزين S3)؟

بالنظر إلى الوقت من العام، سيكون من الصعب للغاية (اقرأ: ربما مستحيل) تنسيق الآخرين للتغييرات اللازمة في الوقت المناسب.

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

هل يمكن لأحد المساعدة؟

لا إذا اتبعت تكوين موفر تخزين كائنات متوافق مع S3 لتحميلات. إذا كانت لديك الإعدادات في قاعدة البيانات، فقد يكون الأمر أكثر تعقيدًا إذا حاولت استعادة بدلاً من rsync.

الانتقال إلى قطرة جديدة منخفض المخاطر نظرًا لأنه يمكنك فقط تغيير نظام أسماء النطاقات (DNS) مرة أخرى إلى موقعك المعطل، ولكن إذا لم يكن لديك وصول إلى نظام أسماء النطاقات (DNS) و Digital Ocean، فأنت عالق.

يبدو أنك ربما فاتك اقتباس شيء ما مع أمر البدء. يبدو أن هذا قد يكون ما تريد القيام به.

حظا سعيدا

تكوين موفر تخزين كائنات متوافق مع S3 لتحميل الملفات

لقد قمت بتكوين هذه الخدمة في عام 2016، لذا للأسف يبدو أن لدينا الإعدادات في قاعدة بيانات؟ لا توجد معلمات S3 في app.yml

هل هناك أي مشاكل أخرى يجب أن أكون على علم بها؟

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

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

شكراً لك مرة أخرى على مساعدتك. أما بالنسبة لـ rsync، فأنا قلق بعض الشيء بشأن كيفية ذكر التعليمات بوضوح:

  1. إعداد الخادم الجديد والمزامنة
  2. إيقاف الخدمة على الخادم القديم
  3. المزامنة مرة أخرى ولكن مع --delete

هذا يبدو متقلبًا، وغير ممكن أيضًا في السيناريو الخاص بي. هل سيكون ذلك مصدر قلق؟ أعتقد أن الأمر يتعلق فقط بالتأكد من مزامنة أي شيء حدث منذ آخر مزامنة لـ rsync للمنتدى، ولكن ربما أكون مخطئًا.

تحديث:
لقد عدنا للعمل مع Droplet جديد تمامًا.

يسعدني أن أعرف الآن أن الترحيل سهل نسبيًا. كان سيكون أفضل بكثير لو لم يؤدِ التحديث إلى تعطيل الـ droplet القديم.

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

إعجابَين (2)