टैर त्रुटि: क्रोन/PHP

Question

के माध्यम से चलते समय संग्रह में अप्रत्याशित ईओएफ मेरे पास एक PHP कंसोल स्क्रिप्ट है जिसे क्रॉन के माध्यम से बुलाया जाता है जो स्वयं अन्य चीजों के बीच एक निर्देशिका की टैर फ़ाइल बनाता है।

क्रॉन के माध्यम से PHP स्क्रिप्ट को कॉल करते समय टैर फ़ाइल सही ढंग से नहीं बनाई गई है। जब टार फ़ाइल को देखने के निम्न त्रुटि दिया जाता है:

gzip: stdin: unexpected end of file 
tar: Unexpected EOF in archive 
tar: Error is not recoverable: exiting now 

जब सांत्वना टार फ़ाइल सही तरीके से बनाई गई है के माध्यम से मैन्युअल PHP स्क्रिप्ट बुला। क्रॉन लॉग आउटपुट कोई त्रुटि नहीं दिखाता है।

यहां टैर कॉल PHP स्क्रिप्ट का निर्माण करता है।

exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents"); 

खुराक किसी को पता है कि मैन्युअल रूप से कॉल किया जाता है जब क्रॉन के माध्यम से बुलाया जाता है और विफल रहता है?

अद्यतन: क्रॉन के माध्यम से टार फ़ाइल बनाते समय दिया त्रुटि है:

tar: ../../backup/20150819-060003.tar.gz: Wrote only 4096 of 10240 bytes 
tar: Error is not recoverable: exiting now 

कभी-कभी गलती से हुआ है:

tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe 
tar: Error is not recoverable: exiting now 

के रूप में, से पहले कहा था कि जब क्रॉन टार के माध्यम से मार डाला फ़ाइल बनाई गई है, लेकिन सही आकार का हमेशा 50% (जब मैन्युअल रूप से स्क्रिप्ट निष्पादित करता है):

-rw-r--r-- 1 gtz gtz 1596099468 Aug 19 06:25 20150819-042330.tar.gz <- Manually called skript, working tar 
-rw-r--r-- 1 gtz gtz 858570752 Aug 19 07:21 20150819-052002.tar.gz <- Script called via cron, broken tar 

अद्यतन 2

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

Answer 1

मुझे लगता है कि आप किसी संसाधन सीमा है के रूप में एम इवानोव ने कहा है, अपने PHP स्क्रिप्ट में इस आदेश को जोड़ें:

shell_exec("php -info"); 

और इस पैरामीटर जाँच दोनों जब आप कमांड लाइन से और से अपनी स्क्रिप्ट पर अमल क्रॉन जॉब

memory_limit => ??? 

तुम भी 1600m

को स्मृति सीमा बेहतर बना कर अपना क्रॉन चलाने का प्रयास कर सकते हैं

php -d memory_limit=1600M scriptCompressor.php 

आशा में मदद करता है :)

Answer 2

cronjobs खुद से आम तौर पर सीमा नहीं है। यदि आप साझा होस्टिंग का उपयोग कर रहे हैं तो उन्होंने कुछ लागू स्क्रिप्ट इंस्टॉल की हो सकती हैं लेकिन मुझे संदेह है कि वे आपके कंसोल बैकअप भी तोड़ देंगे।

यदि आप कुछ कंटेनर से cronjobs चला रहे हैं, उदा। Drupal, उनके पास विशेष सीमाएं हैं। सिर्फ मामले में बैकअप शुरू होने से पहले ulimit -a

रिपोर्ट डिस्क स्थान और बाद में:

इसके अलावा के साथ बैश सीमा की जाँच करें। यह आमतौर पर वीपीएस पर काफी छोटा है।

Answer 3

आप exec कॉल से बचने के लिए सीधे PHP से टैरबॉल बनाने का प्रयास करना चाह सकते हैं। यह उत्तर देखें: https://stackoverflow.com/a/20062628/5260945।

इसके अलावा, अपनी क्रॉन प्रविष्टि को देखते हुए, आपके उदाहरण पर कोई प्रमुख स्लैश नहीं है। मुझे पता है कि यह टिप्पणी के लिए सिर्फ एक टाइपो हो सकता है, लेकिन सुनिश्चित करें कि आपके पास cd कमांड के लिए एक पूर्ण पथ है। क्रॉन नौकरी के लिए डिफ़ॉल्ट वातावरण आपके लॉगिन खोल के समान नहीं है।

Answer 4

त्रुटि तब होती है जब आप php फ़ाइल निष्पादित करने का प्रयास करते हैं और EOF त्रुटि देता है। यह अपने php फ़ाइल में कहीं मतलब है कि आप अपने क्रॉन फ़ाइल के कोड यह हो सकता है आप शर्त या वर्ग आदि के कोष्ठक पूरा करने के लिए भूल जाते हैं कि ...

गुड लक [ '}

Answer 5

कि त्रुटि की जांच करना चाहिए आमतौर पर डिस्क स्थान की कमी से आता है।

मैं इस विषय पर कुछ और शोध कर रहा हूं, टैर निष्पादन से पहले और बाद में कुछ लॉग जोड़कर।

यह भी जांचें कि आपके कॉन्फ़िगरेशन का उपयोग करने वाले क्रॉन नौकरी के लिए आपकी कॉन्फ़िगरेशन किस उपयोगकर्ता का उपयोग कर रही है। यह उस उपयोगकर्ता पर कुछ कोटा सीमा भी हो सकती है, ऐसा तब नहीं होता जब आप क्रॉन के बाहर कंसोल पर चलते हैं।

उपयोगकर्ताओं के लिए और प्रक्रियाओं के लिए वीपीएस पर कोटा सीमाओं के लिए अपने प्रदाता से पूछें ... यही घंटी बजती है। जब क्रॉन के माध्यम से निष्पादित

Answer 6

लॉग त्रुटि लिखने में 2>&1 >/path/to/application/app/logs/backup-output.log द्वारा क्रॉन लाइन में >/paht/to/application/app/logs/backup-output.log की जगह भी क्रॉन लाइन में पथ की जाँच करें .. शायद परिवर्तन-निर्देशिका काम नहीं कर रहा जैसा कि आप सोच सकते हैं। Cron से php स्क्रिप्ट चलाते समय, getcwd() को लॉग या किसी चीज़ पर प्रिंट करने का प्रयास करें।

संपादित करें: मुझे आश्चर्य है कि इसे not useful क्यों चुना गया था। प्रश्नकर्ता ने उल्लेख किया कि क्रॉन स्क्रिप्ट निष्पादित करते समय लॉग में कोई त्रुटि मुद्रित नहीं होती है। कल्पना करने के लिए मुश्किल नहीं है > बस एसटीडीओयूटी को रीडायरेक्ट करता है, न कि एसटीडीईआरआर (जिस पर PHP त्रुटियों को मुद्रित किया जाएगा) लॉग पर। इसलिए 2>&1 जोड़ना कुछ नई सूचनाएं प्रकट कर सकता है।

Answer 7

मुझे यकीन है कि इसकी स्मृति या निष्पादन समय समस्या है। क्या एक चीज निर्देशिका के लिए एक ही स्क्रिप्ट चलाती है जिसमें केवल एक परीक्षण फ़ाइल होती है और आउटपुट की जांच करें, यदि आपकी स्क्रिप्ट इस परिदृश्य में काम करती है तो 100% इसकी स्मृति समस्या सुनिश्चित करें।

मेमोरी पैरामीटर को ट्विक करने और अपनी स्क्रिप्ट निष्पादित करने का प्रयास करें।

मुझे उम्मीद है कि यह आपकी मदद करेगा।

धन्यवाद

Answer 8

निम्न त्रुटि को देखते हुए।

tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe 
tar: Error is not recoverable: exiting now 

मुझे लगता है कि PHP स्क्रिप्ट में कार्यकारी समारोह को अवरुद्ध नहीं कर रहा है के रूप में या समय से पहले एक त्रुटि के कारण देखते हैं। तो कमांड खत्म होने से पहले क्रॉन जॉब के दौरान बुलाया गया PHP सत्र बाहर निकलता है। यह सिर्फ एक अनुमान है लेकिन जब आप इसे क्रॉन से चलाते हैं तो आप इसे पृष्ठभूमि में भेजने की कोशिश कर सकते हैं।

exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents &"); 

यह आदेश अवरुद्ध होना चाहिए ताकि यह अंधेरे में सिर्फ एक शॉट हो।

http://php.net/manual/en/function.exec.php