خطأ أثناء إعادة البناء: registry.yarnpkg.com ESOCKETTIMEDOUT

تثبيت
1

أقوم بتشغيل نسخة مستضافة ذاتيًا من Discourse على https://forum.embeetle.com.

بالأمس، فشل الترقية بنقرة واحدة عبر المتصفح، لذا سجلت الدخول إلى الخادم وحاولت تشغيل ./launcher rebuild app.

فشل هذا أيضًا، مع الخطأ التالي:

I, [2024-08-01T20:46:09.837292 #1]  INFO -- : 
I, [2024-08-01T20:46:09.837631 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'yarn install --frozen-lockfile & yarn cache clean'
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
error Error: https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz: ESOCKETTIMEDOUT
    at ClientRequest.<anonymous> (/usr/share/yarn/lib/cli.js:142037:19)
    at Object.onceWrapper (node:events:631:28)
    at ClientRequest.emit (node:events:517:28)
    at TLSSocket.emitRequestTimeout (node:_http_client:847:9)
    at Object.onceWrapper (node:events:631:28)
    at TLSSocket.emit (node:events:529:35)
    at Socket._onTimeout (node:net:598:8)
    at listOnTimeout (node:internal/timers:569:17)
    at process.processTimers (node:internal/timers:512:7)

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

لا توجد مشكلة في الشبكة: من داخل حاوية docker (./launcher enter app)، تشغيل wget https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz يعود بنجاح في أقل من 0.1 ثانية.

لقد تحققت من هذه المشكلة المشابهة: Error during the update ESOCKETTIMEDOUT registry.yarnpkg.com - #4 by jericson الاقتراح هناك هو زيادة مهلة الانتهاء عن طريق تعديل /var/discourse/templates/web.template.yml.

للأسف، هذا المسار غير موجود في تثبيتي (من داخل حاوية docker، لا يوجد /var/discourse؛ هناك مجلد var/www/discourse وهو الدليل العامل الافتراضي عند الدخول إلى التطبيق، ولكن هذا لا يحتوي على مجلد فرعي templates؛ بحثت عن web.template.yml ولكن لم أجده في أي مكان.

لست واثقًا جدًا من أن زيادة مهلة الانتهاء ستصلح المشكلة، نظرًا للتنزيل السريع جدًا لـ https://registry.yarnpkg.com/date-fns/-/date-fns-3.6.0.tgz.

انتهى بي الأمر باستعادة نسخة احتياطية من بضعة أيام مضت، مع إصدار أقدم من discourse، ونسخ أحدث إصدار من discourse/shared إليه. هذا يعمل، لذا المنتدى قيد التشغيل مرة أخرى.

هل هناك خطأ في أحدث إصدار على الفرع الرئيسي؟ لقد حاولت بالفعل تشغيل ./launcher rebuild app مرة أخرى، وفشل مرة أخرى بنفس الطريقة، لذا اضطررت إلى استعادة المنتدى من النسخة الاحتياطية مرة أخرى.

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

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

على سبيل المثال، لقد قمت للتو بتحديث Discourse على Droplet بسعة 4 جيجابايت ولم أواجه أي مشاكل خاصة.

3

أنا أستخدم خادمًا افتراضيًا خاصًا (VPS) بذاكرة وصول عشوائي (RAM) بسعة 32 جيجابايت، وحاليًا 24 جيجابايت مجانية؛ لذلك لا ينبغي أن تكون الذاكرة مشكلة.

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

يمكنك تجربة

./launcher start app

لتشغيل الحاوية القديمة مرة أخرى.
هذا لا يحل المشكلة ولكنه سيعيد تشغيل موقعك. لا تحتاج إلى استعادة من نسخة احتياطية.

/var/discourse هو خارج الحاوية، وليس بداخلها. هذا القالب هو ما يبني الأشياء داخل الحاوية، لذا يستحق التجربة.

أيضًا، مع وجود ذاكرة وصول عشوائي (RAM) لديك، سأنتقل إلى إعداد حاويتين حتى تتمكن من البدء دون إيقاف موقعك.

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

للأسف، مجرد تشغيل

./launcher start app

لا يعيد المنتدى للعمل.

على أي حال، قمت بتجارب إضافية. على وجه التحديد، حاولت تنفيذ أمر yarn الفاشل يدويًا في صورة docker:

./launcher enter app
cd /var/www/discourse
su discourse
yarn install --frozen-lockfile
... يفشل بنفس مهلة الانتهاء ...
yarn config set network-timeout 600000 -g
yarn install --frozen-lockfile
... ينجح ...

يؤكد هذا أن زيادة مهلة الانتهاء تحل المشكلة.

السؤال المتبقي إذن هو كيفية زيادة مهلة الانتهاء أيضًا أثناء ./launcher rebuild app.

الملف web.template.yml موجود بالفعل في discourse/containers خارج صورة docker. لم أجده في البداية، لأن تثبيت Discourse الخاص بي في موقع غير قياسي، وليس في /var/discourse.

الإصلاح المذكور في المنشور المشار إليه أعلاه يشير إلى السطر 159، ولكن هذا لم يعد يبدو صحيحًا، ربما بسبب التحديثات. ومع ذلك، توجد هذه الأسطر حول السطر 188:

  - exec:
      cd: $home
      hook: yarn
      cmd:
        - |-:
          if [ "$version" != "tests-passed" ]; then
            rm -rf app/assets/javascripts/node_modules
          fi
        - su discourse -c 'yarn install --frozen-lockfile &amp;&amp; yarn cache clean'

يقترح المنشور إدراج قسم جديد لتعيين مهلة الانتهاء، ولكنه لا يقدم تعليمات محددة حول كيفية القيام بذلك. أنا لست على دراية كبيرة بـ yaml أو pups أو yarn أو كيفية استخدامها في Discourse، لذلك لم أكن أرغب في التخمين. بدلاً من ذلك، جربت هذا التغيير على القسم الأصلي:

  - exec:
      cd: $home
      hook: yarn
      cmd:
        - |-:
          if [ "$version" != "tests-passed" ]; then
            rm -rf app/assets/javascripts/node_modules
          fi
        - su discourse -c 'yarn config set network-timeout 600000 -g &amp;&amp; yarn install --frozen-lockfile &amp;&amp; yarn cache clean'

يستغرق الأمر ./launcher rebuild app الآن وقتًا طويلاً جدًا (أكثر من ساعتين!، أطول بكثير مما كان يستغرقه سابقًا). الخبر السار هو أن المنتدى عاد للعمل! رائع، شكرًا للمساعدة.

هل هناك طريقة لزيادة مهلة الانتهاء عن طريق إضافة أمر إلى containers/app.yml؟ سيكون ذلك مناسبًا، لأنه سيحتفظ بجميع تخصيصاتي في ملف واحد.

يبدو أن استخدام إعداد حاويتين فكرة رائعة؛ لم أكن على علم بإمكانية ذلك. أعتقد أنك تشير إلى هذا: https://meta.discourse.org/t/move-from-standalone-container-to-separate-web-and-data-containers/29413؛ سأجربها. أي نصائح إضافية مرحب بها.

عندما أقوم بتحديث مثيل Discourse الخاص بي من المتصفح، هل يقوم أيضًا بتشغيل ./launcher rebuild app؟ هل يؤدي ذلك إلى إيقاف المنتدى مؤقتًا؟ حتى الآن، كان لدي انطباع بأن المنتدى يظل عبر الإنترنت خلال معظم العملية، لكنني لست متأكدًا. لم تكن هذه الأمور واضحة لي أبدًا، ولم يكن لدي الوقت الكافي لفهمها حقًا. أي إجابات أو إشارات إلى مزيد من المعلومات مرحب بها.

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