लाइव साइट खाली दृश्य में या लोडिंग पर रखें और कभी लोड न करें

Question

मैं Magento में कभी सबसे अजीब समस्या का सामना कर रहा हूँ। हम 1.9.0 संस्करण का उपयोग कर रहे हैं।

पिछले 2 महीनों से, हमारी लाइव साइट उपयोग किए गए ब्राउज़रों के लिए "रिक्त" या "लोड करना जारी रखें" है। इस ब्राउज़र के माध्यम से हमने बहुत बार साइट का दौरा किया।

कुछ ब्राउज़रों में, इसका काम ठीक है। कुछ खाली दिखा।

लेकिन बैकएंड सभी ब्राउज़रों में ठीक काम कर रहा है।

हम क्रोम, मोज़िला, ओपेरा और अन्य सभी ब्राउज़रों में समस्या का सामना कर रहे हैं ।

1) अगर हम ब्राउजर हिस्ट्री [कैशे और कूकीज] को उसके काम करने से साफ करते हैं।

2) यदि हम एक ही साइट को निजी विंडो में खोलते हैं, तो इसका कार्य।

3) यदि हम नए सिरे से स्थापित ब्राउज़रों में साइट खोलते हैं, तो कुछ समय के लिए काम करना। फिर से खाली होने के बाद हमने साइट का उपयोग किया।

4) यदि हम var / सत्र फ़ोल्डर को साफ़ करते हैं, तो इससे कुछ समय के लिए सभी ब्राउज़रों के लिए काम करना शुरू हो जाएगा। फिर से साइट खाली।

5) कभी-कभी, साइट लोड होती रहेगी और यह कभी लोड नहीं होगी ...।

मैंने system.log & अपवाद . log की जाँच की । लेकिन लगता है कि इससे संबंधित कोई त्रुटि नहीं हैं। हम सुरक्षित पृष्ठों के लिए https का उपयोग कर रहे हैं । यहां तक ​​कि हमारे पास इस साइट के लिए लाइव एंड्रियाड ऐप भी है । कभी-कभी हमें घातक त्रुटियाँ मिलेंगी:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

हमने php.ini में memory_limit = 1512 Mb निर्धारित किया है

, .htaccess में हमारे पास फाइलें हैं।

php_value memory_limit 1512M php_value max_execution_time 18000

हमने इसे अनसुना कर दिया:

ini_set('display_errors', 1);

लेकिन दृश्यपटल में प्रदर्शित होने में कोई त्रुटि नहीं है। यह अपाचे त्रुटि लॉग है:

चाइल्ड पीआईडी ​​23845 एग्जिट सिग्नल सेग्मेंटेशन फॉल्ट (11), संभव कोरडंप इन / आदि / अपाचे 2

वास्तव में इस समस्या को हल करने के लिए संघर्ष कर रहा है। क्या यह समस्या हमारे कोड से संबंधित है या यह समस्या सर्वर साइड से संबंधित है?

क्या ब्राउज़र कुकी मुख्य समस्या है? यदि ऐसा है तो सभी ब्राउज़र के लिए इस कुकी समस्या को हल करने के लिए क्या करने की आवश्यकता है। क्यों हम सत्र फ़ोल्डर साफ़ करने के बाद काम शुरू कर दिया?

अपनी साइट ब्राउज़ करते समय हम इन मुद्दों का सामना करते हैं।

Comments

क्या यह संभव है कि इसका कुकी मुद्दा हो? stackoverflow.com/questions/15491819/…

— pzirkind 19

लिंक जो मैंने पेस्ट किया है वह बैकएंड के लिए है, लेकिन फ्रंट में एक कुकी मुद्दा भी हो सकता है ... यह कुकी के जीवनकाल के कारण हो सकता है और सर्वर का टाइमस्टैम्प बंद है

— pzirkind

@pzirkind हमारे मामले में बैकएंड सभी ब्राउज़रों के लिए ठीक है। की तुलना में हमें कोड के माध्यम से कुकी के जीवनकाल को बढ़ाना होगा? और मुझे सर्वर के टाइमस्टैम्प के बारे में नहीं मिला। क्या हमें इसे बनाना है?

— मैगेंटो में बेबी

Magento में @ कभी-कभी अगर सर्वर में सही टाइमस्टैम्प नहीं है तो यह एक कुकी उत्पन्न करेगा जो वर्तमान तिथि से पहले समाप्त हो जाती है, इसलिए जब ग्राहक साइट को फिर से लोड करता है और Magento कुकी को इसकी अवैध जाँच करता है

— pzirkind 20

@pzirkind क्या कोई संभावना है कि प्रश्न या टाइमस्टैम्प में पोस्ट की गई अपाचे त्रुटि इस रिक्त पृष्ठ का कारण हो सकती है?

— मैगेंटो में बेबी

Answer 1

अपनी .htaccessफ़ाइल में पहले डेवलपर मोड सक्षम करें , फ़ाइल के अंत में निम्नलिखित जोड़ें:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

अगला संपादित करें index.phpऔर लाइन को अनलिम करें :

#ini_set('display_errors', 1);

संदर्भित लाइन:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

SSH के माध्यम से अगला लॉगिन करें और /tmpबताए गए खंड त्रुटि त्रुटि के तहत एक कोर डंप फ़ाइल देखें । कभी-कभी यह मूल /या साइट के मूल निर्देशिका में भी हो सकता है उदाहरण के लिए /var/www/html/videomergerapp/:।

यदि आप किसी भी कोर डंप फ़ाइलों का पता लगाने में असमर्थ हैं, तो आप PHP / Apache में कुछ अतिरिक्त निर्देश जोड़ना चाह सकते हैं।

यहाँ एक नज़र रखना:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

आपके पास कोर डंप फ़ाइल (एस) होने के बाद, आप उपयोग कर सकते हैं gdb(यदि --enable-debug) PHP का कॉन्फ़िगर होने पर उपयोग किया गया था। आप कमांड लाइन से निम्नलिखित जारी करके यह निर्धारण कर सकते हैं:

php -i | grep debugया बस अपने वेबसर्वर रूट में php स्क्रिप्ट फ़ाइल बना रहा है: <?php phpinfo(); ?>इसकी सामग्री में और PHP कॉन्फ़िगरेशन मानों को देखने के लिए वेब ब्राउज़र के माध्यम से फ़ाइल देखें।

• https://bugs.php.net/bugs-generating-backtrace.php

यदि इसे सक्षम नहीं किया गया था, तो आप PHP में ही पूर्ण बैकट्रेस प्राप्त नहीं कर पाएंगे, लेकिन केवल उच्च स्तरीय सिस्टम कॉल और / या अपाचे बैकट्रेस:

यदि आपके पास कोर डंप फ़ाइल तक पहुंच है, तो निम्न जैसा कुछ जारी करने से आपको विफलता के बिंदु को खोजने में मदद करने के लिए बैकट्रेस मिलेगा:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

---

यदि आप केवल फ्रंटएंड पर बेतरतीब मुद्दों का सामना कर रहे हैं और बैकएंड कभी नहीं कर रहे हैं, तो अधिकांश संकेत आपके टेम्पलेट कोडिंग के साथ संभावित मुद्दे की ओर इशारा करते हैं। एक बार जब आप खाली पृष्ठों का अनुभव करते हैं (और / या त्रुटि प्रदर्शित करता है यदि आपने डेवलपर मोड और त्रुटि प्रदर्शन सक्षम किया है)। अपने व्यवस्थापक को लॉगिन करें और सभी कैश को अक्षम करें और सभी कैश और कैश स्टोरेज को फ्लश करें।

तब जाकर app/etc/local.xmlनिष्क्रिय स्थानीय मॉड्यूल को सही पर सेट करें।

<disable_local_modules>true</disable_local_modules>

यह किसी भी मॉड्यूल को लोड करने से ऑटो लोडर को निष्क्रिय कर देगा app/code/local।

सामुदायिक मॉड्यूल को अक्षम करने के लिए अपने प्रत्येक मॉड्यूल परिभाषा फ़ाइलों के माध्यम से जाना आसान है app/etc/modulesऔर सक्रिय नोड को झूठे की तरह सेट करके अक्षम करना है:

<active>false</active>

इस तरह से आप यह पता लगाने में मदद कर सकते हैं कि क्या कोई तीसरा पक्ष मॉड्यूल उन्मूलन की प्रक्रिया द्वारा मुद्दे के स्रोत का कारण बन रहा है। नोट: आप disable_local_modulesअपने सभी गैर- मॉड्यूल मॉड्यूल (कुछ भी Mage_ * उपेक्षा!) के माध्यम से नहीं जा सकते ।

अगर अभी भी कोई समस्या है तो मैं सिस्टम> डिज़ाइन पर जाकर डिफ़ॉल्ट टेम्पलेट या बेस जैसी किसी नई डिज़ाइन को परिभाषित करके अस्थायी रूप से डिफ़ॉल्ट टेम्पलेट पैकेज का प्रयास करूँगा। यदि स्टॉक टेम्प्लेट पैकेज काम करते हैं तो आपको पता चलेगा कि त्रुटि का कारण आपके टेम्पलेट डिज़ाइन फ़ाइलों (.phtml) में रह रहा है।

बहुत सारे टेम्प्लेट जो मैंने चलाए हैं, वे Mage::getModel()->load()फ़ोरम लूप के भीतर उपयोग करने के बारे में बुरे हैं क्योंकि यह बुरा अभ्यास है और अंततः बड़ी मात्रा में सर्वर मेमोरी और संसाधनों का उपभोग कर सकता है।

Magento के पास कोड विश्लेषण उपकरण है जो आपकी टेम्पलेट फ़ाइलों को स्कैन करने में मदद कर सकता है ताकि यह निर्धारित किया जा सके कि इनमें से कोई भी खराब कोड है:

• https://github.com/magento-ecg/magniffer

आगे की पढाई:

• एक Magento दुकान डिबगिंग के लिए बुनियादी बातों

इसके अलावा, यह उन सभी के लिए मददगार हो सकता है कि आप जो कैश और सेशन स्टोरेज का उपयोग कर रहे हैं वह किसमें परिभाषित है app/etc/local.xml।

उम्मीद है की यह मदद करेगा!

Comments

मैं कोशिश करूँगा कि यह नाद आपको बता दे ....

— में बेबी

हमने var / session फोल्डर को क्लियर किया। इससे आज तक हमारी समस्या हल हो गई है। लेकिन आज फिर यह समस्या हो गई। की तुलना में मैंने इसे जोड़ा है। यह रेखा। और <disable_local_modules> true </ disable_local_modules>। क्या मुझे tjis त्रुटि मिली: magento.stackexchange.com/questions/94559/…

— Magento में बेबी

मैं कुछ चेंजेस करने के बाद किसी भी सेसिन को क्लीयर नहीं कर रहा हूं, अगर मैं सेशन को अपने आप ही क्लियर कर दूं तो सारी प्रॉब्लम सॉल्व हो जाएगी। क्या आपको लगता है कि इसके कुछ संबंधित कुकीज़ या सत्र नहीं हैं? क्या इसका हल करने का कोई तरीका है ?

— मैगेंटो में बेबी

@BabyinMagento क्या आप प्रदान की गई जानकारी के आधार पर समस्या को हल करने में सक्षम थे? यदि हां, तो उन लोगों के लिए क्या समस्या थी जो एक समान मुद्दे का अनुभव कर रहे थे? धन्यवाद।

— B00MER

आपकी सहायता के लिए धन्यवाद। हमने सत्र फ़ोल्डर को साफ़ किया और कुकी संबंधित चीजों को varien.php में छिपाया। लेकिन फिर भी हमें यह देखने के लिए कुछ और समय की प्रतीक्षा करने की आवश्यकता है कि हमें स्थायी समाधान मिला या नहीं। जैसे ही हमने सत्र फ़ोल्डर को मंजूरी दी, हमें समाधान मिल गया।

— मैगेंटो में बेबी

Answer 2

मेरा अनुमान है कि आपके कोड में एक पुनरावृत्ति है। फ़ाइल को संपादित करें lib/Varien/Db/Adapter/Pdo/Mysql.phpऔर सेट करें $_debugऔर $_logCallStackसच करें। यह var/debug/pdo_mysql.logफ़ाइल में कॉल स्टैक को लॉग इन करना चाहिए जो आपको एक विचार देना चाहिए कि क्या आपके कोड में एक पुनरावृत्ति होती है जब इसे लोड करने के लिए हमेशा के लिए लेता है। ध्यान दें कि यह फ़ाइल बहुत तेज़ी से बढ़ती रहेगी इसलिए आदर्श रूप से इसे सक्षम करें जब आपको लगता है कि समस्या साइट पर शुरू हो गई है।

अन्य तरीका यह है कि आपको लगता है कि यह कारण हो सकता है कि छोटी गाड़ी मॉड्यूल / एक्सटेंशन को अक्षम करना है। यह आपके साधारण विन्यास योग्य मूल्य विस्तार भी हो सकता है, इसे अस्थायी रूप से अक्षम करने का प्रयास करें और देखें कि क्या यह समस्या को रोकने में मदद करता है।

Comments

मैंने "$ _debug" और "$ _logCallStack" के मूल्यों को सच में बदल दिया है, अब मैं pdo_mysql.log फ़ाइल की प्रतीक्षा कर रहा हूं। और हमारे लॉग फोल्डर बहुत अधिक भर रहे हैं, इसके लगभग 90 gb लॉग हैं। मैंने 2 सप्ताह से पहले सरल विन्यास एक्सटेंशन स्थापित किया, यह समस्या 2 महीने से थी। लेकिन अभी भी अन्य छोटी गाड़ी मॉड्यूल को देखने की जरूरत है।

— में बेबी

मुझे अब तक यह फ़ाइल var / debug / pdo_mysql.log नहीं मिली, लेकिन सिस्टम और अपवाद लॉग बनाए गए। मैं इस लॉग को मुख्य रूप से देख सकता हूं: "lib / Varien / Simplexml / config.php ऑन लाइन 510"

— बेबी Magento में

90 जीबी लॉग? वाह! उन्हें कुछ अलग जगह पर बैकअप दें और फाइलें खाली करें। कम से कम आपकी साइट की गति को बेहतर बनाने में कुछ मदद करनी चाहिए।

— कल्पेश

हाँ आप सही है। हम कुछ समय बाद हटाते रहते हैं। क्या इस समस्या के कारण वे लॉग हैं? और अब तक मुझे कोई pdo_mysql.log नहीं मिला

— बेबी Magento में

$_debugFileMysql.php फ़ाइल के मूल्य की जाँच करें और सुनिश्चित करें कि आपकी varनिर्देशिका में फ़ोल्डर और फ़ाइल बनाने के लिए उचित अनुमतियाँ हैं।

— कल्पेश

Answer 3

मैं एक ग्राहक वेबसाइट में एक ही मुद्दा था। मैलवेयर के लिए अपने Magento की जाँच करें।

यह एक प्रसिद्ध परिदृश्य है, ususally यह एक वॉलवेयर है जो उपयोगकर्ता की पोस्ट की सामग्री को बाहरी वेबसाइट पर पुनर्निर्देशित करता है।

Index.php की जाँच शुरू करें, वे आमतौर पर इसे हैक करते हैं। कोड को अंत तक स्क्रॉल करें, लाइसेंस हेडिंग में दाईं ओर और टिप्पणी की गई लाइनों के बीच भी जांच करें। इस तरह से कोड को छिपाने के लिए हैकर्स का इस्तेमाल किया जाता है।

आपके पास "हमेशा के लिए लोड हो रहा है" क्योंकि यह उन वेबसाइटों से संपर्क करने की कोशिश करता है जिन्हें आपके आईएसपी ने अवरुद्ध किया है।

मैलवेयर को खोजने के लिए काफी आसान होना चाहिए, "बेस 64", "ईवैल", "एमसीट्रिप" स्ट्रिंग्स की खोज करें।

Comments

यह हमारा सूचकांक है। php => pastebin.com/N8xnWMa7

— बेबी

हमारी साइट को 3 महीने से पहले हैक कर लिया गया था, उसके बाद ही यह समस्या आई। लेकिन बाद में हमने सर्वर की तरफ से सुरक्षा के कई उपाय किए। लेकिन क्या आपको लगता है कि हैक किया गया कोड अभी भी साइट में मौजूद है और समस्या पैदा कर रहा है ?।

— में बेबी

ठीक है, आपका index.php ठीक है, लेकिन आपके लक्षण वास्तव में उसी तरह हैं जैसे मैंने कुछ ग्राहक हैक किए गए वेबिस्टों में देखे हैं। मैं आपको निम्नलिखित पैटर्नों की तलाश में एक पूर्ण खोज करने का सुझाव देता हूं: "बेस 64", "ईवैल", "एमक्रिप्ट", "$ _POST"। वे आपको झूठी सकारात्मकता के टन देंगे ताकि आपको उनकी जांच करने की आवश्यकता हो। अगर आपको कुछ भी गलत नहीं लगता है तो मैं आपको एक कैशगाइंड विश्लेषण या एक्सडेबग चरण-दर-चरण विश्लेषण का सुझाव देता हूं।

— फीनिक्स128_रीकॉर्डो 20

मैं हमारी साइट फ़ाइलों में उन शब्दों को खोजूंगा।

— में बेबी

मैं असीमित समय पा रहा हूँ: "बेस 64" एनकोड और डिकोड ग्रंथों ........

— बेबी में Magento

Answer 4

मैंने एक Magento पर एक समान व्यवहार का अनुभव किया है जिसमें दो वेबसाइट थीं। साइट कुछ पृष्ठों के लिए अच्छी तरह से लोड हो रही थी और फिर हमेशा के लिए लोड हो रही थी।

आधार URL का विन्यास गलत था। सुरक्षित आधार URL सेटिंग गलत वेबसाइट पर सेट की गई थी, जबकि असुरक्षित आधार URL सही तरीके से सेट किया गया था।

तो इसे ठीक करने के लिए यदि व्यवस्थापक ठीक से काम नहीं कर रहा है, तो मानों को सही वेबसाइट के लिए core_config_data तालिका में बदलने की आवश्यकता है अर्थात "http: //" के साथ सही URL सेट करें और मूल्य फ़ील्ड में एक अनुगामी स्लैश इसी पथ "वेब / असुरक्षित / base_url" और "वेब / सुरक्षित / base_url" वेबसाइट आईडी का प्रतिनिधित्व करने के लिए सही गुंजाइश_id के लिए।

ध्यान दें कि सुरक्षित यूआरएल केवल http है क्योंकि यह एक डेमो वेबसाइट थी।