هذه أول مشاركة لي هنا، شكرًا مقدّمًا لاستقبالي. أقوم بتشغيل مجموعة روتينية (وإن كانت متأخرة) من التحديثات على منتدى يعمل بنظام Discourse ( https://forum.troygrady.com )، وقد وصلنا إلى نقطة يفشل فيها التحديث بعد تنفيذ خطوات “git pull” و"rebuild" من سطر الأوامر كما أوصت التعليمات الظاهرة على الشاشة.
انظر أدناه لمخرجات أمر “./launcher rebuild app”. كما قمت بتشغيل سكريبت “discourse doctor”، ويمكنني نشر أو إرسال رابط لمخرجاته أيضًا، بشرط ألا يُشكّل ذلك خطرًا أمنيًا كبيرًا.
يجب أن أذكر أنه بينما أعتبر مطور PHP/SQL كفؤًا نسبيًا ولدي خبرة متقطعة في إدارة تطبيقات Linux، إلا أنني لست على دراية تقنية بنظام Discourse، كما أنني لم أقم بإعداد التثبيت الأولي. أعرف أن هذا هو الوضع المفضل لديكم!
أنا أتبع هنا التعليمات الظاهرة على الشاشة، والتي بدأت بالنقر على أزرار “upgrade” الزرقاء في واجهة المستخدم الخاصة بـ Docker. بمجرد اكتمال ذلك، رأيت تعليمات على الشاشة لتسجيل الدخول عبر سطر الأوامر وتشغيل git pull وإعادة بناء launcher. هذا هو الطريق الذي أوصلني إلى هذه النقطة.
كما أود الإشارة إلى أن منتدى كان يعمل بشكل مثالي تمامًا قبل هذه العملية، دون أي مشاكل على الإطلاق، إذا كان ذلك يساعد في التشخيص. السبب الوحيد الذي دفعنا لإجراء هذا التحديث هو ببساطة البقاء على اطلاع دائم بالإصدارات التي تطلقونها حتى لا نتأخر كثيرًا. هذا هو التناقض المركزي في عقلية “ما لم يكن معطوبًا فلا تُصلحه”، حيث أخشى أن يؤدي التحديث إلى حدوث خطأ يتجاوز قدرتي على إصلاحه. وفي الواقع، ها نحن هنا.
حتى لحظة كتابة هذا، فإن المنتدى غير متصل تمامًا بالشبكة، ونظرًا لأن هذا المكون أساسي في عملنا، فإنني أود جدًا إعادة تشغيله في أسرع وقت ممكن.
أي توعية أو نصيحة تُقدّر جدًا!
–
فشل
خطأ تنفيذ Pups::ExecError: فشل أمر cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’ مع إرجاع #<Process::Status: pid 3972 exit 1>
موقع الفشل: /pups/lib/pups/exec_command.rb:112:in `spawn’
فشل التنفيذ مع المعاملات {“cd”=>“$home”, “hook”=>“db_migrate”, “cmd”=>[“su discourse -c ‘bundle exec rake db:migrate’”]}
f89318158c2c276c69a60d600def8a838ae4ad4bc7bafbe665fb1cd77c130ad1
** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، فقد يكون هناك أكثر من رسالة.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
مرحبًا غافين! شكرًا لك على الرد السريع. نحن نعمل على Droplet عبر Digital Ocean، وعند تسجيل الدخول يبدو الأمر كالتالي:
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-210-generic x86_64)
أما فيما يتعلق باستخدام الدليل الرسمي الخاص بك، فلا أستطيع الجزم بذلك. هذه تثبيتات نعمل بها منذ حوالي 3-4 سنوات دون أي مشاكل، رغم أنني لم أكن الشخص الذي قام بإعداده في البداية. وقد تطلب الأمر عادةً فقط ترقيات عبر المتصفح، وإعادة بناء دورية عبر سطر الأوامر، وقد نجحت جميعها دون أي تدخل إضافي منا حتى الآن.
لدي مخرجات المحطة الطرفية الكاملة لعملية إعادة البناء محفوظة في ملف ويمكنني فحصها. لكننا نعمل في بيئة Droplet افتراضية ولم نقم بأي تغييرات عليها منذ إعدادها. في الواقع، نادرًا ما نسجل الدخول لأن Discourse تعمل بسلاسة مع الترقيات عبر المتصفح. لذا لا أعرف ما الذي تغير فجأة لجعل قاعدة البيانات غير قابلة للوصول.
بالتأكيد. هذه حالة عملت فيها الأمور بسلاسة لسنوات متتالية، لذا لا يوجد ضغط كبير علينا لتغيير ذلك. لكننا سعداء بتوظيف شخص للنظر في ما قمنا بتثبيته من وقت لآخر والتأكد من أن كل شيء محدث، بدلاً من القيام بذلك بنفسي. هل هناك مورد أو دليل للعثور على خبراء Discourse قد يكونون منفتحين على هذا النوع من العمل؟
حسناً، بعد البحث عن التحذيرات والأخطاء في مخرجات إعادة البناء، إليك ما توصلت إليه (في الأسفل).
–
227:initdb: تحذير: تم تفعيل مصادقة “trust” للاتصالات المحلية
294:update-alternatives: تحذير: إجبار إعادة تثبيت البديل /usr/share/postgresql/13/man/man1/psql.1.gz لأن مجموعة الروابط psql.1.gz تالفة
324:update-alternatives: تحذير: إجبار إعادة تثبيت البديل /usr/share/postgresql/13/man/man1/postmaster.1.gz لأن مجموعة الروابط postmaster.1.gz تالفة
–
1684:createdb: خطأ: فشل إنشاء قاعدة البيانات: خطأ: قاعدة البيانات “discourse” موجودة بالفعل
1811:I, [2021-08-29T20:18:40.246150 #1] INFO – : > cd /var/www/discourse && bash -c “touch -a /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log”
1813:I, [2021-08-29T20:18:40.253584 #1] INFO – : > cd /var/www/discourse && bash -c “ln -s /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log /var/www/discourse/log”
2563:StandardError: حدث خطأ، تم إلغاء هذا الإجراء وجميع عمليات الهجرة اللاحقة:
2698:-- add_column(:groups, :imap_last_error, :text)
2961:** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، قد يكون هناك أكثر من خطأ.
3118:createdb: خطأ: فشل إنشاء قاعدة البيانات: خطأ: قاعدة البيانات “discourse” موجودة بالفعل
3245:I, [2021-08-29T20:22:40.262592 #1] INFO – : > cd /var/www/discourse && bash -c “touch -a /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log”
3247:I, [2021-08-29T20:22:40.274767 #1] INFO – : > cd /var/www/discourse && bash -c “ln -s /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log /var/www/discourse/log”
3960:StandardError: حدث خطأ، تم إلغاء هذا الإجراء وجميع عمليات الهجرة اللاحقة:
4087:** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، قد يكون هناك أكثر من خطأ.
4224:/error – ابحث عن كلمة ‘خطأ’
4358:createdb: خطأ: فشل إنشاء قاعدة البيانات: خطأ: قاعدة البيانات “discourse” موجودة بالفعل
4485:I, [2021-08-29T20:26:59.373901 #1] INFO – : > cd /var/www/discourse && bash -c “touch -a /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log”
4487:I, [2021-08-29T20:26:59.381142 #1] INFO – : > cd /var/www/discourse && bash -c “ln -s /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log /var/www/discourse/log”
5200:StandardError: حدث خطأ، تم إلغاء هذا الإجراء وجميع عمليات الهجرة اللاحقة:
5327:** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، قد يكون هناك أكثر من خطأ.
شكرًا مرة أخرى على إلقاء نظرة على هذا يا غافن، وعذرًا على إهمال ترقيات نظام التشغيل.
ما ورد أعلاه هو مجرد ما أراه عند البحث عن كلمات “error” و"warning" في مخرجات السكربت، وقد حفظت المخرجات كاملة هنا. إذا كان هناك أي شيء آخر يجب أن أبحث عنه في تلك المخرجات، فلا تتردد في إخباري، وسأكون سعيدًا بنشره.
آه، عذراً، أدرك أن المخرجات أقل من الشرح قليلاً. إليك التفاصيل حول رسالة “StandardError”. يبدو أن استعلام INSERT فشل بسبب مفتاح مكرر. تم حذف تفاصيل الاستعلام لتحسين القراءة، ويمكنني تضمينها إذا لزم الأمر.
–
I, [2021-08-29T20:23:37.257772 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’
2021-08-29 20:23:42.937 UTC [3996] discourse@discourse ERROR: duplicate key value violates unique constraint “data_explorer_queries_pkey”
2021-08-29 20:23:42.937 UTC [3996] discourse@discourse DETAIL: Key (id)=(-2) already exists.
2021-08-29 20:23:42.937 UTC [3996] discourse@discourse STATEMENT: INSERT INTO
[…]
FROM plugin_store_rows
WHERE plugin_name = ‘discourse-data-explorer’ AND type_name = ‘JSON’
rake aborted!
StandardError: حدث خطأ، تم إلغاء هذا الانتقال وجميع الانتقالات اللاحقة:
إذا فهمت هذا بشكل صحيح، يبدو أن هناك جدول قاعدة بيانات يُستخدم بواسطة إضافة تسمى “استكشف البيانات” يحتوي على صف مكرر، وحذف هذا الصف المكرر يسمح لبرنامج إعادة البناء بالمضي قدمًا. من ذلك الموضوع، يبدو أيضًا أن هذا الخطأ — أو أخطاء مشابهة — قد حدث من قبل، وقد تكون هناك تحديثات لمنصة Discourse لمنع حدوث ذلك في المستقبل. أي أن الترقيات المستقبلية التي نقوم بها قد لا تواجه هذه المشكلة.
لنختم هذا الأمر، فبالنسبة لأي شخص يواجه هذه الخطأ، يبدو أننا واجهنا عدة مشاكل.
أما فيما يتعلق بالترقية نفسها، فقد تسبب الصف المكرر في إضافة “data_explorer” في حدوث مشكلة، وكان من الضروري إزالته.
ومع ذلك، وكجزء من هذه العملية، قمنا أيضًا بترقية نظام التشغيل من Ubuntu 16 إلى 20، مما تسبب في خطأ شبكي جعل السحلية (Droplet) الخاصة بـ Digital Ocean غير قابلة للوصول بعد إعادة التشغيل. وتحديدًا، يبدو أنه مع انتقال نظام التشغيل إلى إعداد “Netplan” الجديد، كان هناك شيء في الإعدادات يمنع سكريبت تشغيل واجهة الشبكة من الاكتمال في اللحظة التي تم فيها تشغيله. لذا، فقد تم تشغيل السحلية، لكن الشبكة لم تعمل. وبعد ذلك، عند الدخول عبر وحدة التحكم في الاستعادة داخل المتصفح، وتشغيل سكريبت واجهة الشبكة مرة أخرى، تم تفعيل الواجهة وأصبح بإمكاننا الوصول إليها من الخارج مرة أخرى. طالما أننا لا نضطر إلى إعادة تشغيل السحلية، فسنكون بخير حتى نتمكن من إيجاد وقت لإيقاف التشغيل واختبار إصلاح إعدادات Netplan.
أعلم أن هذا ربما حالة نادرة، لكنني أتذكر أنني قرأت في مكان ما أن ترقيات نظام التشغيل عمومًا لا تسبب مشاكل. ورغم أن هذا صحيح على الأرجح في معظم الأوقات، إلا أن الأمر لم يكن كذلك هنا، مما جعلنا خارج الخدمة لمدة نصف يوم تقريبًا حتى تزامنت المناطق الزمنية مع الوقت الذي تمكن فيه فريقنا التقني من استعادتنا للعمل.
إذًا، تم حل المشكلة مؤقتًا. شكرًا لكم جميعًا على ردودكم السريعة.
