Crontab: Linux में कार्य शेड्यूल के उदाहरण, सिंटैक्स और आम गलतियाँ
Crontab एक शेड्यूल तालिका है, जिसके अनुसार cron डेमन कमांड चलाता है: हर पंक्ति में पाँच समय-फ़ील्ड (मिनट, घंटा, महीने का दिन, महीना, हफ़्ते का दिन) और कमांड होती है, जैसे */5 * * * * /opt/backup.sh स्क्रिप्ट को हर 5 मिनट पर चलाता है। तालिका crontab -e से बदली जाती है, और ज़्यादातर समस्याएँ cron के सीमित एनवायरनमेंट से आती हैं: पूरे पथ लिखें और आउटपुट लॉग में भेजें।
Cron Linux का मानक शेड्यूलर है: cron डेमन हर मिनट शेड्यूल की तालिकाएँ (crontab) पढ़ता है और जिस कमांड का समय आ गया हो, उसे चलाता है। रात में बैकअप बनाना, अस्थायी फ़ाइलें साफ़ करना, सर्टिफ़िकेट अपडेट करना और रिपोर्ट भेजना — यही काम cron से होते हैं। नीचे सिंटैक्स, आम स्थितियों के लिए crontab उदाहरण, और उन गलतियों का विश्लेषण है जिनसे कार्य «चुपचाप» नहीं चलता।
crontab कैसे खोलें और बदलें
हर उपयोगकर्ता की अपनी तालिका होती है। उसके साथ crontab कमांड से काम किया जाता है, न कि /var/spool/cron की फ़ाइलों को सीधे बदलकर:
| कमांड | क्या करता है |
|---|---|
crontab -e | अपनी तालिका एडिटर में खोलना (पहली बार एडिटर चुनने को कहेगा) |
crontab -l | मौजूदा तालिका दिखाना |
crontab -r | पूरी तालिका बिना पुष्टि के हटाना |
crontab -i -r | पुष्टि के साथ हटाना (Debian/Ubuntu, RHEL) |
sudo crontab -u alice -e | किसी दूसरे उपयोगकर्ता की तालिका बदलना |
crontab फ़ाइल | तालिका को फ़ाइल की सामग्री से बदलना |
crontab -e सेव करने के बाद सिंटैक्स जाँचता है और लिखता है crontab: installing new crontab। पंक्ति में गलती हो तो errors in crontab file, can't install आएगा और दोबारा एडिट करने का विकल्प मिलेगा। डेमन को दोबारा चालू करने की ज़रूरत नहीं — बदलाव अपने-आप लागू होते हैं।
-r से सावधान रहें: अक्षर e और r कीबोर्ड पर पास-पास हैं, और तालिका का कोई बैकअप अपने-आप नहीं बनता। अच्छी आदत है बैकअप रखना:
crontab -l > ~/crontab.bak
# वापस लाने के लिए
crontab ~/crontab.bak
crontab सिंटैक्स: पाँच समय-फ़ील्ड
हर कार्य की पंक्ति ऐसी दिखती है:
# ┌───────── मिनट (0–59)
# │ ┌─────── घंटा (0–23)
# │ │ ┌───── महीने का दिन (1–31)
# │ │ │ ┌─── महीना (1–12 या jan–dec)
# │ │ │ │ ┌─ हफ़्ते का दिन (0–7 या sun–sat; 0 और 7 — रविवार)
# │ │ │ │ │
* * * * * कमांड
हर फ़ील्ड में ये विशेष चिह्न इस्तेमाल हो सकते हैं:
| चिह्न | अर्थ | उदाहरण |
|---|---|---|
* | कोई भी मान | * * * * * — हर मिनट |
, | सूची | 0 9,18 * * * — 9:00 और 18:00 पर |
- | सीमा (range) | 0 9-18 * * * — 9 से 18 बजे तक हर घंटे |
/ | अंतराल (step) | */15 * * * * — हर 15 मिनट |
अंतराल को सीमा के साथ जोड़ा जा सकता है: 0 8-20/2 * * * — सुबह 8 से रात 20 बजे तक हर दो घंटे (8, 10, …, 20)। समय सिस्टम के टाइमज़ोन में लिया जाता है — उसे timedatectl से जाँचें।
रोज़मर्रा के crontab उदाहरण
| शेड्यूल | crontab की पंक्ति |
|---|---|
| हर मिनट | * * * * * |
| हर 5 मिनट | */5 * * * * |
| हर 30 मिनट | */30 * * * * या 0,30 * * * * |
| हर घंटे, घंटे की शुरुआत पर | 0 * * * * |
| हर 6 घंटे | 0 */6 * * * |
| हर दिन 3:00 पर | 0 3 * * * |
| हर दिन 23:45 पर | 45 23 * * * |
| वर्कडे पर 9:00 बजे | 0 9 * * 1-5 |
| सप्ताहांत पर दोपहर 12 बजे | 0 12 * * 6,0 |
| हर सोमवार 8:30 पर | 30 8 * * 1 |
| हर महीने की 1 तारीख को 00:00 पर | 0 0 1 * * |
| हर तिमाही | 0 0 1 1,4,7,10 * |
| हर साल 1 जनवरी को | 0 0 1 1 * |
| काम के घंटों में हर 10 मिनट | */10 9-18 * * 1-5 |
पूरी कार्य-पंक्ति = शेड्यूल + कमांड:
# डेटाबेस का बैकअप हर रात 3:00 बजे
0 3 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1
# रविवार को 7 दिन से पुरानी अस्थायी फ़ाइलें साफ़ करना
0 4 * * 0 /usr/bin/find /tmp/app -type f -mtime +7 -delete
# हर 5 मिनट पर साइट की जाँच
*/5 * * * * /usr/bin/curl -fsS https://example.com/health > /dev/null || /usr/local/bin/alert.sh
@reboot, @daily और अन्य विशेष रूप
पाँच फ़ील्ड की जगह छोटा उपनाम भी लिखा जा सकता है:
| उपनाम | बराबर |
|---|---|
@reboot | cron डेमन शुरू होने पर एक बार (सिस्टम बूट के बाद) |
@hourly | 0 * * * * |
@daily / @midnight | 0 0 * * * |
@weekly | 0 0 * * 0 |
@monthly | 0 0 1 * * |
@yearly / @annually | 0 0 1 1 * |
@reboot /home/alice/bin/start-tunnel.sh >> /home/alice/tunnel.log 2>&1
जो सेवाएँ लगातार चलनी चाहिए और गिरने पर दोबारा शुरू होनी चाहिए, उनके लिए @reboot कमज़ोर हल है: बेहतर है systemd यूनिट बनाना, जिसमें Restart=on-failure हो।
हर N सेकंड पर कमांड कैसे चलाएँ
cron की सबसे छोटी इकाई एक मिनट है। अगर इससे बार-बार चलाना हो, तो दो तरीके हैं। पहला — sleep से खिसकाई गई कई पंक्तियाँ:
* * * * * /opt/check.sh
* * * * * sleep 30; /opt/check.sh
दूसरा, ज़्यादा सही तरीका — OnUnitActiveSec=30s वाला systemd टाइमर। अगर कार्य मिनट में एक बार से ज़्यादा चलाना है, तो अक्सर वह डेमन या टाइमर का काम है, cron का नहीं।
सिस्टम crontab: /etc/crontab और /etc/cron.d
उपयोगकर्ता तालिकाओं के अलावा सिस्टम तालिकाएँ भी होती हैं। उनका फ़ॉर्मेट अलग है: समय और कमांड के बीच उस उपयोगकर्ता का नाम लिखा जाता है, जिसके अधिकारों से कमांड चलेगी।
# /etc/cron.d/certbot-renew
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 */12 * * * root certbot renew --quiet
कौन-सी चीज़ कहाँ रहती है:
/etc/crontab— मुख्य सिस्टम तालिका; Debian/Ubuntu में इसी से नीचे की डायरेक्टरी चलती हैं।/etc/cron.d/— अलग-अलग कार्य-फ़ाइलें; पैकेज इन्हें लगाते हैं या Ansible से रखे जाते हैं।/etc/cron.hourly/,cron.daily/,cron.weekly/,cron.monthly/— इनमें बिना शेड्यूल की executable स्क्रिप्ट रखी जाती हैं; उन्हेंrun-parts(या anacron) चलाता है।
run-parts की एक चाल: Debian और Ubuntu में वह उन फ़ाइलों को छोड़ देता है जिनके नाम में बिंदु (.) है। /etc/cron.daily/ में backup.sh नहीं चलेगी — उसका नाम backup रखें। क्या चलेगा, यह देखने के लिए: run-parts --test /etc/cron.daily।
/etc/cron.d/ की फ़ाइलें root की होनी चाहिए, समूह और बाकी लोगों के लिए लिखने योग्य न हों, और उनके अंत में नई पंक्ति (newline) हो — वरना cron उन्हें नज़रअंदाज़ कर देगा।
cron का एनवायरनमेंट: PATH, SHELL और वेरिएबल
«टर्मिनल में चलता है, cron में नहीं» वाली समस्या का मुख्य कारण एनवायरनमेंट है। Cron कमांड /bin/sh से चलाता है, आपकी .bashrc और .profile के बिना, और न्यूनतम PATH के साथ (आम तौर पर /usr/bin:/bin)। इसलिए /usr/local/bin में रखे docker, node या php बस नहीं मिलते।
वेरिएबल तालिका की शुरुआत में सेट किए जा सकते हैं:
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=admin@example.com
CRON_TZ=Europe/Moscow
0 6 * * * cd /srv/app && ./report.sh
MAILTO— कार्य का आउटपुट किसे भेजना है;MAILTO=""ईमेल बंद करता है।CRON_TZ— शेड्यूल का टाइमज़ोन (RHEL/Fedora के cronie में समर्थित; Debian के cron में यह वेरिएबल काम नहीं करता)।- वेरिएबल के मानों में
$HOME/binजैसे विस्तार नहीं चलते — पूरा पथ लिखें।
सबसे भरोसेमंद तरीका है कार्य में सभी प्रोग्रामों और फ़ाइलों के पूरे पथ लिखना, और स्क्रिप्ट की पहली पंक्ति में shebang रखना: #!/bin/bash।
cron के लॉग कहाँ देखें
Cron जर्नल में केवल यह दर्ज करता है कि कार्य शुरू हुआ, उसका आउटपुट नहीं:
# Debian/Ubuntu
grep CRON /var/log/syslog
# systemd-journald के ज़रिए
journalctl -u cron --since today # Debian/Ubuntu
journalctl -u crond --since today # RHEL, Fedora, Rocky
# बिना journald वाला RHEL
tail -f /var/log/cron
शुरू होने की पंक्ति कुछ ऐसी दिखती है:
Oct 14 03:00:01 web1 CRON[21544]: (root) CMD (/usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1)
यह देखने के लिए कि कार्य ने क्या छापा और किस गड़बड़ी से गिरा, stdout और stderr दोनों फ़ाइल में भेजें: >> /var/log/job.log 2>&1। ऐसा न करने पर आउटपुट लोकल मेल से जाता है, और अगर मेल एजेंट इंस्टॉल नहीं है तो वह खो जाता है (जर्नल में No MTA installed, discarding output दिखेगा)।
cron कार्य क्यों नहीं चलाता: आम गलतियाँ
कमांड नहीं मिली
लक्षण: कार्य के लॉग में command not found। कारण — सीमित PATH। हल: प्रोग्राम का पूरा पथ लिखें (which docker वह पथ बता देगा), या तालिका की शुरुआत में PATH= पंक्ति रखें।
कमांड में प्रतिशत चिह्न (%)
crontab में % का मतलब है नई पंक्ति: पहले % के बाद का सब कुछ कमांड को stdin पर दिया जाता है। इसलिए फ़ाइल के नाम में तारीख वाली क्लासिक पंक्ति टूट जाती है:
# गलत — कमांड पहले % पर कट जाएगी
0 2 * * * tar czf /backup/site-$(date +%F).tar.gz /var/www
# सही — escape करें
0 2 * * * tar czf /backup/site-$(date +\%F).tar.gz /var/www
इससे भी आसान है तर्क को स्क्रिप्ट में डालना, जहाँ % को escape करने की ज़रूरत नहीं होती।
स्क्रिप्ट executable नहीं है या लाइन-एंडिंग गलत है
Permission denied का मतलब है कि फ़ाइल में x बिट नहीं है: chmod +x script.sh चलाएँ, या सीधे लिखें /bin/bash /opt/script.sh। अगर स्क्रिप्ट Windows में लिखी गई है, तो CRLF लाइन-एंडिंग से अजीब त्रुटि आती है /bin/bash^M: bad interpreter — इसे sed -i 's/\r$//' script.sh या dos2unix से ठीक करें।
सापेक्ष पथ और वर्किंग डायरेक्टरी
कार्य उपयोगकर्ता की होम डायरेक्टरी से शुरू होता है। अगर स्क्रिप्ट ./config.ini पढ़ती है, तो वह उसे ~ में खोजेगी। कमांड से पहले cd /srv/app && लिखें या स्क्रिप्ट के अंदर पूरे पथ इस्तेमाल करें।
महीने का दिन और हफ़्ते का दिन एक साथ
अगर दोनों फ़ील्ड भरे हैं, तो cron तब चलता है जब उनमें से कोई भी मेल खाए, दोनों एक साथ नहीं। पंक्ति 0 9 13 * 5 13 तारीख को और हर शुक्रवार को चलेगी, केवल शुक्रवार 13 तारीख को नहीं। सही शर्त कमांड के भीतर जाँचें:
0 9 13 * * [ "$(date +\%u)" = 5 ] && /opt/friday13.sh
कार्य एक-दूसरे पर चढ़ जाते हैं
अगर बैकअप अंतराल से ज़्यादा समय लेता है, तो अगला रन पिछले के ऊपर शुरू हो जाता है। बचाव है flock से लॉक:
*/10 * * * * /usr/bin/flock -n /tmp/sync.lock /opt/sync.sh
-n के साथ दूसरा उदाहरण तुरंत खत्म हो जाता है, अगर पहला अभी चल रहा है।
cron डेमन चालू नहीं है
systemctl status cron से जाँचें (RHEL में नाम crond है)। न्यूनतम इमेज, जैसे Docker कंटेनर, में cron डेमन होता ही नहीं — वहाँ crontab की कार्य चलाने वाला कोई नहीं होता।
cron कार्य को डीबग कैसे करें
कमांड को उस एनवायरनमेंट में चलाएँ जो cron जैसा हो:
env -i SHELL=/bin/sh PATH=/usr/bin:/bin HOME=$HOME /bin/sh -c '/opt/backup.sh'
यहाँ त्रुटि आती है, तो वही cron में भी आएगी। अस्थायी रूप से शेड्यूल * * * * * रखें, आउटपुट फ़ाइल में भेजें और tail -f से देखते रहें। शेड्यूल की अभिव्यक्ति जाँचने में ऑनलाइन cron कैलकुलेटर मदद करते हैं, पर अंतिम फ़ैसला सिस्टम के लॉग का होता है।
cron का उपयोग कौन कर सकता है: cron.allow और cron.deny
पहुँच /etc/cron.allow और /etc/cron.deny फ़ाइलों से सीमित होती है। अगर cron.allow मौजूद है, तो crontab केवल उसमें सूचीबद्ध उपयोगकर्ताओं के लिए है। अगर वह नहीं है पर cron.deny है, तो सभी के लिए है सिवाय उन्हीं के जो उसमें लिखे हैं। जिस उपयोगकर्ता पर रोक है, वह crontab -e पर संदेश देखेगा: You (bob) are not allowed to use this program।
निष्कर्ष
Crontab पाँच समय-फ़ील्ड और कमांड की पंक्तियाँ हैं: */5 * * * * — हर 5 मिनट, 0 3 * * * — हर रात, 0 9 * * 1-5 — वर्कडे पर। तालिका crontab -e से बदलें, पूरे पथ लिखें, % को escape करें, आउटपुट लॉग में भेजें, और लंबे कार्यों को flock से बचाएँ। इन उदाहरणों से ज़्यादातर सर्वर कार्य हो जाते हैं, और स्वचालन व कार्य-शेड्यूलिंग का व्यावहारिक अभ्यास Linux कोर्स में किया जाता है।
अक्सर पूछे जाने वाले प्रश्न
cron और anacron में क्या फ़र्क है?
Cron कार्य ठीक तय समय पर चलाता है और अगर कंप्यूटर बंद था तो उसे छोड़ देता है। Anacron यह पक्का करता है कि रोज़, साप्ताहिक और मासिक कार्य चालू होने के बाद ज़रूर पूरे हों, इसलिए लैपटॉप और डेस्कटॉप के लिए ठीक है।
cron या systemd टाइमर में से कौन बेहतर है?
Cron सरल है और लगभग हर जगह मिलता है। systemd टाइमर में journalctl के लॉग, डिपेंडेंसी, संसाधन सीमा और छूटे रनों के लिए Persistent=true मिलता है, इसलिए आधुनिक सर्वरों पर महत्वपूर्ण कार्यों के लिए इन्हें ज़्यादा चुना जाता है।
उपयोगकर्ता की crontab वास्तव में कहाँ रहती है?
Debian और Ubuntu में /var/spool/cron/crontabs/नाम पर, और RHEL व Fedora में /var/spool/cron/नाम पर। इन फ़ाइलों को सीधे न बदलें, crontab -e का इस्तेमाल करें।
crontab में कोई कार्य अस्थायी रूप से कैसे बंद करें?
crontab -e में उस पंक्ति की शुरुआत में # लगा दें। सारे कार्य बंद करने के लिए crontab -l से तालिका फ़ाइल में सहेजें और फिर crontab -r से हटाएँ।
महीने के आख़िरी दिन कोई कार्य कैसे चलाएँ?
इसके लिए अलग फ़ील्ड नहीं है। कार्य 28–31 तारीख को चलाएँ और जाँचें कि कल पहली तारीख है: 0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = 01 ] && /opt/job.sh.
यह विषय “Linux: с нуля до уверенного администрирования” कोर्स में अभ्यास के साथ विस्तार से समझाया गया है।
कोर्स पर जाएँ