सत्र_स्टार्ट

Question

कुछ घंटों से लटकता है जब भी सर्वर सत्र_स्टार्ट करते समय हर बार लटकता है।

परीक्षण प्रयोजनों के लिए मैं एक स्क्रिप्ट जो इस तरह दिखता बनाया:

<?php 
session_start(); 
?> 

सांत्वना रुक जाता है से यह कॉलिंग और यह भी, साथ Ctrl-C रोका नहीं जा सकता केवल मारने -9 काम करता है। अपाचे के माध्यम से इसे कॉल करने के लिए वही। /var/lib/php/session/ खाली रहता है लेकिन अनुमतियां बिल्कुल ठीक हैं, www लिख सकते हैं और सभी मूल फ़ोल्डर्स के लिए अनुमतियां भी पढ़ सकते हैं।

व्यवस्थापक के मुताबिक सर्वर पर कोई बदलाव नहीं आया और सत्रों के लिए कोई विशेष कोड पंजीकृत नहीं है। सर्वर CentOS 4 या 5 है और कल सब कुछ पूरी तरह से काम कर रहा था। हमने सर्वर को रिबूट किया और PHP अपडेट किया, लेकिन कुछ भी नहीं बदला।

मैं विचारों से बाहर हो गया हूं, कोई सुझाव?

अद्यतन

हम इसलिए जब समस्या अभी भी एक सर्वर पर मौजूद है वहाँ एक समाधान के लिए कोई तात्कालिक जरूरत अब और है, अन्य सर्वर पर परियोजना को ले जाकर इस समस्या का समाधान। यदि किसी के पास भविष्य में ऐसी ही समस्या होने वाले लोगों के लिए कोई विचार है, तो मैं प्रश्न को खुला रखूंगा।

Answer 1

, उस के लिए कई कारण हैं उनमें से कुछ हैं:

ए सत्र फ़ाइल विशेष रूप से खोला जा सकता है। जब किसी भी कारण से फ़ाइल लॉक ठीक से रिलीज़ नहीं होता है, तो यह किसी भी भावी स्क्रिप्ट निष्पादन पर असीमित रूप से लटकने के लिए session_start() का कारण बन रहा है। वर्कअराउंड: session_set_save_handler() का उपयोग करें और सुनिश्चित करें कि लिखने समारोह fopen($file, 'w') instead of fopen($file, 'x')

बी का उपयोग करता है अपने php.ini फ़ाइल में निम्नलिखित (entropie फ़ाइल "/dev/random" करने के लिए) का उपयोग कभी नहीं, यह आपके session_start() लटका कारण होगा बनाने:

<?php 
ini_set("session.entropy_file", "/dev/random"); 
ini_set("session.entropy_length", "512"); 
?> 

सी session_start() में लिखने के लिए एक निर्देशिका की जरूरत है।

आप एक सामान्य उपयोगकर्ता खाते में अपाचे प्लस PHP चला सकते हैं। अपाचे को निश्चित रूप से 80 से अधिक पोर्ट (उदाहरण के लिए, 8080) सुनना होगा।

निम्नलिखित बातें करने के लिए सुनिश्चित करें: - एक अस्थायी निर्देशिका PREFIX/tmp बना सकते हैं - PREFIX/lib में डाल php.ini - संपादित php.ini और निर्देशिका तुम सिर्फ

अन्यथा बनाया session.save_path निर्धारित करते हैं, अपनी स्क्रिप्ट लगेगा session_start() पर 'लटका' करने के लिए।

Answer 2

मेरे साथ यह एक अजीब मुद्दा था।

मैं CentOS 5.5x64, PHP 5.2.10-1 का उपयोग कर रहा हूं। रूट में एक स्वच्छ एएनएसआई फ़ाइल session_start() के अलावा कुछ भी नहीं लटक रही थी। सत्र डिस्क पर लिखा जा रहा था और कोई त्रुटि नहीं फेंक दी गई थी। यह बस लटका हुआ है।

मैं Thariama ने सुझाव दिया सब कुछ करने की कोशिश की, और जाँच पीएचपी संकलन सेटिंग्स आदि

मेरे फिक्स:

yum reinstall php; /etc/init.d/httpd restart 

आशा इस कोई मदद करता है।

हर किसी को डाउनटाइम के 30 सेकंड के बारे में शिकायत करने के लिए अस्वीकार्य होने के कारण, यह एक ब्रांड नई, स्वच्छ ओएस इंस्टॉल, एक चल रही उत्पादन मशीन पर एक अतुलनीय मुद्दा था। इस समाधान का उपयोग उत्पादन वातावरण में नहीं किया जाना चाहिए।

Answer 3

इस मदद करता है, तो:

मेरी परिदृश्य में, session_start() एक ही समय में लटक रहा था मैं PHPStorm, आईडीई के भीतर XDebug डिबगर उपयोग कर रहा था, विंडोज पर। मैंने पाया कि एक स्पष्ट कारण था: जब भी मैंने पीएचपीएसटॉर्म के भीतर डीबग सत्र को मार दिया, अगली बार जब मैंने डीबग सत्र चलाने की कोशिश की, तो session_start() लटका होगा।

समाधान, यदि यह आपका परिदृश्य है, तो हर बार जब आप अपने आईडीई के भीतर XDebug सत्र को मारते हैं तो अपाचे को पुनरारंभ करना सुनिश्चित करना है।

Answer 4

समस्या : -

चतुर्थ अनुभव (और फिक्स्ड) समस्या जहां फ़ाइल आधारित सत्र अनुरोध लटका है, और डेटाबेस आधारित सत्र (प्रत्येक सत्र के भंडारण की तरह तारीख सत्र डेटा से बाहर भंडारण के द्वारा तालमेल न बिठा पाएं

गलत क्रम में सहेजें)।

यह किसी भी अनुरोध के कारण होता है जो एक सत्र (एक साथ अनुरोध) लोड करता है, जैसे AJAX, वीडियो एम्बेड जहां वीडियो फ़ाइल php स्क्रिप्ट के माध्यम से वितरित की जाती है, गतिशील संसाधन फ़ाइल (जैसे स्क्रिप्ट या सीएसएस) php स्क्रिप्ट के माध्यम से वितरित की जाती है।

फ़ाइल आधारित सत्र फ़ाइल लॉकिंग में सत्र लेखन को रोकता है जिससे एक साथ अनुरोध थ्रेड के बीच एक डेडलॉक होता है।

डेटाबेस आधारित सत्र में अंतिम अनुरोध धागा पूरा करने के लिए सबसे हालिया बचत बन जाता है, उदाहरण के लिए एक वीडियो वितरण स्क्रिप्ट पृष्ठ अनुरोध के बाद लंबे समय तक पूरा हो जाएगी और पुराने सत्र डेटा के साथ अद्यतन सत्र के बाद से ओवरराइट हो जाएगी।

ठीक: -

अपने ajax या संसाधन वितरण स्क्रिप्ट सत्र तो सबसे आसान उपयोग करने के लिए बस इसे से सत्र उपयोग दूर करने के लिए जरूरत नहीं है।

नहीं तो आप सबसे अच्छा अपने आप को एक कॉफी बनाने चाहते हैं और निम्न कार्य करें: -

1. लिखें या एक सत्र हैंडलर को रोजगार http://www.php.net//manual/en/class.sessionhandler.php (कई अन्य गूगल खोज के द्वारा उपलब्ध उदाहरण) के अनुसार (यदि पहले से ही ऐसा करने से नहीं) ।

2. अपने सत्र हैंडलर समारोह लिखने में() आगे जोड़ते कोड ...

   // processes may declare their session as read only ... 
       if(!empty($_SESSION['no_session_write'])) { 
         unset($_SESSION['no_session_write']); 
         return true; 
       } 
   

3. अपने ajax या संसाधन वितरण php स्क्रिप्ट में कोड (के बाद सत्र शुरू हो जाता) जोड़ने के ...

   $_SESSION['no_session_write'] = true; 
   

मुझे पता है यह क्या एक छोटे से ठीक किया जाना चाहिए के लिए चारों ओर भरने का एक बहुत की तरह लगता है, लेकिन दुर्भाग्य से यदि आप एक साथ अनुरोध प्रत्येक एक सत्र तो यह आवश्यक है लोड हो रहा है की आवश्यकता है।

नोट करें कि अगर आपका AJAX या संसाधन वितरण स्क्रिप्ट वास्तव में डेटा लिखने/सहेजने की आवश्यकता है, तो आपको डेटाबेस की तरह सत्र के अलावा कहीं और करने की आवश्यकता है।

Answer 5

मेरे लिए, समस्या SeLinux से उत्पन्न हुई प्रतीत होती है। सही निर्देशिका तक पहुंच प्रदान करने के लिए आवश्यक कमांड chcon -R -t httpd_sys_content_t [www निर्देशिका] था। https://askubuntu.com/questions/451922/apache-access-denied-because-search-permissions-are-missing

Answer 6

केले जाने वाले लोगों के मिश्रण में एक और जवाब फेंकने के लिए, मेरे पास केवल session_start() केवल विशेष मामलों और स्क्रिप्ट में मर रहा था। मेरा सत्र मरने का कारण आखिरकार था क्योंकि मैं विशेष रूप से गहन लिपि के बाद लॉट डेटा संग्रहित कर रहा था, और आखिरकार session_start() पर कॉल php.ini में 'memory_limit' सेटिंग को समाप्त कर रहा था।

'memory_limit' बढ़ाने के बाद, उन session_start() कॉल अब मेरी स्क्रिप्ट को नहीं मार पाए।