क्रॉन जॉब्स का कॉन्फ़िगरेशन

क्रोन is a commonly confusing and misconfigured aspect of the operating system. Technically, cron is just the clock daemon (/usr/sbin/cron or perhaps /usr/sbin/crond) that executes commands at specific times. However, a handful of configuration files and programs go into making up the cron package. Like many system processes, cron never ends.

The controlling files for cron are the cron-tables or crontabs. The crontabs are often located in /var/spool/cron/crontab. However, on SuSE you will find them in /var/spool/cron/tabs. The names of the files in this directory are the names of the users that submit the cron jobs.

अन्य UNIX संस्करणों के विपरीत, Linux का cron daemon अगला cron job तैयार होने तक निष्क्रिय नहीं रहता। इसके बजाय, जब cron एक job पूरा कर लेता है, तो वह चलाने के लिए और jobs हैं या नहीं, यह हर मिनट में एक बार जांचता रहता है। साथ ही, आपको इन फ़ाइलों को सीधे संपादित नहीं करना चाहिए। आप इन्हें vi जैसे टेक्स्ट एडिटर से संपादित कर सकते हैं, हालांकि इससे गड़बड़ी होने की संभावना रहती है। इसलिए, आपको Linux द्वारा उपलब्ध कराए गए टूल crontab का उपयोग करना चाहिए। (अधिक जानकारी के लिए man-page देखें)

crontab utility के कई कार्य हैं। इसी के माध्यम से cron jobs वाली फ़ाइलें सिस्टम में जमा की जाती हैं। दूसरा, यह आपके crontab की सामग्री की सूची दिखा सकती है। यदि आप root हैं, तो यह किसी भी उपयोगकर्ता के लिए jobs जमा भी कर सकती है और उनकी सूची भी दिखा सकती है। समस्या यह है कि jobs को अलग-अलग जमा नहीं किया जा सकता। crontab का उपयोग करते समय आपको सभी jobs एक साथ जमा करनी होती हैं।

पहली नज़र में यह थोड़ा परेशान करने वाला लग सकता है। फिर भी, आइए किसी job को "जोड़ने" की प्रक्रिया देखें। cron job जोड़ने के लिए आपको सबसे पहले -l विकल्प के साथ मौजूदा crontab की सामग्री की सूची निकालनी होगी। यदि आप root हैं और किसी अन्य उपयोगकर्ता के crontab में कुछ जोड़ना चाहते हैं, तो -u विकल्प के बाद उपयोगकर्ता का logname लिखें। फिर इस crontab को किसी फ़ाइल में redirect करें, जिसे आप बाद में संपादित कर सकते हैं। (ध्यान दें कि कुछ सिस्टम में crontab में -e ("edit" के लिए) विकल्प होता है, जो सारा काम आपके लिए कर देता है। अधिक जानकारी के लिए man-page देखें।)

उदाहरण के लिए, मान लें कि आप root उपयोगकर्ता हैं और UUCP उपयोगकर्ता के crontab में कुछ जोड़ना चाहते हैं। सबसे पहले, इस कमांड से मौजूदा crontab प्रविष्टि का आउटपुट प्राप्त करें:

crontab -l -u uucp >/tmp/crontab.uucp

नई प्रविष्टि जोड़ने के लिए बस एक नई पंक्ति जोड़ें। फ़ाइल सेव करें, एडिटर से बाहर निकलें और crontab utility को दोबारा चलाएं। इस बार सूची दिखाने वाला -l हटा दें और फ़ाइल का नाम दें। crontab utility stdin से भी इनपुट ले सकती है, इसलिए आप फ़ाइल का नाम छोड़ भी सकते हैं और तब crontab आपको कमांड लाइन पर cronjobs दर्ज करने देगा। ध्यान रखें कि आप जो भी तरीका अपनाएं, पहले का कोई भी crontab हटा दिया जाता है।

The file /tmp/crontab.uucp now contains the contents of UUCPs crontab. It might look something like this:

39,9 * * * * /usr/lib/uucp/uudemon.hour > /dev/null
10 * * * * /usr/lib/uucp/uudemon.poll > /dev/null
45 23 * * * ulimit 5000; /usr/lib/uucp/uudemon.clean > /dev/null
48 10,14 * * 1-5 /usr/lib/uucp/uudemon.admin > /dev/null

दिखने में भले ही अलग लगे, हर crontab प्रविष्टि में केवल छह फ़ील्ड होते हैं। पहले पांच फ़ील्ड वह समय दर्शाते हैं जब job चलनी चाहिए, और छठा फ़ील्ड वास्तविक कमांड होता है। पहले पांच फ़ील्ड स्पेस या टैब से अलग किए जाते हैं और क्रमशः इन इकाइयों को दर्शाते हैं:

मिनट (0-59)
घंटा (0-23)
महीने का दिन (1-31)
वर्ष का महीना (1-12)
सप्ताह का दिन (0-6, 0=रविवार)
सभी संभावित मान दर्शाने के लिए तारांकन चिह्न (*) का उपयोग करें। किसी एक मान को दर्शाने के लिए बस वही मान लिखें। उदाहरण के लिए, पिछले उदाहरण की दूसरी पंक्ति के पहले फ़ील्ड में मान 10 है, जिसका अर्थ है घंटे के 10 मिनट बाद। क्योंकि बाकी चारों समय फ़ील्ड तारांकन चिह्न हैं, इसका अर्थ है कि कमांड हर दिन हर घंटे के 10 मिनट बाद चलती है।

मानों की सीमा में पहला मान, एक डैश और अंतिम मान होता है। उदाहरण के लिए, चौथी पंक्ति में सप्ताह के दिन वाले कॉलम में सीमा (1-5) है, जिसका अर्थ है कि कमांड केवल दिन 1-5, यानी सोमवार से शुक्रवार तक चलती है।

किसी सीमा में न आने वाले अलग-अलग मान दर्शाने के लिए, हर मान को कॉमा से अलग करें। चौथे उदाहरण में घंटे के फ़ील्ड में दो मान 10 और 14 हैं। इसका अर्थ है कि कमांड सुबह 10 बजे और दोपहर 2 बजे चलती है।

ध्यान दें कि समय एक-दूसरे में जुड़ते हैं। आइए एक उदाहरण देखें:


10 * 1,16 * 1-5 /usr/local/bin/command


कमांड हर घंटे के 10 मिनट बाद, महीने की पहली और सोलहवीं तारीख को, साथ ही सोमवार से शुक्रवार तक चलती है। यदि पहली या सोलहवीं तारीख सप्ताहांत में पड़ती है, तब भी कमांड चलेगी क्योंकि महीने के दिन वाला फ़ील्ड लागू होगा। हालांकि, इसका अर्थ यह नहीं है कि यदि पहली तारीख सोमवार को हो, तो कमांड दो बार चलेगी।

crontab प्रविष्टि को केवल हर घंटे या हर दिन के बजाय अलग-अलग अंतरालों पर चलने के लिए भी तय किया जा सकता है। हर दो मिनट या हर तीन घंटे जैसा अंतराल crontab में हर प्रविष्टि अलग से लिखे बिना भी निर्धारित किया जा सकता है।

मान लें कि हम पिछली कमांड को घंटे के 10 मिनट बाद नहीं, बल्कि हर दस मिनट पर चलाना चाहते थे। हम इस तरह की प्रविष्टि बना सकते थे:


0,10,20,30,40,50 * 1,16 * 1-5 /usr/local/bin/command


यह हर 10 मिनट पर चलती है: घंटे की शुरुआत में, 10 मिनट बाद, 20 मिनट बाद, और इसी तरह आगे। काम आसान बनाने के लिए, हम प्रविष्टि को सीधे इस तरह भी बना सकते हैं:


*/10 * 1,16 * 1-5 /usr/local/bin/command


यह सिंटैक्स कुछ एडमिनिस्ट्रेटरों के लिए नया हो सकता है। (मेरे लिए भी था।) स्लैश (/) बताता है कि दिए गए अंतराल (इस मामले में, हर मिनट) के भीतर कमांड को इतने-इतने मिनट पर चलाएं; इस मामले में, हर 10 मिनट पर।

सीमा तय करते समय भी हम इसका उपयोग कर सकते हैं। उदाहरण के लिए, यदि job को केवल घंटे के 20 मिनट बाद से 40 मिनट बाद के बीच चलना हो, तो प्रविष्टि कुछ इस तरह हो सकती है:


20-40 * 1,16 * 1-5 /usr/local/bin/command


यदि आप चाहें कि यह इन्हीं समयों पर चले, लेकिन केवल हर तीन मिनट पर, तो पंक्ति कुछ इस तरह हो सकती है:


20-40/3 * 1,16 * 1-5 /usr/local/bin/command


चीज़ों को और जटिल बनाने के लिए, आप कह सकते हैं कि कमांड घंटे से 20 मिनट बाद तक हर दो मिनट पर, 20 से 40 मिनट बाद तक हर तीन मिनट पर, और फिर 40 मिनट बाद से घंटे तक हर 5 मिनट पर चले।


0-20/2,21-40/3,41-59/5 * 1,16 * 1-5 /usr/local/bin/command


Linux की कई शाखाओं में एक वाकई अच्छी सुविधा यह है कि आप सप्ताह के दिनों और महीनों के लिए संक्षिप्त नाम निर्दिष्ट कर सकते हैं। यह याद रखना कहीं आसान है कि fri का मतलब शुक्रवार है, बजाय इसके कि इसके लिए 5 याद रखा जाए।

समय वाले फ़ील्ड की कुछ त्रुटियों को छोड़कर, अन्य त्रुटियों की सूचना तब तक नहीं मिलती जब तक cron कमांड को चला न दे। सभी त्रुटि संदेश और आउटपुट उपयोगकर्ताओं को ईमेल से भेज दिए जाते हैं। कम से कम crontab के man-page में यही लिखा है, और मूल रूप से यह सही भी है। लेकिन जैसा कि आपने पिछले उदाहरणों में देखा, आप stdout को /dev/null पर रीडायरेक्ट कर रहे हैं। चाहें तो आप stderr को भी वहीं रीडायरेक्ट कर सकते हैं, और तब आपको कभी पता नहीं चलेगा कि कोई त्रुटि हुई या नहीं।

आउटपुट उपयोगकर्ता को ईमेल से इसलिए भेजा जाता है क्योंकि cronjob जिस पर चलते हैं वहाँ कोई वास्तविक टर्मिनल नहीं होता। इसलिए त्रुटियाँ दिखाने के लिए कोई स्क्रीन नहीं होती। साथ ही, इनपुट लेने के लिए कोई कीबोर्ड भी नहीं होता। तो क्या इसका मतलब है कि आप cron job को इनपुट नहीं दे सकते? नहीं। शेल स्क्रिप्ट पर हुई चर्चा को याद कीजिए। हम stdin, stdout और stderr को दोबारा परिभाषित कर सकते हैं। इस तरह वे सभी फ़ाइलों की ओर संकेत कर सकते हैं और हमारी अपेक्षा के अनुसार काम कर सकते हैं।

मैं एक बात बताना चाहूँगा कि मैं crontab के कमांड फ़ील्ड में रीडायरेक्शन करने का समर्थन नहीं करता। मैं वहाँ जितना संभव हो उतना कम करना पसंद करता हूँ। इसके बजाय, मैं वहाँ किसी शेल स्क्रिप्ट का पूरा पाथ डाल देता हूँ। फिर मैं crontab एंट्री को किसी सरल चीज़ से परख सकता हूँ। एक बार वह ठीक चल जाए, तो मैं cronjob को दोबारा सबमिट किए बिना शेल स्क्रिप्ट में बदलाव कर सकता हूँ।

ध्यान रखें कि cron बिल्कुल सटीक नहीं होता। यह खुद को हर मिनट की शुरुआत से सिंक करता है। जिस व्यस्त सिस्टम में क्लॉक टिक छूट जाते हैं, वहाँ जॉब तय समय के कुछ मिनट बाद तक भी नहीं चल पातीं। इसके अलावा, ऊँची प्राथमिकता वाली अन्य प्रक्रियाएँ भी cron जॉब में देरी कर सकती हैं। कुछ मामलों में (खासकर बहुत व्यस्त सिस्टम पर) यदि जॉब हर मिनट चलाई जाएँ, तो वे छूट भी सकती हैं।

cron सुविधा तक पहुँच /etc में मौजूद दो फ़ाइलों के माध्यम से दी जाती है। यदि आपके पास cron.allow फ़ाइल है, तो आप तय कर सकते हैं कि कौन-से उपयोगकर्ता cron का उपयोग कर सकते हैं। cron.deny बताती है कि किन उपयोगकर्ताओं को cron का उपयोग करने की विशेष रूप से अनुमति नहीं है। यदि इनमें से कोई भी फ़ाइल मौजूद न हो, तो केवल सिस्टम उपयोगकर्ताओं को पहुँच मिलती है। लेकिन यदि आप चाहते हैं कि सभी को पहुँच मिले, तो cron.deny फ़ाइल में एक खाली एंट्री बनाएँ। यानी किसी को भी पहुँच से वंचित नहीं किया गया है।

It is often useful for root to run jobs as a different user without having to switch users (for example, using the su command). Most Linux dialects provide a mechanism in the form of the /etc/crontab file. This file is typically only writable by root and in some cases, only root can read it (which is often necessary in high security environments). The general syntax is the same as the standard crontabs, with a couple of exceptions.

पहला अंतर हेडर का है, जो आप यहाँ देख सकते हैं:


SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#

59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly
14 0 * * * root rm -f /var/spool/cron/lastrun/cron.daily
29 0 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly
44 0 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly

SHELL वेरिएबल उस शेल को निर्धारित करता है जिसके अंतर्गत हर कमांड चलेगी। PATH वेरिएबल सामान्य PATH एनवायरनमेंट वेरिएबल की तरह है और सर्च पाथ तय करता है। MAILTO वेरिएबल बताता है कि ईमेल संदेश किसे मिलने चाहिए, जिनमें त्रुटि संदेश और चलाई गई कमांड का स्टैंडर्ड आउटपुट शामिल है।

The structure of the actual entries is pretty much the same with the exception of the user name (root in each case here). This way, the root users (or whoever can edit /etc/crontab) can define which user executes the command. Keep in mind that this can be a big security hole. If someone can write to this file, they can create an entry that runs as root and therefore has complete control of the system.

cron "सूट" की अगली कमांड at है। इसका काम किसी कमांड को एक निश्चित समय पर चलाना है। अंतर यह है कि at जॉब एक बार चल जाने के बाद सिस्टम से हट जाती है। cron की तरह ही, at.allow और at.deny, ये दो फ़ाइलें at प्रोग्राम पर भी वही असर डालती हैं।

batch कमांड का उपयोग भी कमांड को केवल एक बार चलाने के लिए होता है। लेकिन batch से सबमिट की गई कमांड तब चलती हैं जब सिस्टम को उनके लिए समय मिलता है, यानी जब सिस्टम कम व्यस्त हो, जैसे आधी रात में। सिस्टम के लोड के अनुसार यह भी संभव है कि ऐसी जॉब पूरे दिन में फैल जाएँ।

at और batch के व्यवहार पर ध्यान देने योग्य एक बात यह है कि दोनों कमांड के नाम कमांड लाइन से स्वीकार करते हैं, कमांड के आर्ग्युमेंट के रूप में नहीं। आपको पहले कमांड चलानी होगी, जिससे आप नई लाइन पर पहुँचेंगे, जहाँ आप वे कमांड लिखते हैं जिन्हें चलाना है। हर कमांड के बाद Enter दबाएँ। काम पूरा होने पर Ctrl-D दबाएँ।

चूँकि ये दोनों कमांड stdin से कमांड स्वीकार करती हैं, आप हर बार नई लाइन पर लिखे बिना भी कमांड दे सकते हैं। एक तरीका किसी फ़ाइल से इनपुट रीडायरेक्ट करना है। उदाहरण के लिए


at now +1 hour < command_list


जहाँ command_list कमांड की सूची वाली एक फ़ाइल है। आप at (या batch) को पाइप के अंत में भी रख सकते हैं


cat command_list | at now + 1 hour

cat command_list | batch

Another interesting thing about both at and batch is that they create a kind of shell script to execute your command. When you run at or batch, a file is created in /usr/spool/cron/atjobs. This file contains the system variables that you would normally have defined, plus some other information that is contained in /usr/lib/cron.proto. This essentially creates an environment as though you had logged in.