Cron vs systemd timers: आपके लिए कौन सा सही?

आधुनिक distro पर, अपनी बनाई हर चीज़ के लिए systemd timer इस्तेमाल करें और cron को one-line user jobs तथा उन servers के लिए रखें जिन्हें आपने ख़ुद सेट नहीं किया। Timer हर run को journal में log करता है, मशीन बंद रहने के दौरान छूटे schedule को बाद में निभा सकता है, और system की बाक़ी हर चीज़ की तरह उन्हीं unit files पर टिका है। Cron संक्षिप्तता में जीतता है — एक crontab -e line, दो unit files से बेहतर है — और minimal containers व अजीब Unix boxes पर यह अकेला scheduler है जिसकी मौजूदगी पक्की है। लेकिन एक दम भारी कमी है: cron चुपचाप फेल होता है। अगर आपकी job रात 3 बजे error दे, तो cron उस लोकल mailbox पर mail भेजता है जिसे कोई पढ़ता नहीं, जबकि timer आपको journalctl -u mytimer.service के साथ पूरा output देता है। आगे: असली फ़र्क़, दोनों को कैसे टेस्ट करें, timer trigger क्यों न हो, और एक decision table।

cron और systemd timer में फ़र्क़ क्या है?

Cron एक daemon है जो lines की एक table पढ़ता है — पाँच time fields और एक कमांड — और wall clock मैच होते ही हर कमांड चला देता है। पूरा model बस इतना ही। इसमें job कोई object नहीं है: न unit, न status, न dependencies, न अपना कोई log entry।

systemd timer एक unit file (foo.timer) है जो अपने schedule पर दूसरी unit file (foo.service) चला देती है। Job यहाँ first-class object है — start, status, logs और failure tracking किसी और service की तरह। Schedule या तो calendar-based होता है (cron जैसा) या monotonic (OnBootSec=15min, जिसे wall-clock के बदलने से धोखा नहीं हो सकता)।

अमली नतीजे:

• Logging: timer हर unit का stdout/stderr journal में लिखते हैं; cron से अधिकतम लोकल user को mail जाती है।
• छूटे हुए runs: Persistent=true वाला timer boot पर एक बार चलता है अगर उसका schedule छूट गया था; cron बस आगे निकल जाता है।
• Dependencies: timer network-online.target या mount points का इंतज़ार कर सकते हैं; cron में script के अंदर retry logic ख़ुद लिखनी पड़ती है।
• Syntax: cron एक line है; timer दो फ़ाइलें। Switch करने की पूरी क़ीमत इतनी ही है।

Schedule syntax कौन सी आसान है — crontab या OnCalendar?

Cron के पाँच fields पुराना और सघन हिस्सा हैं: */15 * * * * का मतलब हर 15 मिनट है, और ज़्यादातर admins इन्हें नींद में भी पढ़ लेते हैं। Systemd का OnCalendar= लंबा-चौड़ा है पर कहीं ज़्यादा अभिव्यक्त है, और systemd-analyze calendar आपके commit करने से पहले अगले runs बता देता है — cron में ऐसा कोई dry-run नहीं।

# Cron: हर रोज़ 03:30 बजे
30 3 * * * /usr/local/bin/backup.sh

# systemd: वही schedule, save करने से पहले जाँचा जा सकता है
systemd-analyze calendar "*-*-* 03:30:00"
# -> Next elapse: Fri 2026-09-11 03:30:00 ...

OnCalendar वे चीज़ें भी सँभाल लेता है जिन्हें cron साफ़-साफ़ कह ही नहीं सकता: Mon..Fri *-*-* 09..17:00:00 (हफ़्ते के working days, business hours), या *:0/15 के साथ RandomizedDelaySec=10m, ताकि हज़ार मशीनें एक ही पल सर्वर पर न गिर पड़ें।

systemd timer बिना इंतज़ार के कैसे टेस्ट करें?

तीन कमांड सब बता देती हैं। देखें क्या schedule है और कब अगली बार चलेगा, फिर job को हाथ से ठीक उसी अंदाज़ में चलाएँ जैसे timer चलाता, फिर उसके logs पढ़ें:

systemctl list-timers --all                 # हर timer, अगली + पिछली run
sudo systemctl start backup.service         # job अभी चलाएँ, timer वाली ही unit
journalctl -u backup.service -f             # उसका output लाइव देखें

इस बँटवारे पर ध्यान दें: systemctl start backup.timer schedule को armed करता है; असली service ही job है। अगर list-timers आपका timer दिखाए, systemctl status backup.service हरी रहे, और journal में आपका output आए — तो पूरी chain चल रही है।

cron job मैन्युअली कैसे चलाएँ?

Cron jobs एक छँटा हुआ environment लेकर चलते हैं, इसीलिए “मेरी shell में चलती है, cron में फेल होती है” एक पूरी genre की bug है। Cron को सच्चाई से दोहराने के लिए, कमांड को उसी environment के साथ sh से चलाएँ जो cron इस्तेमाल करता:

crontab -l                                  # ठीक वही line कन्फ़र्म करें
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # cron ने इसे चलाया भी या नहीं? (Debian/Ubuntu)
journalctl -u cron -n 20                    # वही बात, systemd वाले distros पर

वह env -i line ही ईमानदार manual test है: cron के default PATH वाला निरा environment। ज़्यादातर चुपचाप फेल होने वाली cron jobs की वजह निरा PATH या कमांड में बिना quote का % होता है (cron % को newline समझता है), और दोनों इस तरह तुरंत पकड़ में आते हैं।

मेरा systemd timer trigger क्यों नहीं हो रहा?

चार वजहें लगभग हर case को कवर करती हैं, जाँचने के क्रम में:

1. Service और timer के नाम मेल नहीं खाते। foo.timer को foo.service चलाना है — typo वाला OnFailure या rename हो चुकी unit का मतलब है कि timer “चलकर” कहीं जा ही नहीं रहा। systemctl cat foo.timer ठीक-ठीक बताता है कि वह किसे target कर रहा है।
2. Timer बदला गया पर reload नहीं हुआ। Unit file बदलने के बाद: sudo systemctl daemon-reload && sudo systemctl restart foo.timer। इसके बिना आपका नया schedule live नहीं हुआ।
3. Persistent=true, OnCalendar की जिन semantics की आपको उम्मीद है उनके बिना — या आप systemctl status foo.timer देख रहे हैं (idle में भी हमेशा active दिखाता है) list-timers की जगह।
4. जिस service को यह चलाता है वह तुरंत फेल हो रही है, इसलिए timer मरा हुआ लगता है। journalctl -u foo.service --since -1h वह crash दिखा देगा जिसे list-timers छिपा लेता है।

और जब logs देखने ही जाएँ, तो journalctl cheat sheet वे filters (-u, --since, -f) समझाता है जो यह काम तेज़ कर देते हैं।

Cron vs systemd timers: फ़ैसले की table

	cron	systemd timer
Setup	एक crontab line	दो unit files
Logging	लोकल mail, जिसे आम तौर पर कोई पढ़ता नहीं	journal, हर unit का अलग
छूटी run (मशीन बंद)	skip हो जाती है	Persistent=true से एक बार चलती है
Dependencies / क्रम	कोई नहीं — script में ख़ुद बनाएँ	पूरी unit dependencies
Random देरी	$RANDOM से ख़ुद	RandomizedDelaySec=
Schedule का test/dry-run	नहीं	systemd-analyze calendar
हर जगह मौजूद	हाँ — containers, BSD, embedded	systemd (PID 1) ज़रूरी
बिना root user jobs	crontab -e	systemd --user units

काम के नियम: अपनी systemd मशीन पर job उतारनी है → timer। Quick personal reminder या वह box जिसे आपने ख़ुद नहीं बनाया → cron। Dependencies, retries, या यह जानने की ज़रूरत कि वह चला भी या नहीं → हमेशा timer। एक आम pattern है timer से चलती maintenance job — मान लीजिए रोज़ रात का rsync backup — जहाँ Persistent=true भरोसा देता है कि backup होगा, चाहे तय समय पर मशीन सो रही थी, जो cron दे ही नहीं सकता।