अक्सर, crontab स्क्रिप्ट शेड्यूल पर या अपेक्षित रूप से निष्पादित नहीं की जाती हैं । इसके कई कारण हैं:
गलत crontab अंकन
अनुमतियाँ समस्या
पर्यावरण चर
इस समुदाय विकी का उद्देश्य शीर्ष कारणों को एकत्र करना है crontab स्क्रिप्ट को अपेक्षित रूप से निष्पादित नहीं किया जा रहा है । प्रत्येक कारण को एक अलग उत्तर में लिखें ।
कृपया प्रति उत्तर एक कारण शामिल करें - इस बारे में विवरण कि इसे निष्पादित क्यों नहीं किया गया है - और उस एक कारण के लिए फिक्स(एस) ।
कृपया केवल क्रॉन-विशिष्ट मुद्दों को लिखें, उदाहरण के लिए कमांड जो शेल से अपेक्षित रूप से निष्पादित होते हैं लेकिन क्रॉन द्वारा गलत तरीके से निष्पादित होते हैं ।
क्रॉन आपकी नौकरियों के लिए पर्यावरण चर का एक न्यूनतम सेट पास करता है । अंतर देखने के लिए, इस तरह एक डमी नौकरी जोड़ें:
>* * * * * env /tmp/लि.आउटपुट
के लिए प्रतीक्षा करें /tmp/env.output बनाने के लिए, फिर नौकरी को फिर से हटा दें । अब की सामग्री की तुलना करें /tmp/env.output के उत्पादन के साथ env अपने नियमित टर्मिनल में चलाएं ।
यहाँ एक आम "गोचा" है PATH पर्यावरण चर अलग है। हो सकता है कि आपकी क्रॉन स्क्रिप्ट कमांड का उपयोग करती हो somecommand में पाया /opt/someApp/bin, जिसे आपने जोड़ा है PATH में /etc/environment? क्रॉन अनदेखा करता है PATH उस फ़ाइल से, इसलिए रनिंग somecommand क्रोन के साथ चलने पर आपकी स्क्रिप्ट विफल हो जाएगी, लेकिन टर्मिनल में चलने पर काम करें । यह ध्यान देने योग्य है कि चर से /etc/environment क्रॉन नौकरियों पर पारित किया जाएगा, न कि चर क्रॉन विशेष रूप से खुद को सेट करता है, जैसे PATH.
इसके आसपास जाने के लिए, बस अपना खुद का सेट करें PATH स्क्रिप्ट के शीर्ष पर चर । जैसे ।
#!/bin/bashPATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin# rest of script follows
कुछ इसके बजाय सभी आदेशों के लिए पूर्ण पथ का उपयोग करना पसंद करते हैं । मैं इसके खिलाफ सलाह देता हूं । विचार करें कि क्या होता है यदि आप अपनी स्क्रिप्ट को किसी भिन्न सिस्टम पर चलाना चाहते हैं, और उस सिस्टम पर, कमांड अंदर है /opt/someAppv2.2/bin बजाय. आपको पूरी स्क्रिप्ट को बदलना होगा /opt/someApp/bin साथ में /opt/someAppv2.2/bin स्क्रिप्ट की पहली पंक्ति पर केवल एक छोटा सा संपादन करने के बजाय ।
आप क्रोनटैब फ़ाइल में पथ चर भी सेट कर सकते हैं, जो सभी क्रॉन नौकरियों पर लागू होगा । जैसे ।
मेरा शीर्ष गोचा: यदि आप अंत में एक नई लाइन जोड़ना भूल जाते हैं crontab फ़ाइल। दूसरे शब्दों में, क्रोनटैब फ़ाइल एक खाली लाइन के साथ समाप्त होनी चाहिए ।
नीचे इस मुद्दे के लिए मैन पेज में प्रासंगिक अनुभाग है (man crontab फिर अंत तक छोड़ें):
Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end. 4th Berkeley Distribution 29 December 1993 CRONTAB(1)
क्रॉन डेमन नहीं चल रहा है । मैं वास्तव में कुछ महीने पहले इसके साथ खराब हो गया था ।
प्रकार:
pgrep cron
यदि आप कोई संख्या नहीं देखते हैं (यानी क्रॉन का मुख्य पीआईडी), तो क्रॉन नहीं चल रहा है । sudo /etc/init.d/cron start क्रॉन शुरू करने के लिए इस्तेमाल किया जा सकता.
संपादित करें: इनिट स्क्रिप्ट को /आदि/इनिट के माध्यम से लागू करने के बजाय । डी, सेवा उपयोगिता का उपयोग करें, उदा ।
sudo service cron start
संपादित करें: इसके अलावा आप आधुनिक लिनक्स में सिस्टमक्टल का उपयोग कर सकते हैं, उदाहरण के लिए
स्क्रिप्ट फ़ाइल नाम में cron.d/, cron.daily/, cron.hourly/, आदि । , डॉट नहीं होना चाहिए (.), अन्यथा रन-पार्ट्स उन्हें छोड़ देंगे ।
रन-पार्ट्स देखें (8):
If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, dig‐ its, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).
इसलिए, यदि आपके पास क्रॉन स्क्रिप्ट है backup.sh, analyze-logs.pl में cron.daily/ निर्देशिका, आप एक्सटेंशन नामों को हटाने के लिए सबसे अच्छा होगा ।
स्क्रिप्ट के लिए निरपेक्ष पथ का उपयोग किया जाना चाहिए:
उदाहरण के लिए, /bin/grep इसके बजाय इस्तेमाल किया जाना चाहिए grep:
# m h dom mon dow command0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors
के बजाय:
# m h dom mon dow command0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors
यह विशेष रूप से मुश्किल है, क्योंकि शेल से निष्पादित होने पर एक ही कमांड काम करेगा । कारण यह है कि cron एक ही नहीं है PATH उपयोगकर्ता के रूप में पर्यावरण चर ।
यदि आपके क्रोंटैब कमांड में एक है % इसमें प्रतीक, क्रॉन इसकी व्याख्या करने की कोशिश करता है । तो अगर आप एक साथ किसी भी आदेश का उपयोग कर रहे थे % इसमें (जैसे दिनांक कमांड के लिए एक प्रारूप विनिर्देश) आपको इससे बचने की आवश्यकता होगी ।
यह भी संभव है कि उपयोगकर्ता का पासवर्ड समाप्त हो गया हो । यहां तक कि रूट का पासवर्ड भी समाप्त हो सकता है । आप कर सकते हैं tail -f /var/log/cron.log और आप देखेंगे कि पासवर्ड समाप्त होने के साथ क्रॉन विफल हो जाएगा । आप ऐसा करके पासवर्ड को कभी भी समाप्त नहीं होने के लिए सेट कर सकते हैं: passwd -x -1 <username>
कुछ प्रणालियों में (डेबियन, उबंटू) क्रॉन के लिए लॉगिंग डिफ़ॉल्ट रूप से सक्षम नहीं है । में /आदि/rsyslog.conf या /आदि/rsyslog.डी / 50-डिफ़ॉल्ट । conf लाइन:
# cron.* /var/log/cron.log
संपादित किया जाना चाहिए (sudo nano /etc/rsyslog.conf) uncommented करने के लिए:
cron.* /var/log/cron.log
उसके बाद, आपको आरएसआईएसएलओजी को पुनरारंभ करना होगा
कुछ सिस्टम (उबंटू) में क्रॉन के लिए अलग लॉगिंग फ़ाइल डिफ़ॉल्ट रूप से सक्षम नहीं है, लेकिन क्रॉन संबंधित लॉग सिस्लॉग फ़ाइल में दिखाई दे रहे हैं । एक उपयोग कर सकते हैं
क्रॉन को प्रभावित करने के लिए आपको क्रोनटैब-ई को बंद करना होगा । उदाहरण के लिए विम का उपयोग करके मैं फ़ाइल को संपादित करता हूं और इसे लिखने के लिए :डब्ल्यू का उपयोग करता हूं, लेकिन जब तक मैं भी नहीं छोड़ता तब तक नौकरी क्रॉन में नहीं जोड़ी जाती है । इसलिए मैं :क्यू के बाद भी नौकरी नहीं देखूंगा ।