क्रॉन एक्सप्रेशन पार्सर
क्रॉन एक्सप्रेशन को आसान भाषा में पढ़ें, और देखें कि वह अगली बार ठीक कब चलेगा।
मिनट · घंटा · महीने का दिन · महीना · सप्ताह का दिन। @daily जैसे मैक्रो भी चलते हैं।
यह चलता है
03:00 बजे, सोमवार को
अगले छह रन · UTC
- 2026-09-21 03:00सोमवार
- 2026-09-28 03:00सोमवार
- 2026-10-05 03:00सोमवार
- 2026-10-12 03:00सोमवार
- 2026-10-19 03:00सोमवार
- 2026-10-26 03:00सोमवार
UTC में दिखाया गया है। असली crontab सर्वर के टाइमज़ोन में चलता है, और डेलाइट सेविंग की गड़बड़ वहीं होती है — नीचे देखें।
एक-एक फ़ील्ड
- मिनट
- 00
- घंटा
- 33
- महीने का दिन
- *कोई भी
- महीना
- *कोई भी
- सप्ताह का दिन
- 11
इस शेड्यूल के बारे में जानने लायक़ बातें
- 31 तारीख़ हर महीने होती नहीं, इसलिए उन महीनों में यह चलेगा ही नहीं।
- 29 फ़रवरी सिर्फ़ लीप वर्ष में आती है — यानी यह चार साल में एक बार चलेगा।
पाँच फ़ील्ड, सबसे मोटी सबसे बाद में
| स्थान | फ़ील्ड | परास | टिप्पणी |
|---|---|---|---|
| 1 | मिनट | 0–59 | |
| 2 | घंटा | 0–23 | 24 घंटे की घड़ी, सर्वर का समय |
| 3 | महीने का दिन | 1–31 | जो दिन होते ही नहीं वे बस छोड़ दिए जाते हैं |
| 4 | महीना | 1–12 | या JAN–DEC |
| 5 | सप्ताह का दिन | 0–7 | 0 और 7 दोनों रविवार हैं। या SUN–SAT |
किसी फ़ील्ड के भीतर: * यानी कोई भी, , मानों की सूची देता है, - परास देता है, और / क़दम तय करता है। मिनट फ़ील्ड में */15 यानी हर पंद्रह मिनट; 5/10 यानी 5 से आगे दस-दस के अंतर पर, यानी 5, 15, 25 वग़ैरह। परास लपेटकर भी लिखी जा सकती हैं, इसलिए FRI-MON सप्ताहांत और उसके किनारे कहने का वैध तरीक़ा है।
वह नियम जो सबको फँसाता है
इस पेज से ले जाने लायक़ अगर एक ही चीज़ है, तो यही है।
जब महीने-का-दिन और सप्ताह-का-दिन — दोनों फ़ील्ड सीमित हों — तो cron जॉब तब चलाता है जब इनमें से कोई एक मिले। दोनों नहीं। यह «या» है, और पढ़ने में «और» लगता है।
0 0 1 * MON # NOT "the 1st, if it is a Monday"
# Actually: every 1st, AND every Mondayवह शेड्यूल महीने में क़रीब पाँच बार चलता है। उसे ऊपर वाले पार्सर में चिपकाइए और अगली बार चलने के समय देखिए — क्रम देखते ही भेद खुल जाता है।
यह नियम तभी लागू होता है जब दोनों फ़ील्ड सीमित हों। अगर इनमें से कोई * हो तो दूसरा ही तय करता है, और इसीलिए 0 0 * * MON ठीक वैसा ही बरताव करता है जैसी उम्मीद होती है। यह बरताव POSIX विनिर्देश में है और हर मुख्यधारा cron इसे लागू करता है, इसलिए यह ऐसा बग नहीं जिसे सेटिंग से हटाया जा सके।
दोनों शर्तें सचमुच चाहिए तो शेड्यूल में एक फ़ील्ड सीमित कीजिए और दूसरी जाँच जॉब के शुरू में रखिए:
0 0 * * MON [ "$(date +\%d)" = "01" ] && /usr/local/bin/jobडेलाइट सेविंग, जो साल में दो बार जॉब तोड़ती है
जब तक कहा न जाए, cron सर्वर की स्थानीय टाइमज़ोन में चलता है, और स्थानीय समय लगातार नहीं होता। घड़ियाँ आगे बढ़ें तो एक घंटा ग़ायब हो जाता है: 02:30 पर तय जॉब पूरी तरह छूट सकता है या 03:30 पर चल सकता है, यह इस पर निर्भर है कि आपके पास कौन-सा cron है। घड़ियाँ पीछे हों तो 01:30 दो बार आता है, और जॉब भी।
आधुनिक Vixie cron कोशिश करता है — आगे की छलाँग में छूटे जॉब आम तौर पर बाद में एक बार चला दिए जाते हैं — पर यह बरताव अलग-अलग कार्यान्वयनों में एकसार नहीं है, और कंटेनर शेड्यूलर तो और भी अलग-अलग हैं।
टिकाऊ इलाज यह है कि शेड्यूलर UTC में चलाइए और किनारों पर बदलिए। Kubernetes के CronJob ठीक इसी वजह से डिफ़ॉल्ट रूप से UTC में चलते हैं। अगर किसी जॉब को किसी ख़ास स्थानीय समय पर ही चलना है, तो यह मान लीजिए कि साल के कुछ हिस्से में वह एक घंटा इधर-उधर रहेगा — या ऐसा शेड्यूलर लीजिए जो टाइमज़ोन को ठीक से समझता हो; systemd टाइमर समझते हैं।
cron जॉब न चलने की दूसरी वजहें
- परिवेश लगभग ख़ाली होता है। cron आपकी शेल प्रोफ़ाइल नहीं पढ़ता, इसलिए
PATHबहुत कम होता है और आपका वर्चुअलएन्व सक्रिय नहीं होता। हमेशा पूर्ण पथ इस्तेमाल कीजिए। - अकेला प्रतिशत चिह्न। crontab में
%का मतलब नई पंक्ति है।date +%Yचुपचाप टूट जाता है; उसेdate +\%Yलिखना पड़ता है। - आख़िर में नई पंक्ति न होना। कुछ cron उस crontab की आख़िरी पंक्ति को अनदेखा कर देते हैं जो नई पंक्ति पर ख़त्म न हो।
- आउटपुट कहीं नहीं जाता। cron आउटपुट उपयोगकर्ता को मेल कर देता है, और अगर मेल सेट न हो तो वह ग़ायब हो जाता है। किसी लॉग फ़ाइल में मोड़ दीजिए ताकि नाकामी दिखे।
- ओवरलैप होते रन। cron पिछले रन के ख़त्म होने का इंतज़ार नहीं करता। हर मिनट के शेड्यूल पर पाँच मिनट का जॉब जमा होता जाता है, जब तक कुछ ढह न जाए।
flockइस्तेमाल कीजिए।
cron क्या नहीं कह सकता
फ़ील्ड आपस में स्वतंत्र हैं, इसलिए जो कुछ भी एक घंटे या एक दिन में पूरा-पूरा न बँटे वह पहुँच से बाहर है। «हर 90 मिनट» लिखा ही नहीं जा सकता। मानक cron में «महीने का आख़िरी शुक्रवार» भी नहीं — Quartz के L और # इसी के लिए हैं, और इसीलिए वे पोर्टेबल नहीं हैं।
अगर आप ख़ुद को इस वाक्य-रचना से जूझते पाएँ, तो आम तौर पर यही संकेत है कि ऐसे शेड्यूलर पर जाना चाहिए जो कैलेंडर फ़ील्ड के बजाय अंतरालों में सोचता हो। OnUnitActiveSec=90min वाला systemd टाइमर आपका मतलब एक पंक्ति में कह देता है।
संबंधित
ऊपर दिए चलने के समय UTC में हैं — टाइमस्टैम्प कन्वर्टर उनमें से किसी को भी आपकी अपनी टाइमज़ोन में, या आपका शेड्यूलर जिस भी फ़ॉर्मैट में लॉग करता है उसमें, बदल देगा। और अगर आपको शेड्यूल नहीं, टेक्स्ट मिलाना है, तो रेगेक्स टेस्टर बग़ल में ही है।
cron से जुड़े सवाल
मेरा जॉब उन दिनों क्यों चलता है जो मैंने तय नहीं किए?
लगभग निश्चित रूप से महीने-का-दिन और सप्ताह-का-दिन वाला नियम। जब दोनों फ़ील्ड सीमित हों, तो cron जॉब तब चलाता है जब इनमें से कोई एक मिले — दोनों नहीं। इसलिए 0 0 1 * MON हर महीने की पहली तारीख़ को भी चलता है और हर सोमवार को भी, यानी महीने में क़रीब पाँच बार, उस एक बार के बजाय जो आपका इरादा था। अगर कोई एक फ़ील्ड * हो तो यह नियम लागू नहीं होता और दूसरा ही तय करता है। दोनों शर्तें चाहिए तो cron में एक फ़ील्ड सीमित कीजिए और दूसरी जाँच जॉब के भीतर कीजिए।
पाँचों फ़ील्ड का क्या मतलब है?
मिनट (0–59), घंटा (0–23), महीने का दिन (1–31), महीना (1–12), सप्ताह का दिन (0–7, जहाँ 0 और 7 दोनों रविवार हैं)। बाएँ से दाएँ पढ़ते जाइए तो इकाई मोटी होती जाती है — यह याद रखने का अच्छा तरीक़ा है। कुछ शेड्यूलर — Quartz, Spring और कई जॉब रनर — शुरू में सेकंड के लिए छठा फ़ील्ड जोड़ देते हैं; मानक crontab में सेकंड का फ़ील्ड है ही नहीं।
डेलाइट सेविंग के दौरान cron जॉब का क्या होता है?
यह कार्यान्वयन पर निर्भर है, और साल में दो बार शेड्यूल किए गए जॉब यहीं चुपचाप टूटते हैं। जब घड़ियाँ आगे बढ़ती हैं तो एक घंटा होता ही नहीं — 02:30 वाला जॉब पूरी तरह छूट सकता है, या 03:30 पर चल सकता है, यह इस पर निर्भर है कि cron कौन-सा है। जब घड़ियाँ पीछे होती हैं तो 01:30 दो बार आता है, इसलिए जॉब दो बार चल सकता है। आधुनिक Vixie cron और systemd टाइमर इसमें समझदारी बरतने की कोशिश करते हैं; पुराने नहीं करते। मज़बूत जवाब यही है कि शेड्यूल किया काम UTC में चलाइए और किनारों पर बदलिए।
L, W और # क्या हैं और यहाँ इन्हें क्यों नहीं माना जाता?
ये Quartz के विस्तार हैं — L यानी «आख़िरी» (महीने का आख़िरी दिन, आख़िरी शुक्रवार), W यानी सबसे नज़दीकी कार्यदिवस, और # यानी «महीने का n-वाँ अमुक वार»। ये सचमुच उपयोगी हैं और ये मानक cron नहीं हैं। crontab, Kubernetes के CronJob और GitHub Actions — तीनों या तो इन्हें ठुकरा देंगे या ग़लत पढ़ेंगे। यह पार्सर अंदाज़ा लगाने के बजाय इनकार कर देता है, क्योंकि जो शेड्यूल चुपचाप L को अनदेखा कर दे वह ठीक उसी तरह ग़लत होगा जिसे कोई जाँचता नहीं।
@reboot क्या करता है?
यह जॉब को एक बार तब चलाता है जब cron शुरू होता है, आम तौर पर बूट के समय। इसका कोई दोहराव वाला शेड्यूल नहीं है, इसलिए अगली बार चलने का समय निकालने को कुछ है ही नहीं — यही वजह है कि यह टूल ख़ाली सूची दिखाने के बजाय यह बात कह देता है। जानने लायक़ है कि @reboot तब चलता है जब cron डीमन शुरू होता है, तब नहीं जब मशीन का बूट पूरा होता है — इसलिए जो कुछ भी नेटवर्क के तैयार होने पर निर्भर है, उसे ख़ुद इंतज़ार करना पड़ेगा।
हर 90 मिनट पर कुछ चलाने के लिए क्या करूँ?
इसे सीधे लिखा ही नहीं जा सकता, और यह एक असली सीमा है, कोई ऐसी तरकीब नहीं जो आपने सीखी न हो। cron के फ़ील्ड एक-दूसरे से स्वतंत्र हैं, इसलिए मिनट फ़ील्ड में */90 अवैध है, और ऐसा कोई शेड्यूल बनाया ही नहीं जा सकता जो एक घंटे या एक दिन में पूरा-पूरा न बँटता हो। रास्ते ये हैं: दो प्रविष्टियाँ जो दिन भर में यह पैटर्न पूरा कर दें, या — और यह ज़्यादा ईमानदार है — ऐसा शेड्यूलर जो कैलेंडर फ़ील्ड के बजाय अंतरालों में सोचता हो, जैसे OnUnitActiveSec वाला systemd टाइमर।
अंतिम समीक्षा । कुछ पुराना पड़ा हुआ मिला? हमें बताइए.