Cron एक्सप्रेशन व्याख्याता

एक cron अभिव्यक्ति पेस्ट करें और समझें कि यह वास्तव में क्या करती है।

सामान्य उदाहरण

cron एक्सप्रेशन कैसे पढ़ें

एक मानक cron एक्सप्रेशन में स्पेस से अलग किए गए 5 फ़ील्ड होते हैं:

मिनट घंटा दिन महीना सप्ताह-दिन

* · कोई भी मान   */n · प्रत्येक n इकाई   1,5 · मानों 1 और 5 पर   1-5 · 1 से 5 तक की सीमा

सीमाएँ: मिनट (0-59), घंटा (0-23), दिन (1-31), महीना (1-12), सप्ताह का दिन (0-6, 0 = रविवार)

यह कैसे काम करता है

  1. cron एक्सप्रेशन दर्ज करें: 0 9 * * 1-5 जैसी 5 या 6-फ़ील्ड cron स्ट्रिंग पेस्ट करें।
  2. स्पष्ट भाषा व्याख्या पढ़ें: टूल तुरंत पठनीय विवरण प्रदर्शित करता है कि कार्य कब चलता है।
  3. अगले चालन देखें: वर्तमान तिथि से अगले 5 से 10 निर्धारित चालनों की सूची प्रदर्शित होती है।
  4. सत्यापित करें: अमान्य एक्सप्रेशन त्रुटि संदेशों के साथ हाइलाइट होते हैं।

एक मिनट की टिक की आधी सदी

cron दुनिया के अधिकांश सर्वरों पर अब भी निरंतर दैनिक उपयोग में रहने वाला सबसे पुराना शेड्यूलर है। इसका ऐतिहासिक रिकॉर्ड में पहला दिखावा मई 1975 है, जब AT&T Bell Laboratories से एक प्रारंभिक संस्करण Research Unix शाखा के हिस्से के रूप में आया। नाम Chronos के लिए एक संकेत है, समय का ग्रीक मानवीकरण, और डिज़ाइन अजीब अनुग्रह के साथ पुराना हुआ है: 1970 के दशक के मध्य में Bell Labs के इंजीनियरों ने /usr/lib/crontab में जो वही पाँच व्हाइटस्पेस-अलग किए गए फ़ील्ड टाइप किए थे, वे आज भी Kubernetes CronJobs, GitHub Actions शेड्यूल और इस वक़्त फ्रैंकफ़र्ट के किसी वर्चुअल प्राइवेट सर्वर पर रात के डेटाबेस बैकअप को चला रहे हैं। 1975 का कार्यान्वयन न्यूनतम था, एक crontab था, root के स्वामित्व में, जो पूरी मशीन को सेवा देता था। यदि कोई उपयोगकर्ता एक आवर्ती कार्य चाहता था, तो वह व्यवस्थापक से हाथ से एक पंक्ति जोड़ने को कहता। cron ने व्यापक दुनिया में Version 7 Unix में, 1979 में जारी क़दम रखा। Purdue विश्वविद्यालय के Robert Brown और Keith Williamson ने 1979 के अंत में cron को कई उपयोगकर्ताओं को संभालने के लिए विस्तारित किया, प्रति-उपयोगकर्ता crontab -e वर्कफ़्लो पेश किया। निर्णायक पुनर्लेखन तब आया जब Paul Vixie ने 6 मई 1987 को vixie-cron 1.0 जारी किया; vixie-cron ने विशेष वर्णों को औपचारिक बनाया और @reboot, @hourly, @daily, @weekly, @monthly, @yearly शॉर्टकट पेश किए। Vixie 3.0 (27 दिसंबर 1993) ने स्टेप मान (/) जोड़े और मामूली पैच के साथ उस युग की लगभग हर Linux वितरण और BSD में पहुँचा। POSIX 1992 में पकड़ में आया (IEEE Std 1003.2-1992)। आधुनिक cron की हर विचित्रता (रविवार की गलत-एक-से नंबरिंग, यूनियन-बनाम-इंटरसेक्शन डे-फ़ील्ड बग) इस विकास का निशान है; इसमें से कुछ भी एक ही बार में नहीं बनाया गया।

पाँच-फ़ील्ड अभिव्यक्ति की शारीरिक रचना

एक मानक cron अभिव्यक्ति व्हाइटस्पेस से अलग किए गए पाँच फ़ील्ड है। बाएँ से दाएँ पढ़ने पर, वे पूछते हैं: किस घंटे का कौन सा मिनट, किस माह का कौन सा दिन-का-माह, किस वर्ष का कौन सा माह, किस दिन-का-सप्ताह? POSIX cron में सटीक रेंज पर बातचीत नहीं हो सकती: मिनट 0-59, घंटा 0-23, दिन-का-माह 1-31, माह 1-12, दिन-का-सप्ताह 0-7 जिसमें 0 और 7 दोनों रविवार का प्रतिनिधित्व करते हैं। हर फ़ील्ड पाँच ऑपरेटरों को स्वीकार करता है जो स्वतंत्र रूप से जुड़ते हैं: * का अर्थ है हर मान्य मान; , असतत मानों की सूची को अलग करता है (0,15,30,45 * * * * हर घंटे शीर्ष पर, चौथाई बाद, आधे बाद, और तीन-चौथाई बाद चलता है); - एक समावेशी रेंज है (घंटा फ़ील्ड में 9-17 का अर्थ है 9, 10, 11, 12, 13, 14, 15, 16, 17); / एक स्टेप मान है (मिनट फ़ील्ड में */15 का अर्थ है शून्य से शुरू होकर हर पंद्रहवाँ मिनट, यानी 0, 15, 30, 45)। माह और सप्ताह के दिनों को तीन-अक्षर के संक्षिप्त रूप में भी लिखा जा सकता है: JAN-DEC और SUN-SAT। एक कार्यशील उदाहरण: */15 9-17 * * 1-5 इस तरह डिकोड होता है: घंटे 9 से 17 (समावेशी) के दौरान, माह के हर दिन, वर्ष के हर माह, सोमवार से शुक्रवार तक हर पंद्रह मिनट: “सप्ताह के दिनों में व्यावसायिक घंटों के दौरान हर तिमाही-घंटे”।

दिन-का-माह / दिन-का-सप्ताह का जाल

सबसे महत्वपूर्ण cron विचित्रता (जिसने पैंतीस वर्षों तक उत्पादन में आउटेज, छूटे बैकअप और चुपचाप ग़लत बिलिंग रन का कारण बना है) यह तरीक़ा है कि जब दिन-का-माह और दिन-का-सप्ताह दोनों फ़ील्ड प्रतिबंधित हों तो cron उन्हें कैसे जोड़ता है। POSIX भाषा यहाँ असामान्य रूप से सटीक है: “यदि ‘माह का दिन’ (फ़ील्ड 3) और ‘सप्ताह का दिन’ (फ़ील्ड 5) दोनों प्रतिबंधित हैं (‘*’ नहीं रखते), तो एक या दोनों वर्तमान दिन से मेल खाने चाहिए।” दूसरे शब्दों में, जब कोई भी फ़ील्ड वाइल्डकार्ड नहीं है, तो cron दोनों का संघ लेता है, कार्य उस किसी भी दिन चलता है जो किसी एक प्रतिबंध से मेल खाता है। यह उसके विपरीत है जो अधिकांश उपयोगकर्ता मानते हैं। 0 0 13 * 5 को ज़ोर से पढ़ना (“13 तारीख़ की आधी रात, शुक्रवार को”) स्वाभाविक रूप से एक चौराहे की तरह लगता है: केवल शुक्रवार 13। vixie-cron और इसके वंशजों में इसका वास्तव में अर्थ है “माह के हर 13 और हर शुक्रवार”, माह में लगभग नौ बार ट्रिगर होता है। और बुरा यह कि vixie-cron यह तय करता है कि संघ या चौराहे का उपयोग करे या नहीं, हर दिन फ़ील्ड के केवल पहले वर्ण का निरीक्षण करके। Paul Vixie ने स्वयं इस व्यवहार को एक बग के रूप में स्वीकार किया लेकिन इसे बदलने से इनकार कर दिया, यह नोट करते हुए कि इसे ठीक करने से सबसे कम आश्चर्य के सिद्धांत का उल्लंघन होगा, लाखों crontab पहले से ही इस धारणा पर लिखी गईं थीं कि मौजूदा व्यवहार जानबूझकर था। इसलिए बग अब एक विशेषता है, अमर और प्रसारित होती हुई। व्यावहारिक मानसिक मॉडल: यदि आप स्वयं को दिन-का-माह और दिन-का-सप्ताह दोनों को प्रतिबंधित करते पाते हैं और वास्तव में चौराहा चाहते हैं (जैसे “हर माह का दूसरा मंगलवार”), तो उन कार्यान्वयनों में # ऑपरेटर का उपयोग करें जो इसका समर्थन करते हैं (Quartz, एक्सटेंशन वाला cronie): 0 12 ? * 2#2। शुद्ध POSIX cron में, चौराहा एक एकल अभिव्यक्ति में व्यक्त करना वास्तव में असंभव है और आपको cron द्वारा बुलाई गई स्क्रिप्ट के अंदर फ़िल्टर करना होगा।

शॉर्टकट मैक्रो

ये शॉर्टकट POSIX नहीं हैं। सख्त केवल-POSIX वातावरण @daily को अस्वीकार करेंगे; व्यवहार में, हर cron कार्यान्वयन जिससे कोई पाठक मिलने की संभावना रखता है (vixie-cron, cronie, fcron, ISC cron, कंटेनर इमेज) उन्हें समर्थन करता है।

बोलियाँ, मानक बनाम Quartz बनाम AWS बनाम K8s बनाम systemd

“cron अभिव्यक्ति” अब परस्पर असंगत बोलियों का एक छोटा परिवार है। मानक 5-फ़ील्ड cron (POSIX, vixie-cron, cronie): मिनट घंटा दिन-का-माह माह दिन-का-सप्ताह, सार्वभौमिक न्यूनतम साझा भाजक। Quartz Scheduler (6 या 7 फ़ील्ड, Java इकोसिस्टम): सेकंड मिनट घंटे दिन-का-माह माह दिन-का-सप्ताह [वर्ष]; ?, L (अंतिम), W (कार्यदिवस), # (माह का n-वाँ कार्यदिवस) पेश करता है। Spring का @Scheduled और Spring Boot Quartz का उपयोग करते हैं। Kubernetes CronJob मानक 5-फ़ील्ड cron का उपयोग करता है, जिसमें एक अलग spec.timeZone फ़ील्ड है जो K8s 1.27 में GA हुआ (CronJob संसाधन स्वयं 1.21, अप्रैल 2021 में GA था); टाइमज़ोन फ़ॉर्मैट IANA tz डेटाबेस है (Europe/Berlin, America/New_York)। GitHub Actions cron शेड्यूल 5-फ़ील्ड POSIX cron का उपयोग करते हैं और UTC में चलते हैं। AWS EventBridge cron 6 फ़ील्ड (मिनट घंटे दिन-का-माह माह दिन-का-सप्ताह वर्ष) का उपयोग करता है, दिन-का-माह या दिन-का-सप्ताह में से किसी एक पर ? ऑपरेटर की आवश्यकता होती है (आप दोनों को प्रतिबंधित नहीं कर सकते), और 1-7 का उपयोग करता है जिसमें SUN=1, मतलब एक EventBridge अभिव्यक्ति 0 12 ? * 2 * सोमवार को दोपहर चलती है, मंगलवार को नहीं। systemd टाइमर पूरी तरह से एक अलग सिंटैक्स (OnCalendar=*-*-* 02:00:00) का उपयोग करते हैं और सिस्टम-स्तर शेड्यूलिंग के लिए आधुनिक Linux पर cron को धीरे-धीरे बदल रहे हैं, हालाँकि दोनों हर प्रमुख डिस्ट्रो पर साथ-साथ आते हैं। Cloud Scheduler (Google Cloud) स्पष्ट टाइमज़ोन कॉन्फ़िगरेशन के साथ मानक 5-फ़ील्ड cron का उपयोग करता है। प्लेटफ़ॉर्मों के बीच अभिव्यक्ति का अनुवाद सावधानीपूर्वक ध्यान की आवश्यकता है: कॉपी-पेस्ट किया गया EventBridge शेड्यूल vixie-cron में दिन-का-सप्ताह नंबरिंग बदलाव के कारण ग़लत कार्यदिवस पर चलेगा।

याद रखने योग्य सामान्य पैटर्न

सामान्य ख़तरनाक बिंदु

टाइमज़ोन। cron डिफ़ॉल्ट रूप से सिस्टम के स्थानीय समय का उपयोग करता है, क्लाउड मशीनों पर आश्चर्यजनक जो डिफ़ॉल्ट रूप से UTC होती हैं। UTC सर्वर पर सुबह 9 बजे का cron कार्य पूर्वी समय में सुबह 4 बजे ट्रिगर होता है। आधुनिक शेड्यूलर (Kubernetes 1.27+, AWS EventBridge, Cloud Scheduler) ने स्पष्ट टाइमज़ोन फ़ील्ड जोड़े हैं; क्लासिक cron नहीं। “*/N 0 से शुरू होता है” नियम। */15 0, 15, 30, 45 है, 5, 20, 35, 50 नहीं। ग़ैर-शून्य ऑफ़सेट से शुरू करने के लिए आपको गणना करनी होगी (5,20,35,50) या Quartz-only 5/15 सिंटैक्स का उपयोग करना होगा। 60-मिनट का ढेर लगने का जाल। एक कार्य जो अपने शेड्यूल अंतराल से अधिक समय लेता है, ढेर लग सकता है, हर 15 मिनट में चलने वाले तीन 30-मिनट के बैकअप ओवरलैप होंगे। मानक शमन flock(1) है: * * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob सुनिश्चित करता है कि एक समय में केवल एक इंस्टेंस चले; -n ध्वज लॉक अधिग्रहण को ग़ैर-अवरोधक बनाता है, इसलिए बाद में होने वाले आह्वान कतार में लगने के बजाय चुपचाप बाहर निकलते हैं। DST विसंगतियाँ। 02:30 के लिए निर्धारित cron कार्य उस दिन दो बार ट्रिगर होगा जब घड़ियाँ पीछे जाती हैं और उस दिन बिल्कुल नहीं जब वे आगे जाती हैं। cron के पास “DST का हिसाब रखने वाले वॉल-क्लॉक समय” की कोई अवधारणा नहीं है; यदि आपके शेड्यूल को DST संक्रमण से बचना है, तो इसे एक अप्रभावित घंटे (अधिकांश टाइमज़ोन में सुबह 3 बजे या बाद में) पर लंगर डालें या ऐसे शेड्यूलर का उपयोग करें जो टाइमज़ोन शब्दार्थ को समझता हो। PATH हटाना। cron कार्य न्यूनतम PATH (/usr/bin:/bin) और लगभग ख़ाली वातावरण के साथ चलते हैं; स्क्रिप्ट जो आपके इंटरैक्टिव शेल में काम करती हैं, cron में विफल हो सकती हैं क्योंकि node, python3 या aws विरासत में मिले PATH पर नहीं हैं। crontab के शीर्ष पर PATH= सेट करें या cron कमांड में निरपेक्ष पथ का उपयोग करें। ईमेल अतिप्रवाह। डिफ़ॉल्ट रूप से cron हर कार्य के आउटपुट को उपयोगकर्ता के स्थानीय मेलबॉक्स में ईमेल करता है; मेल कॉन्फ़िगर न होने वाले सर्वर पर यह चुपचाप /var/spool/mail को तब तक भरता है जब तक डिस्क ख़त्म नहीं हो जाती। आउटपुट को रीडायरेक्ट करें (>/dev/null 2>&1), crontab के शीर्ष पर MAILTO="" सेट करें, या वास्तव में मेल फ़ॉरवर्डर कॉन्फ़िगर करें।

आधुनिक विकल्प, कब कुछ और चुनें

cron एकल मशीन पर सरल आवर्ती कार्यों के लिए उत्कृष्ट है। यह इनमें कमज़ोर है: वितरित शेड्यूलिंग (एक ही कार्य प्रति मशीन एक बार के बजाय एक फ़्लीट में एक बार ट्रिगर होता है), इवेंट-ड्रिवन ट्रिगर (जब क्यू एक संदेश प्राप्त करता है तब चलें, घड़ी पर नहीं), मॉनिटरिंग (cron चुपचाप विफल होता है यदि कार्य नॉन-ज़ीरो से बाहर निकलता है जब तक कि आप ईमेल फ़ॉरवर्डिंग सेट अप नहीं करते), पुनः प्रयास (कोई अंतर्निहित तंत्र नहीं, विफल कार्य अगले चक्र में फिर से चलते हैं और स्थिति जमा करते हैं), और निर्भरताएँ (कार्य A सफलतापूर्वक पूरा होने के बाद ही कार्य B चलाएँ)। उन मामलों के लिए आधुनिक उत्तर इनमें से एक है: Kubernetes CronJob (रीट्राय और समानांतरता नीतियों के साथ क्लस्टर-जागरूक शेड्यूलिंग), AWS EventBridge + Lambda या Step Functions (अंतर्निहित अवलोकनीयता के साथ इवेंट-ड्रिवन), Apache Airflow या Prefect (स्पष्ट निर्भरताओं के साथ DAG-आधारित वर्कफ़्लो ऑर्केस्ट्रेशन), Temporal (टिकाऊ वर्कफ़्लो निष्पादन), healthchecks.io (एक “डेड मैन स्विच” जो आपको पिंग करता है जब cron कार्य समय पर नहीं चलता)। 2026 में एकल-मशीन आवर्ती कार्यों के लिए, साधारण cron अभी भी सही उत्तर है; किसी और चीज़ के लिए, विकल्पों में से एक अतिरिक्त सेटअप के लायक है।

अक्सर पूछे जाने वाले प्रश्न

cron अभिव्यक्ति में * का क्या अर्थ है?

cron फ़ील्ड में एक तारक (*) का अर्थ है “हर मान्य मान”, हर मिनट, हर घंटा, हर दिन, हर माह, हर दिन-का-सप्ताह। * * * * * हर दिन के हर मिनट चलता है। तारक दिन-का-माह और दिन-का-सप्ताह फ़ील्ड में भी विशेष है यूनियन-बनाम-इंटरसेक्शन जाल के कारण: जब किसी एक दिन फ़ील्ड में अग्रणी * होता है, vixie-cron चौराहे मोड का उपयोग करता है; जब किसी में नहीं होता, तो यह यूनियन मोड का उपयोग करता है और दोनों प्रतिबंधों के संघ पर चलता है।

मैं cron कार्य हर 15 मिनट में कैसे चलाऊँ?

स्टेप नोटेशन का उपयोग करें: */15 * * * * हर 15 मिनट चलता है, xx:00, xx:15, xx:30 और xx:45 पर। ध्यान दें कि */N हमेशा 0 से शुरू होता है; आप */15 का उपयोग “मिनट 5 से शुरू होकर हर 15 मिनट” के अर्थ में नहीं कर सकते, उसके लिए आप 5,20,35,50 * * * * लिखेंगे। Quartz-बोली cron 5/15 को एक ग़ैर-मानक विकल्प के रूप में समर्थन करता है।

cron और at के बीच क्या अंतर है?

cron कार्यों को दोहराव अनुसूची पर चलाता है (हर मिनट, दैनिक, साप्ताहिक)। at कमांड एक विशिष्ट भविष्य के समय पर चलने के लिए एक एक-बार के कार्य को शेड्यूल करता है, at 14:30 tomorrow उस एकल क्षण के लिए एक कार्य कतार में डालता है। आवर्ती कार्यों के लिए cron और एक-बार के भविष्य के निष्पादन के लिए at का उपयोग करें। दोनों एक ही Bell Labs / vixie-cron वंश से उतरते हैं और अंततः अधिकांश सिस्टमों पर एक ही डेमॉन में मिला दिए गए।

मेरा cron कार्य अपेक्षा से मेल क्यों नहीं खाता?

मोटे क्रम में पाँच सबसे सामान्य कारण: (1) दिन-का-माह बनाम दिन-का-सप्ताह भ्रम (जब दोनों प्रतिबंधित हों तो cron दोनों के यूनियन का उपयोग करता है, चौराहे का नहीं। (2) टाइमज़ोन) cron डिफ़ॉल्ट रूप से सर्वर के स्थानीय समय का उपयोग करता है, क्लाउड मशीनों पर अक्सर UTC। (3) PATH समस्याएँ, आपके इंटरैक्टिव शेल का PATH विरासत में नहीं मिलता, इसलिए जो कमांड प्रॉम्प्ट पर काम करते हैं, वे cron में विफल हो सकते हैं। (4) */N-हमेशा-0-से-शुरू होने वाला जाल। (5) आउटपुट कहीं कैप्चर नहीं हो रहा, विफल कार्य चुपचाप ग़ायब हो जाते हैं यदि आपने ईमेल सेट अप नहीं किया या आउटपुट को लॉग फ़ाइल पर रीडायरेक्ट नहीं किया। तैनात करने से पहले आपकी अभिव्यक्ति का वास्तव में क्या अर्थ है यह सत्यापित करने का सबसे सस्ता तरीक़ा इस एक्सप्लेनर का “अगले 10 निर्धारित रन” पैनल है।

क्या यह ग़ैर-मानक cron प्रारूपों का समर्थन करता है?

यह मानक 5-फ़ील्ड POSIX/vixie-cron, सेकंड के साथ 6-फ़ील्ड Quartz/Spring वैरिएंट, और विशेष स्ट्रिंग्स @hourly, @daily, @weekly, @monthly, @yearly और @reboot को संभालता है। यह पूर्ण Quartz एक्सटेंशन (L, W, #) या AWS EventBridge की 1-आधारित कार्यदिवस नंबरिंग को नहीं संभालता, उनके लिए, तैनाती से पहले प्लेटफ़ॉर्म के अपने वैलिडेटर का उपयोग करें।

क्या मेरी cron अभिव्यक्ति कहीं भेजी जाती है?

नहीं। पार्सिंग और व्याख्या पूरी तरह से आपके ब्राउज़र में JavaScript के माध्यम से चलती हैं। चिपकाई गई अभिव्यक्तियाँ कभी नेटवर्क पार नहीं करतीं, Explain पर क्लिक करते समय DevTools के Network टैब में सत्यापित करें। प्रोडक्शन CI कॉन्फ़िग्स, इन्फ़्रास्ट्रक्चर कोड, और ऑपरेशनल रनबुक्स में cron अभिव्यक्तियों के लिए सुरक्षित जहाँ शेड्यूल स्वयं संवेदनशील हो सकता है (जैसे रात के डेटाबेस निर्यात शेड्यूल जो डाउनटाइम विंडोज़ का संकेत देते हैं)।

संबंधित टूल