2:00 और 3:00 बजे के cron jobs से बचें (2013)

• Linux सर्वरों में Daylight Saving Time (DST) बदलाव के दौरान होने वाली cron job त्रुटियों के बारे में चेतावनी देने वाला लेख
• हर साल दो बार, रविवार तड़के 2 बजे या 3 बजे टाइमज़ोन बदलने पर cron jobs के दोबारा चलने या छूट जाने की समस्या होती है
• एक वास्तविक मामले में, vixie-cron वातावरण में 3:00~3:01 के बीच की jobs 1 सेकंड के अंतराल पर 60 बार दोहराई गईं, जिससे ईमेल अव्यवस्था पैदा हुई
• समाधान के तौर पर UTC टाइमज़ोन सेट करना या उस समयावधि में jobs से बचना, और बेहतर open source scheduler विकसित करने का सुझाव
• सर्वर ऑपरेटरों और DevOps इंजीनियरों के लिए टाइमज़ोन बदलाव के जोखिम प्रबंधन के महत्व की याद दिलाने वाला उदाहरण

---

Daylight Saving Time और cron jobs का टकराव

• यदि रविवार तड़के 2 बजे या 3 बजे cron job सेट की जाए, तो वह Daylight Saving Time (DST) परिवर्तन के समय से टकराकर अप्रत्याशित execution errors पैदा कर सकती है
  • DST शुरू होने पर घड़ी एक घंटा आगे बढ़ती है, और खत्म होने पर एक घंटा पीछे जाती है, जिससे समय का दोहराव या छूटना होता है
  • इसके कारण किसी खास समय की jobs दो बार चल सकती हैं या बिल्कुल नहीं चल सकतीं
• खास तौर पर हर रविवार तड़के चलने वाली jobs पर साल में दो बार होने वाले DST बदलाव का असर पड़ता है
  • सामान्य दिनों में सब ठीक चलता है, लेकिन DST बदलाव वाले दिन असामान्य रूप से बार-बार execution हो सकता है

वास्तविक मामला: vixie-cron में repeated execution की समस्या

• Linux वातावरण के vixie-cron में DST शुरू होने पर 3:00~3:01 के बीच की job लगभग 60 बार, हर 1 सेकंड पर execute होने का मामला दर्ज किया गया
  • हर job दूसरी jobs से टकराई, जिससे ईमेल notifications की बाढ़ जैसी स्थिति बनी
  • अच्छी बात यह रही कि वह job गंभीर नहीं थी, इसलिए सिस्टम को नुकसान नहीं हुआ
• ऐसी समस्या cron की साधारण time-based scheduling संरचना से पैदा होती है
  • cron टाइमज़ोन बदलाव या DST transition को नहीं समझता, और सिर्फ तय समय देखकर jobs चलाता है

संभावित समाधान और विकल्प

• सबसे आसान तरीका है रविवार तड़के 2 बजे और 3 बजे के समय jobs शेड्यूल न करना
  • इस समयावधि से बचने पर DST transition से होने वाली repeated execution समस्या को पूरी तरह टाला जा सकता है
• सर्वर का टाइमज़ोन UTC पर सेट करना भी एक असरदार विकल्प है
  • UTC में Daylight Saving Time लागू नहीं होता, इसलिए समय बदलाव नहीं होता
• एक अधिक मूलभूत समाधान के रूप में ज़्यादा बुद्धिमान job scheduler विकसित करने का सुझाव दिया गया है
  • duplicate execution रोकने, execution time limits, और timezone awareness जैसी सुविधाओं वाले open source विकल्प की ज़रूरत है

दीर्घकालिक प्रस्ताव: Daylight Saving Time को समाप्त करना

• लेख के लेखक ने सरकारी स्तर पर DST को खत्म करना सबसे बेहतर समाधान बताया है
  • साल में दो बार होने वाला समय बदलाव सिस्टम संचालन और मानव जीवन, दोनों में अनावश्यक जटिलता लाता है
• लेकिन जब तक व्यवहारिक रूप से DST बना रहता है, सिस्टम एडमिन और DevOps इंजीनियरों को preventive measures लेने होंगे
  • खासकर automated batch jobs, backups, log rotation जैसी समय-निर्भर tasks के प्रबंधन में सावधानी ज़रूरी है

निष्कर्ष: सुरक्षित cron scheduling के सिद्धांत

• DST transition के दौरान 2:00~3:00 की समयावधि में jobs से बचना चाहिए
• जहाँ संभव हो, UTC-आधारित सर्वर संचालन से टाइमज़ोन समस्या को खत्म करें
• cron की सीमाओं को समझते हुए, ज़्यादा मज़बूत scheduling tools अपनाने पर विचार करना चाहिए
• DevOps वातावरण में टाइमज़ोन प्रबंधन और automation reliability सुनिश्चित करना एक अनिवार्य काम है

[semjei]

मेरे साथ भी सुबह 2 बजे सेट किए गए काम में समस्या हुई है (कभी एक बार की जगह दो बार चला, और कभी चला ही नहीं), इसलिए तब से मैं इसे ज़रूर टालता हूँ।

[GN⁺]

Hacker News की राय

• मुझे लगता है कि DST (daylight saving time) पूरी तरह गलत व्यवस्था है
  यह किसी भी समस्या का समाधान नहीं करती, बल्कि सिर्फ असुविधा पैदा करती है
  बस standard time पर स्थायी रूप से रहना चाहिए, और उसकी जगह काम के घंटे गर्मियों की तरह एक घंटा पहले कर देने चाहिए
  उदाहरण के लिए, दुकान 7 बजे की जगह 6 बजे खोली जाए और 10 बजे की जगह 9 बजे बंद की जाए
  वैसे भी साल में दो बार अनुकूलन की अवधि होती ही है, तो एक बार ही बदलना काफी है
  मैं काम के बाद ज़्यादा धूप देखना चाहता हूँ। सर्दियों में तो खास तौर पर, और दफ़्तर जाते समय सूरज निकला हो या नहीं, उससे फ़र्क नहीं पड़ता
  मैं 9 घंटे अंदर ही बंद रहने वाला हूँ, इसलिए जब मेरे पास अपना समय हो तब धूप देखना चाहता हूँ

  • हर कोई DST से नफ़रत करता है, लेकिन जो विकल्प सुझाए जाते हैं वे पहले आज़माए जा चुके हैं
    उदाहरण के लिए, 1973~1975 में अमेरिका का साल-भर DST प्रयोग हुआ था
    शुरुआत में ऊर्जा बचत और अपराध में कमी जैसी वजहों से इसका समर्थन काफ़ी था,
    लेकिन अंधेरी सुबह स्कूल जाते समय दुर्घटनाओं के कारण जनमत तेज़ी से बदल गया और अंत में इसे खत्म कर दिया गया
    (Wikipedia उद्धरण)
  • घड़ी न बदलकर कारोबारी समय बदलने की बात सुनकर यही सवाल उठता है कि क्या उसका असर आखिर वही नहीं होगा?
    आख़िर में यह और बड़ा time shift चाहने जैसा लगता है
  • ‘winter time’ नाम की कोई वास्तविक चीज़ नहीं है
    सिर्फ standard time और daylight saving time होते हैं
    ‘winter time’ को हमेशा रखने की बात मनोवैज्ञानिक रूप से आकर्षक नहीं लगती
  • DST बस सूर्योदय के समय के हिसाब से खुद को मिलाने का एक अस्थायी उपाय है
    लोग चाहते हैं कि वे अपना दिन तब शुरू करें जब बाहर रोशनी हो
    programmers को DST की वजह से दिक्कत होती है, लेकिन मेरा मानना है कि यह edge cases handle करने की समस्या है
  • standard time बनाम daylight saving time की बहस आखिरकार काम के समय चुनने की आज़ादी की कमी से पैदा होती है
    हर व्यक्ति का sleep pattern अलग होता है, इसलिए अगर सबको अपने हिसाब से काम का समय चुनने की छूट हो, तो टकराव कम होंगे

• जब पहले reddit server सेट कर रहा था, तब सब कुछ Arizona timezone पर सेट किया था
  Arizona में DST नहीं होता, इसलिए California से सिर्फ 1 घंटे का फ़र्क पड़ता है
  UTC इस्तेमाल नहीं किया क्योंकि logs पढ़ते समय ‘8 घटाने से 1 घटाना आसान था’
  अब global team बन चुकी है, इसलिए इसे UTC पर बदल दिया गया है

  • मैंने भी ऐसा ही फैसला लिया था, और बाद में सब कुछ समेटने में बहुत परेशानी हुई
    शुरुआत से ही सब कुछ UTC पर एकसमान रखना बेहतर है
  • लेकिन Arizona जैसे मामलों में timezone definition बदलने का जोखिम भी रहता है
    दुनिया भर में ऐसे बदलाव अक्सर होते रहते हैं, और calendar app developers के लिए यह सच में सिरदर्द है
  • यह बात खलती है कि log viewer UI browser language settings के आधार पर 12/24-hour format थोप देता है
    अगर किसी ने UTC चुना है, तो यह मान लेना चाहिए कि वह YYYY-MM-DD 24-hour format समझता है
  • Java में JVM स्तर पर default timezone सेट किया जा सकता है,
    लेकिन संगठन के अंदर लोग अपनी-अपनी तरफ़ से इसे PST में बदलकर इस्तेमाल करते रहे, जिससे हर log में अलग समय दिखने की गड़बड़ी पैदा हुई
    आखिरकार लीडर को बीच में आकर सभी applications और DB को PST पर एकसमान करना पड़ा
  • UTC में logs पढ़ते समय तारीख़ न बदलने वाली बात अब भी उलझन पैदा करती है
    फिर भी अब मैं सहज रूप से UTC समझने लगा हूँ

• पहले कंपनी के server को BST (British Summer Time) पर सेट किया था और cron का बहुत इस्तेमाल किया था,
  इसलिए हर साल दो बार एक जैसा भ्रम पैदा होता था
  कंपनी बंद होने तक भी इसे ठीक नहीं कर पाए
  सीख सीधी है — UTC इस्तेमाल करो, जब तक कि कोई खास वजह न हो

  • मैं डेस्क पर UTC analog clock रखता हूँ और logs देखते समय उससे मदद लेता हूँ
  • कुछ मामलों में local timezone इस्तेमाल किया जाता है क्योंकि ग्राहक UTC में नहीं होते
    उदाहरण के लिए usage limit reset या billing batch jobs क्षेत्रीय समय के आधार पर चलती हैं
  • cron खुद इस्तेमाल करने के बजाय, data और customer settings समझने वाला scheduler इस्तेमाल करना बेहतर लगता है
  • कुछ reports local time के हिसाब से चाहिए होती हैं
    उदाहरण के लिए UK की 8 बजे वाली report, DST के अनुसार UTC के संदर्भ में बदल जाती है
    इसलिए सिर्फ UTC से काम नहीं चलता, timezone information को साथ में store करना भी ज़रूरी है
  • finance जैसे क्षेत्रों में जहाँ market open time महत्वपूर्ण है, वहाँ सिर्फ UTC काफ़ी नहीं है

• कुछ देशों (Cuba, Egypt, Lebanon) में DST परिवर्तन आधी रात को होता है
  (संबंधित लिंक)

  • यह जानकर हैरानी हुई कि कुछ जगह DST परिवर्तन आधी रात को नहीं होता
    Brazil में 00:00~01:00 या 00:00~23:00 पर बदलना आम बात थी
  • timezone rules सच में बहुत अप्रत्याशित चीज़ें करती हैं

• एक अध्ययन के अनुसार DST adjustment वाले दिनों में मृत्यु दर और emergency room visits तेज़ी से बढ़ जाते हैं
  (ScienceAlert लेख)
  केवल cron की समस्या से आगे बढ़कर, DST स्वास्थ्य के लिए भी हानिकारक व्यवस्था है

• यह समस्या बहुत पहले OpenBSD और Debian में पहले ही हल की जा चुकी थी
  Debian के cron(8) manual में DST adjustment के समय 3 घंटे से कम के time shift को handle करने वाला logic समझाया गया है
  (patch लिंक,
  manual,
  bug report)

  • तो शायद मूल लेखक ने ऐसा distribution इस्तेमाल किया होगा जिसमें यह patch लागू नहीं था

• सलाह यह है कि आधी रात (00:00) पर jobs schedule न करें
  तारीख़ को लेकर भ्रम होना आसान है, इसलिए 00:01 या 01:45 जैसे थोड़े अटपटे समय इस्तेमाल करना बेहतर है

  • मैं भी cron jobs को XX:13, XX:23, XX:42 जैसे समय पर सेट करता हूँ
    जब सिस्टम किसी खास समय पर अजीब व्यवहार करे तो कारण ढूँढना आसान होता है
  • 00:00 ने शायद ही कभी समस्या पैदा की हो
    लेकिन 12-hour clock वाले environment में भ्रम हो सकता है

• timezone की समस्याओं से जूझने तक मुझे पता नहीं था कि दुनिया में ऐसे समय भी होते हैं जो मौजूद ही नहीं होते, और ऐसे समय भी जो अस्पष्ट होते हैं
  उदाहरण के लिए, 2 बजे से 3 बजे पर जाने के दौरान 2:30 अस्तित्व में ही नहीं होता,
  और उल्टा घड़ी पीछे करने पर 2:30 दो बार आता है
  हर देश में DST adjustment का समय अलग होता है, इसलिए Chile जैसे मामलों में आधी रात ही गायब हो सकती है
  (संबंधित ब्लॉग)
  याद है कि Java और Ruby ने इस स्थिति को अलग-अलग तरीके से handle किया था, और Stripe में काम की शुरुआत के दिनों में इससे लगातार 3 incidents हुए थे

• cron jobs को घंटे के ठीक शुरू में चलाने से बचाता हूँ, और संभव हो तो सुबह 4 बजे के बाद या आधी रात से पहले schedule करता हूँ
  क्योंकि shared infrastructure में ठीक घंटे पर resource contention ज़्यादा होता है

  • systemd का RandomizedDelaySec option इस्तेमाल करने से टकराव कम हो सकता है
  • cron command के आगे sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;
    जैसा code जोड़कर 0~59 मिनट की random delay देना भी अच्छा तरीका है

• महत्वपूर्ण scheduled jobs को जहाँ तक संभव हो idempotent (बार-बार चलने पर भी सुरक्षित) बनाना चाहिए
  खासकर जब queue system जुड़ा हो, तब ऐसा design समस्याओं को रोकने की कुंजी होता है