لوحة السجل تتوقف عن التحديث أثناء التحديث

الدعم
1

مجرد تحديث منتديين إلى الإصدار 2.7.0.beta6. سار تحديث أحدهما بسلاسة، حيث تم تحديث مدير Docker أولاً ثم Discourse. أما الآخر، الذي كان يحتاج أيضًا إلى تحديث لاستكشاف البيانات، فقد لاحظت أن لوحة السجلات توقفت مرتين أثناء التحديث النهائي لـ Discourse نفسه. في كلتا الحالتين، كان التوقف عند
Waiting for Unicorn to reload...........
مرة في البداية ومرة في النهاية، بعد تحديث تبويب المتصفح.

كان التوقف في النهاية قد سجل 11 سطرًا من رسائل الانتظار قبل التوقف.

Done compiling CSS: 2021-04-08 12:54:13 UTC
Restarting unicorn pid: 49
Waiting for Unicorn to reload.
Waiting for Unicorn to reload..
Waiting for Unicorn to reload...
Waiting for Unicorn to reload....
Waiting for Unicorn to reload.....
Waiting for Unicorn to reload......
Waiting for Unicorn to reload.......
Waiting for Unicorn to reload........
Waiting for Unicorn to reload.........
Waiting for Unicorn to reload..........
Waiting for Unicorn to reload...........

أما التوقف في البداية فكان عند عدد مماثل تقريبًا.

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

نجح الترقية، وبعد تحديث الصفحة، تمكنت من رؤية ومراجعة سجل الأحداث بالكامل، لكن توقف تحديث لوحة السجلات كان مُقلقًا وربما مُضلّلًا.

لا توجد ملاحظات من وحدة تحكم الجافاسكربت.

2

آه، بعد فترة طويلة، أرى شيئًا في وحدة تحكم JS (هذا هو Chrome على نظام Mac)

[Violation] 'setTimeout' handler took 64ms

مع رابط إلى السطر 5211 في ملف docker-manager-vendor-970…js، أي أن المسار هو /assets/docker-manager-vendor-9709990270a4ade37544c98dda3cfad18f77cdf6cd433291c3c5ef7bd25cb50d.js
ويبدو كالتالي:

try{r||n?t=s.minPollInterval:(t=s.callbackInterval,o>2?t*=o:a()||(t=s.backgroundCallbackInterval),t>s.maxPollInterval&&(t=s.maxPollInterval),(t-=new Date-w)<100&&(t=100))}catch(i){console.log&&i.message&&console.log("MESSAGE BUS FAIL: "+i.message)}d&&(clearTimeout(d),d=null),u&&(d=setTimeout((function(){d=null,e()}),t)),s.longPoll=null}})}},s={minHiddenPollInterval:1500,enableChunkedEncoding:!0,enableLongPolling:!0,callbackInterval:15e3,backgroundCallbackInterval:6e4,minPollInterval:100,maxPollInterval:18e4,callbacks:n,clientId:i,alwaysLongPoll:!1,baseUrl:"/",headers:{},ajax:p&&p.ajax,noConflict:function(){return e.MessageBus=e.MessageBus.previousMessageBus,this},diagnostics:function(){console.log("Stopped: "+l+" Started: "+u),console.log("Current callbacks"),console.log(n),console.log("Total ajax calls: "+O+" Recent failure count: "+o+" Total failures: "+R),console.log("Last ajax call: "+(new Date-w)/1e3+" seconds ago")},pause:function(){f=!0},resume:function(){f=!1,T(h),h=[]},stop:function(){l=!0,u=!1,v&&(clearTimeout(v),v=null),s.longPoll&&s.longPoll.abort()},start:function(){var r
3

ربما نفدت ذاكرة النظام لديك أو حدث شيء ما.

هل يمكنك محاولة إعادة البناء من وحدة التحكم؟

4

ملاحظة: تم الترقية بنجاح؛ والفشل يكمن في عرض المتصفح لتدفق السجلات. عند التحديث، أصبح السجل بأكمله مرئيًا. لذا، أنا متأكد إلى حد كبير من أننا نواجه مشكلة من جانب العميل، وليس أي نوع من مشاكل الترقية أو إعادة البناء أو الخادم.

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

لا أفهم كيف يرتبط كود JavaScript الذي يراه المتصفح بشجرة المصدر، ولكن ربما يكون هذا هو الكود الذي رأيته مرتبطًا في وحدة التحكم (وهو كود لم يتغير مؤخرًا)

5

واجهت نفس المشكلة في بعض المواقع التي أديرها، لكن ليس في جميعها، لذا يبدو أنها مشكلة في الإعدادات. لا أملك حتى الآن أي دليل قاطع، لكن تخميني الأكثر استنارة هو أن الأمر قد يكون متعلقًا بموقع متعدد (multisite).

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

6

شكرًا لك، هذا مثير للاهتمام ومفيد. ليس لدي إعداد متعدد المواقع (حتى الآن) — منتداي موجودان على مضيفين مختلفين. لذا، يمكن لكل من الإعدادات متعددة المواقع وغير متعددة المواقع رؤية هذا.

7

حدث هذا مرة أخرى مع التحديث إلى 2.7.0.beta9: ظل تدفق السجل عالقًا يعرض أنه يتوقف عن تشغيل وحدات