Partkeepr: सेटअप 2/2 वार्मिंग कैश - सर्वर से अमान्य प्रतिक्रिया

कृपया अपने वेब सर्वर के त्रुटि लॉग में देखें या जहां आपका PHP इंस्टॉलेशन त्रुटि लॉग करता है

स्टॉक डेबियन/उबंटू इंस्टॉलेशन पर त्रुटियां /var/log/apache2/error_log . पर जाती हैं

यह /var/log/apache2/error.log . की सामग्री है

errorLog.txt

संपादित करें: ऐसा लगता है कि यह खाली है, php.ini के अनुसार इसे सभी त्रुटि प्रकार लिखना चाहिए।
उम्म, यह अजीब लगता है लेकिन प्रॉक्सी के तहत होने का असर हो सकता है? साथ ही, मैंने बहुत सी बहिष्कृत कोड त्रुटियां देखीं - लेकिन फिर से यह सुनिश्चित नहीं है कि यह एक है या नहीं।

partkeepr/app/logs/setup.log के अंतर्गत अंतिम त्रुटि निम्नलिखित है:

php.INFO: "assetic" एक्सटेंशन में getGlobals() विधि को परिभाषित करना Twig_Extension_GlobalsInterface को स्पष्ट रूप से लागू किए बिना बहिष्कृत है।
बहुत सारे पाठ के बाद मैंने देखा कि यह वार्मअप कॉल है:
...,"क्लास":"पार्टकीपर\सेटअपबंडल\कंट्रोलर\कैशवार्मअपसेटअपकंट्रोलर"... {"फ़ंक्शन":"कैशवार्मअपएक्शन"...

अब शुरुआत में देखा गया है, जिसने इस त्रुटि को ट्रिगर किया है:
...{"type":16384,"file":"/var/www/partkeepr-1.2.0/app/cache/setup/classes.php","line":3494,"level":28928," स्टैक": [{"फ़ंक्शन": "हैंडलएरर", "क्लास": "सिम्फनी \ कंपोनेंट \ डीबग \ एररहैंडलर", "टाइप": "->"}, {"फाइल": "/ var / www / पार्टकीपर- 1.2.0/app/cache/setup/classes.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":"->"},{....
@ फेलिसिटस

नमस्ते
कोशिश करो
उपयुक्त-प्राप्त करें php-apcu php-apcu-bc . स्थापित करें

@FinalHopee अमान्य प्रतिक्रिया संदेश प्रकट होने तक इसमें लंबा समय लगता है?

हाँ, यह 2 मिनट की तरह लगता है। मैंने इसे अनुशंसित के अनुसार 120 पर कॉन्फ़िगर किया था।
मैं apcu स्थापित करने में सफल रहा - अब कोई चेतावनी नहीं।
लेकिन वही त्रुटि।

फिर आपको max_execution_time बढ़ाना चाहिए - कैश को चेतावनी देना एक डिस्क गहन ऑपरेशन है जो धीमी डिस्क पर आसानी से समय निकाल सकता है।

सुबह 11. फरवरी 2017 12:02:22 MEZ schrieb फाइनलहोपी नोटिफिकेशन @github.com:

हाँ, यह 2 मिनट की तरह लगता है। मैंने इसे अनुशंसित के अनुसार 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 पर सेट करें, लेकिन किसी कारण से यह 2 मिनट चलने के बाद त्रुटि दिखाता है।
मैंने apache2 सेवा को पुनरारंभ किया, यहां तक ​​​​कि होस्ट को रीबूट भी किया।

कल मैं भौतिक पीसी पर नई स्थापना का प्रयास करूंगा।
आपको पोस्ट करता रहेगा, किसी भी मदद के लिए धन्यवाद!

क्या आप phpinfo.php फ़ाइल का उपयोग करके सत्यापित कर सकते हैं कि सेटिंग प्रभावी हुई?

सुबह 11. फरवरी 2017 13:20:32 MEZ schrieb फाइनलहोपी नोटिफिकेशन @github.com:

max_execution_time को 600 पर सेट करें, लेकिन किसी कारण से यह त्रुटि दिखाता है
ठीक 2 मिनट चलने के बाद।
मैंने 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

अद्यतन:
मदद और समय के लिए सबसे पहले धन्यवाद!
दूसरा, यह कैसे और क्यों काम करता है, इस बारे में अधिक जानकारी देने के लिए मुझे इस मामले में ज्ञान में वृद्धि करने की आवश्यकता है।

आखिरकार यह प्रॉक्सी समस्या थी, जैसा मैंने सोचा था।
आज मैंने जो किया वह यह है कि हमारे पास नई मशीन का उपयोग किया गया है, अच्छा पीसी - स्थापित स्वच्छ उबंटू और पार्टकीपर विकी गाइड के अनुसार आवश्यक सब कुछ और यह काम नहीं किया।
फिर, मैं उस प्रॉक्सी का परीक्षण करना चाहता था जिसका उपयोग हमारी जगह करता है, अगर यह मामला है।
मैंने जो किया वह पीसी से नेटवर्क केबल को प्लग आउट कर दिया और सेटअप प्रक्रिया को फिर से करने की कोशिश की और 5-10 सेकंड के इंतजार के बाद वार्मिंग पूरी हो गई!
एक ही परीक्षण मैंने दूसरे पीसी पर किया है जिसे मैं पार्टकीपर का उपयोग करना चाहता था, और यह भी काम करता था!

इस मुद्दे का और परीक्षण करते हुए मैंने केबल को प्लग इन किया और सेटअप को फिर से लॉन्च किया।
उसी पते और उसी ब्राउज़र ( लोकलहोस्ट/सेटअप ) का उपयोग करके मुझे वह त्रुटि फिर से मिली - अमान्य सर्वर प्रतिक्रिया
सुनिश्चित नहीं है कि कैसे जाना है और इसे यहां से आगे कैसे डिबग करना है, लेकिन ऐसा लगता है कि कुछ अवरुद्ध हो रहा है और इसे हमारी कंपनी के प्रॉक्सी के साथ करना है। - फिर से मैं स्थानीयहोस्ट पते का उपयोग करके पीसी पर यह प्रक्रिया कर रहा हूं। दूरस्थ रूप से यह भी निश्चित रूप से काम नहीं करेगा।

संक्षेप में, यह अब काम करता है, लेकिन यह काम क्यों नहीं किया मुझे अभी तक यकीन नहीं है।

हम्म यह शायद एक मुद्दा है क्योंकि पार्टकीपर वास्तव में कैश को गर्म करते समय क्रोनोजर चलाता है - शायद यही कारण है कि यह उस स्थिति में समय समाप्त हो जाता है? समस्या को खुला छोड़कर, पार्टकीपर के लिए प्रॉक्सी समर्थन को लागू करने की आवश्यकता है

एक और प्रॉक्सी समस्या जो मुझे मिली है वह है ऑक्टोपार्ट सपोर्ट।
प्रॉक्सी के बिना यह सफलतापूर्वक आइटम ढूंढता है लेकिन नेटवर्क को प्रॉक्सी के तहत बदलना विफल रहता है।

हाँ, अभी पार्टकीपर में प्रॉक्सी के लिए कोई समर्थन नहीं है।

एक ही समस्या है, लेकिन प्रॉक्सी को अक्षम नहीं कर सकता। क्या "कैश को गर्म करना" -स्टेप को संशोधित करने का कोई तरीका है, कि यह इंटरनेट-कनेक्शन के बिना काम करता है?

ठीक है, हाँ, आप कोड में प्रासंगिक लाइन खोजने और इसे अक्षम करने का प्रयास कर सकते हैं। मेरे पास इस समय समस्या को ठीक करने का समय नहीं है, क्षमा करें :(

मुझे डर है कि मेरे सॉफ्टवेयर-कौशल उसके लिए पर्याप्त नहीं हैं :(

ऐसा लगता है कि वेब/सेटअप/जेएस/कार्ड्स/यूजरसेटअपकार्ड.जेएस
टिप्पणी पंक्ति // this.tests.push (नया PartKeeprSetup.WarmupCacheSetup ());

कैश वार्मिंग भाग पर टिप्पणी करते हुए मेरे लिए भी चाल चली (प्रॉक्सी के साथ विंडोज वीएम)।

कृपया ध्यान दें कि पार्टकीपर को ठीक से चलाने के लिए कैश को गर्म करना आवश्यक है - मैं इसे करने की अनुशंसा नहीं करता - अन्यथा यह #962 जैसी समस्या की ओर जाता है

पार्टकीपर मानता है कि इसमें कार्यात्मक इंटरनेट कनेक्टिविटी है।

इस समस्या को हल करने के लिए, मैंने निम्नलिखित किया:
1) मैंने निम्न आदेश के साथ php7.2 की स्थापना रद्द की:
उपयुक्त-php7.2 निकालें *

2) मैंने तब php7.1 स्थापित किया (php7.1 सॉफ़्टवेयर पैकेज अब डिफ़ॉल्ट Ubuntu 18.04.1 कॉन्फ़िगर किए गए रिपॉजिटरी पर उपलब्ध नहीं हैं)

Php7.1 को कैसे स्थापित करें, इस पर निर्देशों के लिए कृपया निम्न साइट देखें:
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

मैं भी वही लक्षण देख रहा हूं, लेकिन यहां कोई भी चर्चा मेरी स्थिति पर लागू नहीं होती है। कुछ जानकारी:

• त्रुटि 2 मिनट के बाद बहुत अधिक दिखाई देती है (जैसा कि @FinalHopee ने भी टिप्पणी की थी), हालांकि मैंने max_execution_time को 240 s पर सेट किया है (मैंने इसे phpinfo.php के साथ भी चेक किया है)
• उपयोग में कोई प्रॉक्सी सर्वर नहीं है। चूंकि @FinalHopee ने केबल को प्लग आउट करके इसे काम किया है, इसलिए मैंने अपने राउटर में आईपी को फ़िल्टर करके अस्थायी रूप से इंटरनेट एक्सेस में कटौती की, लेकिन इससे कोई फर्क नहीं पड़ा।
• मैं एक रास्पबेरी पाई का उपयोग कर रहा हूँ 2
• स्थापित php संस्करण 7.0 . का है
• Setup.log फ़ाइल में "डिप्रिकेटेड" के अलावा कोई अन्य त्रुटियाँ नहीं हैं, जिन्हें अन्य लोग भी देखते हैं।

कोई विचार है कि मैं इस मुद्दे को हल करने की कोशिश कैसे जारी रख सकता हूं? मेरा अब तक का एकमात्र अनुमान यह है कि वैसे भी 2 मिनट का समय समाप्त होता है, जो विशेष रूप से आरपीआई के लिए बहुत कम है।

अग्रिम में धन्यवाद!

मैंने इसे समय दिया, और यह ठीक 2 मिनट है, दूसरे पर

मेरा भी यही विचार है :(
एक पर्यायवाची NAS पर स्थापित।
NAS-OS में कुछ ट्यूनिंग के बाद सभी सेटअप भाग ठीक से चल रहे हैं।
लेकिन, "कैश को गर्म करने" पर यह लगभग 2 मिनट के बाद विफल हो जाता है।

• अपाचे 2.2 और 2.4 का परीक्षण किया गया
• PHP 5.6, 7.0 और 7.2 परीक्षण किया गया
• PHP टाइमआउट वास्तव में बड़े मूल्यों तक बढ़ गया
• परिवर्तन के बाद phpinfo के साथ सेटिंग्स का परीक्षण किया गया
• "/usr/local/etc/apache24/conf/httpd24.conf" में "टाइमआउट 600" शामिल है

इसे काम करने का कोई तरीका नहीं - यह थोड़ा निराशाजनक है ...

मुझे लगता है कि इंस्टॉलेशन ट्रफ को एसएसएच कमांडलाइन चलाने के लिए हल किया जा सकता है।
हो सकता है कि आपको इस सूत्र को पढ़कर कोई समाधान मिल जाए
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
मैंने इसे एक Synology पर चल रहा है, और उसी समस्या का सामना किया है।

मैं आज इस मुद्दे में एक नई स्थापना (फ्रीबीएसडी 11, पीएचपी 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.

अब मैं अगली त्रुटि डीबग कर रहा हूं ... जो एपीसीयू पिछड़ा संगतता कार्यों से संबंधित प्रतीत होता है।

बस इसी मुद्दे में भाग गया (उबंटू 16.04, PHP 7.0, अपाचे 2.4.18 पर)
मैनुअल कैश: वार्मअप काम करता है (उपरोक्त पोस्ट देखें), लेकिन वेब यूआई के माध्यम से वार्मअप विफल रहता है
php-apcu-bc स्थापित करना विफल रहता है: 'कोई स्थापना उम्मीदवार नहीं है'

मैं ubuntu 18.04 पर इंस्टाल करने का पुनः प्रयास करूंगा

@thijz आपकी समस्या में एक (आगे) प्रॉक्सी शामिल है, जिससे आप बच नहीं सकते हैं?

मेरे nginx रिवर्स प्रॉक्सी में 60 सेकंड का डिफ़ॉल्ट टाइमआउट था, इसलिए यह मुझे ट्रिप कर रहा था। मुझे बिल्कुल नहीं बेचा गया है कि यह एक पार्टकीपर मुद्दा है, हालांकि। वास्तव में प्रॉक्सी कॉन्फ़िगरेशन समस्या की तरह दिखता है।

उचित प्रॉक्सी टाइमआउट मूल्यों को संबोधित करना मेरे लिए निश्चित चीजें हैं।

संदर्भ: https://www.smashinglab.com/fix-504-gateway-time-nginx/

हाय दोस्तों! मैं इस बग में जोड़ना चाहता हूं। मैं ऑरेंजपी पर पार्टकीपर स्थापित कर रहा हूं (जो हर तरह से तेज नहीं है) जहां कैश वार्म अप में 2.5 मिनट लगते हैं (और max_execution_time को 3 मिनट पर सेट किया जाता है)। हालांकि, जैसा कि मैं इसे समझता हूं, 2 मिनट का टाइमआउट कहीं फ्रंटएंड में सेट है:

स्क्रीनशॉट पर आप 2 वार्मअप कैश अनुरोध देख सकते हैं, एक सेटअप प्रक्रिया के दौरान बनाए गए वेब इंटरफेस से, दूसरा क्रोम देवटूल के माध्यम से मैन्युअल रूप से बनाया गया। पहला 2 मी पर रद्द हो जाता है, दूसरा 2.5 मिनट के बाद सफल हो जाता है (और ठीक हो जाता है)। इसलिए, जबकि कैश वार्मअप काम करता है, फ्रंटएंड पूरा होने से पहले अनुरोध को समाप्त कर देता है। क्या जेएस पक्ष पर टाइमआउट बढ़ाने का कोई तरीका है?

हाँ, समय समाप्त यहाँ है: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
पता नहीं इस अनुरोध के लिए इसे सही तरीके से कैसे बदला जाए, हालांकि

विंडोज़ पर विकास डॉकर छवि स्थापित करने का प्रयास करते समय मैंने यही समस्या देखी (डॉकर डब्ल्यू/डब्लूएसएल 2 का उपयोग करके, जिसमें फ़ाइल सिस्टम का प्रदर्शन बहुत खराब है)। लॉग इंगित करते हैं कि सर्वर पक्ष अंततः एक सफल प्रतिक्रिया लौटा रहा है, लेकिन UI प्राप्त होने तक पहले ही त्रुटिपूर्ण हो चुका है, जैसा कि @positron96 ने संकेत दिया है।

मैं यह देखने के लिए @positron96 के पुल अनुरोध का परीक्षण और परीक्षण करूंगा कि यह इस उपयोग के मामले के लिए काम करता है या नहीं।