PHP एक हटाए गए सत्र फ़ाइल को लॉक कर रहा है

Question

हमारे PHP एप, अपाचे के तहत चल रहा है, मौलिक रूप से हटाए गए सत्र फ़ाइल को लॉक करने का प्रयास कर रहा है, यह अपाचे प्रक्रिया को लटकता है और अंततः हम प्रक्रियाओं से बाहर हो जाते हैं।

सबूत:

strace : flock(89, LOCK_EX     -----stuck in flock for File Descriptor 89 

और उसके बाद:

lsof, एक ही प्रक्रिया के लिए:

httpd 22161 apache 89u ... /var/lib/php/session/sess_mf7svvirg7rbu9l0m5999pm6h4 (deleted) 

ऐसा क्यों हो रहा है के रूप में कोई भी विचार? और हम इसे रोकने के लिए क्या कर सकते हैं?

Answer 1

आपके मामले के लिए क्यों कोई विचार नहीं है।

यह question कुछ अच्छे सुझाव मिल गया है ...

आप वातावरण फिर से स्थापित करने, या एक अलग सर्वर में जाने की कोशिश की? यदि आप डिफ़ॉल्ट सत्र हैंडलर को ओवरराल करते हैं और fopen ($ file, 'x') के बजाय fopen ($ file, 'w') का उपयोग करते हैं, तो यह काम करेगा?

डेटाबेस के आधार पर एक सत्र हैंडलर को लागू करने का कामकाज, उदाहरण के लिए "php और mysql सत्र हैंडलर" सेट करने के लिए एक लाख या तो मार्गदर्शिकाएं हैं।

Answer 2

क्या सत्र फ़ाइल को हटाने के लिए कोई जबरदस्त (क्लाइंट) आवश्यकता है? आपको ऐसा नहीं करना चाहिए। PHP स्वयं निष्क्रिय सत्र फ़ाइलों को हटाने के लिए एक कचरा संग्रह तंत्र लागू करता है। यह किसी भी चीज की तुलना में much more efficient होने जा रहा है जिसे आप PHP का उपयोग करके स्वयं लिख सकते हैं।

आप उपयोग कर सकते हैं:

1. session_destroy - सभी डेटा एक सत्र
2. session_unset करने के लिए पंजीकृत नष्ट कर देता है - नि: शुल्क सब सत्र चर

और session_start) फिर से (।

और देखें here।

अद्यतन:

पीएचपी एक बहुत साफ स्क्रिप्टिंग इंजन है, जो आपके सिस्टम पर कोई कचरा छोड़ देता है! सत्र-समय-सीमा समाप्त होने के बाद सत्र फ़ाइलों को स्वचालित रूप से हटा दिया जाता है। session-timeout आपके सिस्टम के साथ ऐसा हो सकता है जो मुझे लगता है। इसलिए यदि टाइम-आउट 20 मिनट तक सेट हो गया है, तो अंतिम पहुंच के 20 मिनट बाद फ़ाइलों को हटा दिया जाएगा। कुकी के लिए वही। हर बार, एक पृष्ठ का अनुरोध किया जाता है, कुकी-टीटीएल अब + 20 मिनट पर सेट है।

configuration directives में से कुछ को देखें। बाधाएं हैं कि आपने gc_maxlifetime को बहुत उच्च मूल्य पर सेट किया है, और वे स्वचालित रूप से एकत्र होने के लिए "समाप्ति" सीमा तक नहीं पहुंच पाए हैं। आपको यह सुनिश्चित करने के लिए अपने अनुप्रयोगों की जांच करनी चाहिए कि वे रनटाइम के दौरान सत्र सेटिंग्स (ini_set() का उपयोग करके) के लिए अजीब मान सेट नहीं कर रहे हैं।

PHP में एक आंतरिक एल्गोरिदम है जो session_start() पर चलता है जो यह तय करता है कि उसे कचरा सफाई चलाने और पुराने सत्र फ़ाइलों को निकालना चाहिए या नहीं।प्रदर्शन कारणों से, मेरा मानना ​​है कि प्रत्येक बार रन करने का डिफ़ॉल्ट मौका 1% है, इसलिए औसत पर प्रत्येक 100 session_start() कॉल में एक बार कचरा-संग्रह दिनचर्या शुरू हो जाएगी। यदि आपको लगता है कि यह पर्याप्त नहीं है, तो आप gc_divisor को 1.

Answer 3

पर सेट कर सकते हैं यह शायद आपके मामले के लिए कुछ और कामकाज है, लेकिन आप सिस्टम सिस्टम से सत्रों को पूरी तरह से माइग्रेट क्यों नहीं करते डेटाबेस में?

आप यहां और जानकारी मिल सकती है http://php.net/manual/en/function.session-set-save-handler.php

Answer 4

क्या आप उन 2 खुला कीड़े पढ़ने की कोशिश की?

https://bugs.php.net/bug.php?id=47640 https://bugs.php.net/bug.php?id=32092

कोशिश अपने अंतिम पंक्ति के रूप session_write_close() (बदसूरत काम के आसपास) कॉल करने के लिए या PHP उन्नत करने के लिए।

Answer 5

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

1. /page1.php ठीक कार्यान्वित:

   मेरे मामले में, यह दो लिपियों के बीच एक ही सत्र फाइल करने के लिए पहुँच के लिए एक रेस स्थिति थी। इसमें जावास्क्रिप्ट शामिल है जो XMLHttpRequest को /background.php पर करता है।

2. जब /background.php एक्सेस किया गया है तो यह readfile(http://remote.url) चलाता है, जो एक अस्तित्वहीन यूआरएल है।
3. /page2.php पर नेविगेट करते समय स्क्रिप्ट रुक गई है। एक स्ट्रेस flock(89, LOCK_EX दिखाता है, और lsof इंगित करता है कि यह सत्र फ़ाइल पर पढ़ने/लिखने के उपयोग की प्रतीक्षा कर रहा है।

इस परिदृश्य में, दोनों /page2.php और /background.php दोनों एक ही सत्र फ़ाइल पर इंतजार कर रहे हैं, लेकिन बाद तो, क्योंकि यह समय समाप्ति के readfile() के लिए इंतज़ार कर ऊपर आयोजित किया गया था करने में असमर्थ था। मैं एक php_error_log में यह मिल गया:

PHP Warning: readfile(http://remote.url): failed to open stream: Connection timed out in […]/background.php on line […] 

तो समस्या कथित अपराधी से एक बिल्कुल अलग स्क्रिप्ट के साथ किया गया था।

आप grepping सभी php सत्र फ़ाइल को देखने के लिए खोली गई फ़ाइलों से जल्दी से इस समस्या के लिए जाँच कर सकते हैं जो httpd प्रक्रिया यह उपयोग कर रहा है:

$ sudo lsof | grep sess_it9q6kkvf83gcj72vu05p9fcad7 
httpd  31325 apache 74u  REG    8,5  410 11634061 /var/lib/php/session/sess_it9q6kkvf83gcj72vu05pfa543 
httpd  31632 apache 74uW  REG    8,5  410 11634061 /var/lib/php/session/sess_it9q6kkvf83gcj72vu05pfa543 

तो दो httpd प्रक्रियाओं एक ही सत्र फ़ाइल तक पहुँच रहे हैं, शायद इस तुम्हारी समस्या है अब आप जाँच कर सकते हैं क्या उन प्रक्रियाओं strace के साथ कर रहे हैं, या मेरे मामले में यह उपयोग करने के लिए पर्याप्त था apachectl fullstatus:

$ sudo apachectl fullstatus | grep 31632 
5-7 31632 0/1/1169 _ 0.05 6  30692 0.0 0.02 3.45 111.222.333.444 www.example.com.com  /background.php