Partkeepr: Setup2 / 2 Warming Cache - استجابة غير صالحة من الخادم

يرجى إلقاء نظرة في سجل أخطاء خادم الويب الخاص بك أو مكان تسجيل تثبيت PHP الخاص بك الخطأ

في عمليات تثبيت debian / ubuntu للمخزون ، انتقلت الأخطاء إلى / var / log / apache2 / error_log

هذا هو محتوى /var/log/apache2/error.log

errorLog.txt

تحرير: يبدو أنه فارغ ، وفقًا لـ php.ini ، يجب أن يكتب جميع أنواع الأخطاء.
أم ، هذا يبدو غريبًا ولكن كونك تحت الوكيل يمكن أن يكون له تأثير؟ أيضًا ، رأيت الكثير من أخطاء التعليمات البرمجية المهملة - لكن مرة أخرى لست متأكدًا مما إذا كانت هي الخطأ.

التالي هو الخطأ الأخير ضمن partkeepr / app / logs / setup.log

php.INFO: تعريف طريقة getGlobals () في الامتداد "Assetic" تم إهماله دون تنفيذ Twig_Extension_GlobalsInterface بشكل صريح.
بعد الكثير من الرسائل النصية ، أرى أن هذه مكالمة إحماء:
...، "class": "PartKeepr \ SetupBundle \ Controller \ CacheWarmupSetupController" ... {"function": "cacheWarmupAction" ....

الآن نظرنا إلى البداية ، هو الذي تسبب في هذا الخطأ:
... {"type": 16384، "file": "/ var / www / partkeepr-1.2.0 / app / cache / setup / classes.php"، "line": 3494، "level": 28928، " المكدس ": [{" الوظيفة ":" handleError "،" class ":" Symfony \ Component \ Debug \ ErrorHandler "،" type ":" -> "}، {" file ":" / var / www / partkeepr- 1.2.0 / app / cache / setup / class.php "،" line ": 3494،" function ":" trigger_error "}، {" file ":" / var / www / partkeepr-1.2.0 / app / cache /setup/classes.php "،" line ": 3455،" function ":" initGlobals "،" class ":" Twig_Environment "،" type ":" -> "}، {....
تضمين التغريدة

مرحبا
جربها
apt-get install php-apcu php-apcu-bc

FinalHopee هل يستغرق الأمر وقتًا طويلاً حتى تظهر رسالة الرد غير الصالحة؟

نعم ، يبدو أنها دقيقتان. لقد قمت بتكوينه على 120 على النحو الموصى به.
لقد نجحت في تثبيت apcu - لا توجد تحذيرات بعد الآن.
لكن نفس الخطأ.

ثم يجب عليك زيادة max_execution_time - التحذير من ذاكرة التخزين المؤقت هو عملية مكثفة للقرص يمكن أن تنتهي مهلتها بسهولة على الأقراص البطيئة.

صباح 11. فبراير 2017 12:02:22 MEZ schrieb FinalHopee [email protected] :

نعم ، يبدو أنها دقيقتان. لقد قمت بتكوينه على 120 على النحو الموصى به.
لقد نجحت في تثبيت apcu - لا توجد تحذيرات بعد الآن.
لكن نفس الخطأ.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279136866

-
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

اضبط max_execution_time على 600 ، ولكن لسبب ما يظهر خطأ بعد تشغيل دقيقتين بالضبط.
لقد أعدت تشغيل خدمة apache2 ، حتى أنني أعدت تشغيل المضيف.

غدًا سأحاول تثبيتًا جديدًا على جهاز كمبيوتر فعلي.
سوف تبقيك على اطلاع ، شكرا على أي مساعدة!

هل يمكنك التحقق باستخدام ملف phpinfo.php من أن الإعداد ساري المفعول؟

أنا 11. فبراير 2017 13:20:32 MEZ schrieb FinalHopee [email protected] :

قم بتعيين max_execution_time إلى 600 ، ولكن لسبب ما يظهر خطأ
بالضبط بعد دقيقتين من الجري.
لقد أعدت تشغيل خدمة apache2 ، حتى أنني أعدت تشغيل المضيف.

غدًا سأحاول تثبيتًا جديدًا على جهاز كمبيوتر فعلي.
سوف تبقيك على اطلاع ، شكرا على أي مساعدة!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279140451

-
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

نعم ، تبدو جيدة.
بيانات phpinfo المرفقة.
phpinfo المصدّر إلى html ، يمكنك تعديل النهاية أو فتحه عبر المتصفح لسهولة العرض.
هل كل شيء يبدو على ما يرام هناك؟
info.html.txt

تحديث:
أولا شكرا لكم جميعا على المساعدة والوقت!
ثانيًا ، أنا بحاجة إلى زيادة المعرفة في هذا الأمر لإعطاء المزيد من المدخلات حول كيف ولماذا يعمل.

بعد كل شيء كانت مشكلة الوكيل ، كما اعتقدت.
ما فعلته اليوم هو أنني استخدمت جهازًا جديدًا لدينا ، وجهاز كمبيوتر شخصيًا جيدًا - تم تثبيت Ubuntu نظيفًا وكل ما هو مطلوب وفقًا لدليل Partkeepr Wiki ولم ينجح.
بعد ذلك ، أردت اختبار الوكيل الذي يستخدمه مكاننا ، إذا كان الأمر كذلك.
ما فعلته هو توصيل كابل الشبكة من جهاز الكمبيوتر وحاولت مرة أخرى عملية الإعداد وبعد الانتظار لمدة 5 - 10 ثوانٍ ، اكتمل التسخين!
نفس الاختبار الذي أجريته على جهاز كمبيوتر آخر كنت أرغب في استخدام برنامج Partkeepr عليه ، وقد نجح أيضًا!

بعد اختبار المشكلة ، قمت بتوصيل الكبل وتشغيل الإعداد مرة أخرى.
باستخدام نفس العنوان ونفس المتصفح ( المضيف المحلي / الإعداد ) ، حصلت على هذا الخطأ مرة أخرى - استجابة الخادم غير صالحة
لست متأكدًا من كيفية الانتقال وتصحيح الأخطاء من هنا ، لكن يبدو أن هناك شيئًا ما يحظر ويتعلق ببروكسي شركتنا. - مرة أخرى ، أقوم بهذا الإجراء على جهاز الكمبيوتر باستخدام عنوان المضيف المحلي. انها لن تعمل عن بعد أيضا بالطبع.

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

حسنًا ، ربما تكون هذه مشكلة نظرًا لأن PartKeepr يقوم بالفعل بتشغيل cronjobs عند تسخين ذاكرة التخزين المؤقت - ربما هذا هو السبب وراء انقضاء الوقت في هذا الموضع؟ تحتاج إلى تنفيذ دعم الوكيل لـ PartKeepr ، وترك المشكلة مفتوحة

مشكلة الوكيل الأخرى التي وجدتها هي دعم octopart.
بدون وكيل ، فإنه يعثر على العناصر بنجاح ، ولكن يفشل تشغيل الشبكة في الخادم الوكيل.

نعم ، في الوقت الحالي لا يوجد دعم للوكلاء في PartKeepr.

لديك نفس المشكلة ، ولكن لا يمكن تعطيل الوكيل. هل هناك طريقة لتعديل خطوة "تسخين ذاكرة التخزين المؤقت" بحيث تعمل بدون اتصال بالإنترنت؟

حسنًا ، نعم ، يمكنك محاولة العثور على السطر ذي الصلة في الكود وتعطيله. ليس لدي الوقت حاليًا لإصلاح المشكلة ، معذرة :(

أخشى أن مهاراتي البرمجية ليست جيدة بما يكفي لذلك :(

يبدو مثل web / setup / js / Cards / UserSetupCard.js
سطر التعليق // this.tests.push (new PartKeeprSetup.WarmupCacheSetup ()) ؛

لقد أدى التعليق على جزء تسخين ذاكرة التخزين المؤقت إلى الحيلة بالنسبة لي أيضًا (Windows VM مع الوكيل).

يرجى ملاحظة أن إحماء ذاكرة التخزين المؤقت مطلوب حتى يعمل PartKeepr بشكل صحيح - لا أوصي بذلك - وإلا فإنه يؤدي إلى مشكلة مثل # 962

يفترض PartKeepr أن لديه اتصال إنترنت وظيفي.

لحل هذه المشكلة ، قمت بما يلي:
1) قمت بإلغاء تثبيت php7.2 بالأمر التالي:
apt-get إزالة php7.2 *

2) قمت بعد ذلك بتثبيت php7.1 (لم تعد حزم برامج php7.1 متوفرة على مستودعات Ubuntu 18.04.1 الافتراضية المكونة)

يرجى الرجوع إلى الموقع التالي للحصول على إرشادات حول كيفية تثبيت php7.1:
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

أرى أيضًا نفس الأعراض ، لكن لا يبدو أن أيًا من المناقشات هنا تنطبق على وضعي. بعض المعلومات:

• يظهر الخطأ تمامًا بعد دقيقتين تمامًا (كما علق FinalHopee أيضًا) ، على الرغم من أنني قمت بتعيين max_execution_time إلى 240 ثانية (لقد راجعت هذا أيضًا باستخدام phpinfo.php)
• لا يوجد خادم وكيل قيد الاستخدام. نظرًا لأن FinalHopee جعلها تعمل عن طريق توصيل الكبل ، فقد قطعت الوصول إلى الإنترنت مؤقتًا عن طريق تصفية IP في جهاز التوجيه الخاص بي ، لكن ذلك لم يحدث فرقًا.
• أنا أستخدم التوت بي 2
• إصدار php المثبت هو 7.0
• لا يحتوي ملف setup.log على أية أخطاء بخلاف تلك "المنحلة" التي يراها الآخرون أيضًا.

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

شكرا لك مقدما!

لقد قمت بضبط الوقت ، وهو بالضبط دقيقتان ، في الثانية

كذلك هنا :(
مثبتة على synology NAS.
تعمل جميع أجزاء الإعداد بشكل صحيح بعد بعض عمليات الضبط في NAS-OS.
ولكن ، عند "إحماء ذاكرة التخزين المؤقت" ، يفشل بعد حوالي دقيقتين.

• تم اختبار Apache 2.2 & 2.4
• تم اختبار PHP 5.6 و 7.0 و 7.2
• زادت مهلات PHP إلى قيم كبيرة حقًا
• تم اختبار الإعدادات باستخدام phpinfo بعد التغيير
• تم تضمين "Timeout 600" في "/usr/local/etc/apache24/conf/httpd24.conf"

لا توجد طريقة لجعلها تعمل - هذا محبط بعض الشيء ...

أعتقد أنه من الممكن حل عملية التثبيت من خلال سطر أوامر ssh.
ربما يمكنك إيجاد حل قراءة هذا الموضوع
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
لقد قمت بتشغيله على Synology ، وواجهت نفس المشكلة.

واجهت هذه المشكلة اليوم مع تثبيت جديد (FreeBSD 11 ، PHP 7.2) واكتشفت وظيفة سطر الأوامر لهذا:

root<strong i="6">@server</strong>:/var/www/partkeepr # php ./app/console cache:warmup
 // Warming up the cache for the dev environment with debug true

 [OK] Cache for the "dev" environment (debug=true) was successfully warmed.

أنا الآن بصدد تصحيح الخطأ التالي ... والذي يبدو أنه مرتبط بوظائف التوافق مع الإصدارات السابقة لـ APCU.

واجهت للتو نفس هذه المشكلة (على Ubuntu 16.04 ، PHP 7.0 ، Apache 2.4.18)
ذاكرة التخزين المؤقت اليدوية: يعمل الإحماء (انظر المنشور أعلاه) ، لكن الإحماء يستمر في الفشل عبر واجهة مستخدم الويب
فشل تثبيت php-apcu-bc: "ليس لديه مرشح تثبيت"

سأحاول التثبيت مرة أخرى على ubuntu 18.04

thijz مشكلتك بها وكيل (إعادة توجيه) متضمن ، لا يمكنك تجنبه؟

كان للوكيل العكسي nginx الخاص بي مهلة افتراضية 60 ثانية ، لذلك كان هذا يعرقلني. أنا لا أبيع بالضبط أن هذه مشكلة PartKeepr ، رغم ذلك. حقا يبدو وكأنه مشكلة تكوين الوكيل.

معالجة قيم مهلة الوكيل الصحيحة أصلحت الأشياء بالنسبة لي.

المرجع: https://www.smashinglab.com/fix-504-gateway-time-nginx/

أهلا يا أصدقاء! أريد أن أضيف إلى هذا الخطأ. أقوم بتثبيت PartKeepr على OrangePi (وهو ليس سريعًا بأي حال من الأحوال) حيث تستغرق عملية إحماء ذاكرة التخزين المؤقت 2.5 دقيقة (ويتم تعيين max_execution_time على 3 دقائق). ومع ذلك ، كما أفهمها ، يتم تعيين مهلة دقيقتين في مكان ما في الواجهة الأمامية:

في لقطة الشاشة ، يمكنك رؤية طلبي WarmupCache ، أحدهما من واجهة الويب التي تم إجراؤها أثناء إجراء الإعداد ، والآخر يتم يدويًا عبر Chrome devtools. يتم إلغاء أول واحد عند 2 متر ، وينجح الآخر بعد 2.5 دقيقة (ويعود بشكل جيد). لذلك ، أثناء عمل إحماء ذاكرة التخزين المؤقت ، تنهي الواجهة الأمامية الطلب قبل الإكمال. هل هناك طريقة لزيادة المهلة من جانب JS؟

نعم ، المهلة هنا: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
دونو كيفية تغييره بشكل صحيح لهذا الطلب فقط بالرغم من ذلك

لقد رأيت هذه المشكلة نفسها عند محاولة إعداد صورة Docker للتطوير على Windows (باستخدام Docker w / WSL2 ، والذي يتميز بأداء نظام ملفات سيئ للغاية). تشير السجلات إلى أن جانب الخادم يقوم في النهاية بإرجاع استجابة ناجحة ، ولكن واجهة المستخدم قد أخطأت بالفعل بحلول وقت استلامها ، تمامًا كما أشار @ positron96 .

سأحاول وأختبر طلب سحب @ positron96 لمعرفة ما إذا كان يعمل مع حالة الاستخدام هذه.