तुमचा cron job का चालत नाही? 5 सामान्य कारणे

क्रॉन जॉब का execution का होत नाही

“कधीच चालत नाही” असे वाटणारा क्रॉन जॉब प्रत्यक्षात जवळजवळ नेहमी चाललेला असतो. तो तुमच्या shell पेक्षा वेगळ्या environment मध्ये चालला असेल, पहिल्याच सेकंदात fail झाला असेल आणि त्याचा संदेश तुम्ही पाहत नसलेल्या ठिकाणी गेला असेल. जवळजवळ प्रत्येक तक्रारीचे स्पष्टीकरण पाच कारणांनी देता येते: search path, percent sign, चुकीची crontab file, mail कडे गेलेले output आणि login session अपेक्षित असलेली script.

cron हा एक daemon (background service) आहे. तो crontab files वाचतो आणि schedule नुसार commands सुरू करतो. तो तुमचे .bashrc वाचत नाही, terminal उघडत नाही, login shell सुरू करत नाही आणि command fail झाल्यावर तुम्हाला सांगत नाही. खालील प्रत्येक कारण या चार तथ्यांमधून स्पष्ट होते.

ही कारणे क्रमाने तपासा आणि सर्व कारणांच्या मुळाशी असलेल्या प्रश्नापासून सुरुवात करा: cron ने जॉब सुरू केला का? “cron ने जॉब कधीच सुरू केला नाही” आणि “जॉब सुरू झाला आणि बंद पडला” या दोन वेगळ्या समस्या आहेत. त्यांच्यात काहीही समान नाही. त्यामुळे प्रथम या प्रश्नाचे उत्तर शोधा.

cron ने प्रत्यक्षात काम सुरू केले का?

वेगवेगळ्या distribution family मध्ये daemon चे unit name वेगळे असते. दोन्ही तपासा आणि त्यानंतर log वाचा.

systemctl status cron
systemctl status crond
journalctl -u cron --since "2 hours ago"
journalctl -u crond --since "2 hours ago"

Debian आणि Ubuntu या unit ला cron म्हणतात. Fedora, Rocky आणि Alma मध्ये त्याला crond म्हणतात. दिलेल्या मशीनवर या दोन नावांपैकी फक्त एकच अस्तित्वात असते. त्यामुळे दोनपैकी एका command कडून unknown unit असा संदेश मिळणे सामान्य आहे आणि ती त्रुटी नाही.

तुमच्या system ने स्वतः लिहिलेल्या entries वाचा. एखाद्या guide मधून कॉपी केलेली line शोधू नका, कारण cron implementations आणि logging setups नुसार wording बदलते. तुम्ही फक्त दोन गोष्टी तपासत आहात: schedule मध्ये नमूद केलेल्या minute ला entry आहे का, आणि त्या entry मध्ये तुमच्या command चे नाव आहे का. तुमच्या command चे नाव असलेली entry म्हणजे cron ने त्याचे काम केले आणि failure command च्या आत आहे. कोणतीही entry नसल्यास cron कडे तुमचे schedule कधीच आले नाही. हे खालील cause 3 आहे.

काही images cron messages rsyslog मार्फत journal ऐवजी file मध्ये पाठवतात. /var/log मध्ये cron किंवा syslog च्या नावाची file शोधा आणि तिचा शेवटचा भाग वाचा.

ls -l /var/log
sudo tail -n 50 /var/log/syslog

unit आणि log दोन्ही उपलब्ध नसतील, तर cron कदाचित installed नसेल. Minimal cloud images आणि containers मध्ये ते अनेकदा समाविष्ट केलेले नसते.

dpkg -l cron
rpm -q cronie
sudo apt install cron
sudo dnf install cronie
sudo systemctl enable --now cron

कारण 1: cron कडे तुमचा PATH उपलब्ध नसतो

तुमचा interactive shell /etc/profile, ~/.profile, ~/.bashrc आणि त्या फाइल्समधून source होणाऱ्या सर्व गोष्टींमधून PATH तयार करतो. cron job साठी यापैकी काहीही चालत नाही. cron स्वतःच्या लहान environment सह command सुरू करतो. त्यामुळे standard system directories च्या बाहेर असलेला program सापडत नाही. /usr/local/bin, /opt अंतर्गत असलेली कोणतीही गोष्ट, language version manager, Python virtual environment किंवा Go workspace यापैकी कोणतीही गोष्ट कारण असू शकते. Job पहिल्याच ओळीवर अयशस्वी होतो. त्यानंतर shell "not found" प्रकारची error लिहितो. नेमकी wording कोणता shell command चालवतो यावर अवलंबून असते.

तुमचा job वापरत असलेल्या प्रत्येक command चा वास्तविक path शोधा.

command -v docker
command -v node
readlink -f "$(command -v node)"

त्यानंतर ते absolute paths job मध्ये लिहा किंवा crontab च्या सुरुवातीला PATH एकदाच सेट करा.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3 * * * /usr/local/bin/mytool run

तुमच्या स्वतःच्या machine वरून echo "$PATH" वापरून ही यादी घ्या आणि फक्त interactive session मध्ये उपलब्ध असलेल्या गोष्टी काढून टाका. येथे एक नियम महत्त्वाचा आहे: cron या assignment lines मधील variables expand करत नाही. PATH=$PATH:/usr/local/bin मध्ये $PATH:/usr/local/bin हा literal text साठवला जातो. त्यामुळे job कडे usable directory नसलेला search path राहतो. संपूर्ण यादी स्पष्टपणे लिहा.

Version manager साठी केवळ path पुरेसा नसतो. nvm, pyenv, rbenv आणि asdf तुमच्या .bashrc मधून shell function किंवा shims directory install करतात. cron job ही file कधीही वाचत नाही. Versioned binary चा absolute path वापरा किंवा तुमच्या script मधील पहिल्या ओळीत version manager ची init script source करा.

कारण 2: टक्के चिन्ह तुमची कमांड समाप्त करते

crontab च्या command field मध्ये % हे सामान्य अक्षर नाही. पहिले escape न केलेले % command समाप्त करते. त्यानंतरचा सर्व मजकूर command कडे standard input म्हणून पाठवला जातो आणि पुढील प्रत्येक % नवीन ओळ बनते. प्रोग्रामला लहान input देण्यासाठी ही cron मधील वास्तविक सुविधा आहे. याच कारणामुळे date-stamped filename असलेली नोंद ही crontab मधील सर्वसाधारणपणे बिघडलेली नोंद ठरते.

0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +%F).tar.gz /srv/site लिहिल्यास tar ला formatted date कधीच दिसत नाही. cron पहिल्या % वर ओळ तोडतो. त्यामुळे shell ला अपूर्ण command substitution मिळते आणि तुमच्या ओळीचा उर्वरित भाग standard input म्हणून येतो. प्रत्येक percent च्या आधी backslash लावा.

0 3 * * * /usr/bin/tar -czf /srv/backups/site-$(date +\%F).tar.gz /srv/site

ती एकच ओळ दोन स्तर क्रमाने वाचतात. \% हा cron rule आहे. cron काहीही सुरू करण्यापूर्वी तो लागू होतो. $(date +\%F) हे command substitution आहे. cron ने सुरू केलेला shell नंतर ते लागू करतो. कोणते अक्षर कोणत्या स्तराच्या नियंत्रणाखाली आहे हे समजणे हाच मुख्य मुद्दा आहे.

crontab मधील logic शक्यतो पूर्णपणे बाहेरील script मध्ये ठेवणे अधिक सुरक्षित आहे. तो logic अशा script मध्ये ठेवा जिथे percent चिन्हाचा विशेष अर्थ नसतो.

#!/bin/bash
set -euo pipefail
stamp="$(date +%F)"
tar -czf "/srv/backups/site-${stamp}.tar.gz" /srv/site

त्यानंतर crontab ओळीत फक्त path आणि redirect राहतात. एका नजरेत वाचता येणारी crontab debug करणे सोपे असते.

कारण 3: तुम्ही कोणता crontab संपादित केला?

एकच crontab नसतो. वेगवेगळे मालक आणि वेगवेगळ्या field count असलेल्या अनेक फाइल्स असतात. चुकीच्या फाइलमध्ये लिहिलेला job दिसतच नाही.

• crontab -e ही कमांड चालवणाऱ्या user चा crontab संपादित करते. sudo crontab -e root चा crontab संपादित करते. एकाच मशीनवर troubleshooting करणारे दोन लोक अनेकदा दोन वेगळ्या फाइल्स वाचत असतात.
• sudo crontab -l -u deploy दुसऱ्या user चा crontab दाखवते. Job ज्या account ने चालायला हवा, त्याच्यासाठी प्रत्यक्षात काय installed आहे हे यामुळे पडताळता येते.
• /etc/crontab आणि /etc/cron.d मधील प्रत्येक फाइलमध्ये schedule आणि command यांच्या मध्ये एक extra field असतो: job कोणत्या user म्हणून चालवायचा तो user. Five-field user crontab मधील line /etc/cron.d मध्ये paste केल्यास command मधील पहिला शब्द username म्हणून वाचला जातो.
• /etc/cron.d मधील फाइल्सच्या नावांमध्ये फक्त letters, digits, underscores आणि hyphens असू शकतात. backup.sh किंवा site.conf नावाची फाइल केवळ नाव चुकीचे असल्यामुळे skip केली जाते. तिचे नाव backup असे बदला आणि पुन्हा log तपासा.
• /etc/cron.d मधील फाइल्स root च्या मालकीच्या असाव्यात. तसेच त्या group किंवा इतर users साठी writable नसाव्यात. ls -l /etc/cron.d ही दोन्ही माहिती एकाच वेळी दाखवते.
• /etc/cron.daily आणि त्याच्या समकक्ष directories मध्ये ठेवलेल्या scripts साठीही हेच naming rule लागू होते आणि त्यांच्यावर execute bit असणे आवश्यक आहे. execute bit नसल्यास script शांतपणे skip केली जाते.
• /etc/cron.allow आणि /etc/cron.deny यावरून कोणाला crontab install करण्याची परवानगी आहे हे ठरते. तुमच्या मशीनवर यापैकी कोणतीही फाइल असल्यास, तुमच्या user ला crontab वापरण्याची परवानगी आहे असे गृहीत धरण्यापूर्वी ती वाचा.

Spool file हाताने संपादित करण्याऐवजी crontab command वापरून user crontab install करा, कारण crontab install करण्यापूर्वी फाइल parse करते. Save केल्यानंतर command ने परत दाखवलेला output वाचा. फाइल नाकारल्यास मागील version कार्यरत राहते आणि तुमचा बदल लागू होत नाही. त्यामुळे cron तुमच्याकडे दुर्लक्ष करत आहे असे दिसते.

Permissions वर owner चा देखील परिणाम होतो. Root च्या crontab मधील job root-owned files तयार करते. त्या files वाचणाऱ्या application ला त्यात write करता येईलच असे नाही. सामान्य user च्या crontab मधील job root-only directory वाचू शकत नाही. कामानुसार owner निवडा: application maintenance ही application च्याच account कडे असावी. याच कारणामुळे WordPress wp-cron ऐवजी system cron job वापरणे समजून घेणे उपयुक्त आहे. तुमचा job तयार करत असलेल्या files चा mode त्याला मिळालेल्या umask वरून ठरतो. ही value तुमच्या shell मधील umask पेक्षा वेगळी असू शकते. त्यामुळे job चा output unreadable होत असल्यास umask file permissions कशा ठरवते हे वाचणे उपयुक्त ठरेल.

कारण 4: आउटपुट को कोणीही वाचत नसलेल्या मेलमध्ये पाठवले गेले

cron एखाद्या job ने standard output आणि standard error वर लिहिलेला सर्व मजकूर गोळा करतो. job ने काहीही आउटपुट लिहिले असल्यास, cron तो मजकूर crontab च्या मालकाला किंवा MAILTO ज्याचे नाव देते त्या पत्त्यावर स्थानिक mail system कडे पाठवतो. कमी घटक असलेल्या VPS वर सहसा MTA (mail transfer agent) install केलेला नसतो, त्यामुळे तो मजकूर कोठेही वितरित होत नाही. तुमची error काही क्षण अस्तित्वात होती आणि नंतर कुठेही पोहोचली नाही. बिघडलेला job शांत दिसण्याचे हेच संपूर्ण कारण आहे.

त्याऐवजी आउटपुट तुमच्या नियंत्रणातील file मध्ये पाठवा.

0 3 * * * /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

>> standard output file च्या शेवटी जोडतो. 2>&1 standard error ला त्या क्षणी standard output ज्या ठिकाणी पाठवला जातो, तिथे पाठवतो. त्यामुळे 2>&1 redirect नंतरच असणे आवश्यक आहे. उलट क्रमाने, म्हणजे 2>&1 >> file असे लिहिल्यास, standard error त्याचे मूळ destination ठेवतो. तुम्ही शोधत असलेली error नेमकी file पर्यंत पोहोचत नाही.

journal हे दुसरे चांगले destination आहे. logger तुम्ही निवडलेल्या tag अंतर्गत syslog मध्ये लिहितो.

0 3 * * * /usr/local/sbin/backup-site.sh 2>&1 | logger -t backup-site

journalctl -t backup-site वापरून तो मजकूर पुन्हा वाचा. यामुळे job चे स्वतःचे output cron entries च्या जवळ राहते आणि घटनाक्रम सहज समजतो. या मशीनवर कोणत्या व्यक्तीने कोणता command चालवला याची नोंदही हवी असल्यास, ती स्वतंत्र system आहे. त्यासाठी तुमच्या server वरील user commands चे auditing पहा.

crontab च्या सुरुवातीला MAILTO="" लिहिल्यास त्याखालील jobs साठी mail बंद होते. MAILTO मध्ये वास्तविक address दिल्याने तेव्हाच उपयोग होतो जेव्हा कार्यरत MTA उपलब्ध असतो. त्यामुळे त्यावर अवलंबून राहण्यापूर्वी mail या मशीनमधून बाहेर जातो याची खात्री करा.

debugging करताना एक नियम पाळा: > /dev/null 2>&1 कधीही जोडू नका. प्रत्येक crontab मधील ही सर्वाधिक वापरली जाणारी line आहे आणि ती तुमच्याकडील एकमेव पुरावा टाकून देते. job व्यवस्थित चालू लागल्यानंतर हवे असल्यास ती पुन्हा जोडा.

कारण 5: स्क्रिप्टमध्ये cron उपलब्ध करून देत नसलेले environment गृहीत धरले आहे

कमांड सापडल्यानंतर आणि तिचे output capture केल्यानंतर, तुमचे session तुम्हाला आपोआप उपलब्ध करून देते त्या इतर सर्व गोष्टींचा प्रश्न राहतो.

• Shell कदाचित bash नसेल. ls -l /bin/sh ने तपासा. Debian आणि Ubuntu वर ते dash कडे निर्देश करते. त्यामुळे double bracket test, arrays आणि source यांमुळे syntax error येतो. स्क्रिप्टमध्ये #!/bin/bash line द्या आणि स्क्रिप्ट call करा, किंवा crontab च्या सुरुवातीला SHELL सेट करा.
• Working directory तुम्ही ज्या directory मध्ये उभे होता ती नसते. सर्वत्र absolute paths वापरा, किंवा स्क्रिप्टच्या पहिल्या line मध्ये cd ने त्या directory मध्ये जा. Relative path हे job “मी ते manually चालवले तेव्हा काम करते” याचे सर्वात सामान्य एकमेव कारण आहे.
• Locale तुमच्या session सारखे नसते. Date किंवा number format करणारी अथवा text sort करणारी कोणतीही गोष्ट वेगळ्या LANG अंतर्गत वेगळे output देऊ शकते. पुढील step त्या output चे parsing करत असल्यास अंदाजावर अवलंबून न राहता स्क्रिप्टमध्ये locale सेट करा.
• TTY (terminal) उपलब्ध नसतो. Confirmation विचारणारी, editor उघडणारी किंवा progress bar दाखवणारी command अडकू शकते किंवा exit होऊ शकते. Tool देत असलेला non-interactive flag जो आवश्यक असेल तो जोडा.
• SSH agent उपलब्ध नसतो. SSH_AUTH_SOCK हे cron च्या environment मध्ये नसते. त्यामुळे तुमचा agent loaded असल्यामुळे आधी चाललेली ssh किंवा rsync command आता authenticate होण्यात अपयशी ठरते. Job च्या user च्या मालकीची स्वतंत्र key त्या job ला द्या.
• User session bus उपलब्ध नसतो. त्यामुळे cron job मधून systemctl --user अयशस्वी होते, जोपर्यंत XDG_RUNTIME_DIR सेट केले जात नाही. System unit हा अधिक योग्य उपाय आहे.

Fedora, Rocky आणि Alma वर आणखी एक संभाव्य कारण आहे. SELinux cron jobs वर निर्बंध लावते. त्यामुळे file permissions योग्य दिसत असतानाही, अनपेक्षित label असलेल्या path वर काम करणारी job नाकारली जाते. sudo ausearch -m avc -ts recent ने denials तपासा आणि काहीही बंद करण्यापूर्वी सर्व्हरसाठी SELinux ची मूलभूत माहिती वाचा.

cron चे environment दाखवणारी एक-मिनिटांची probe

cron च्या environment मध्ये काय आहे याचा अंदाज बांधणे थांबवा आणि ते थेट वाचा. सर्व माहिती dump करणारी script लिहा, ती प्रत्येक मिनिटाला schedule करा, प्रतीक्षा करा आणि नंतर file वाचा.

cat > /home/deploy/cron-probe.sh <<'EOF'
#!/bin/bash
echo "=== probe ==="
date -Is
pwd
id
echo "SHELL=$SHELL"
echo "LANG=$LANG"
command -v node || echo "node is not on this PATH"
env | sort
EOF
chmod +x /home/deploy/cron-probe.sh

प्रत्यक्ष job ज्या user म्हणून चालतो, त्या user च्या crontab मध्ये एक ओळ जोडा. दोन्ही बाजूंना absolute paths वापरा.

* * * * * /home/deploy/cron-probe.sh >> /home/deploy/cron-probe.log 2>&1

एक मिनिट प्रतीक्षा करा. त्यानंतर /home/deploy/cron-probe.log वाचा आणि त्याच commands आपल्या shell मध्ये चालवून मिळालेल्या output शी तुलना करा. PATH ओळ, working directory आणि locale यांमुळे failure चे कारण बहुतेक वेळा स्पष्ट होते. या setup मधील दोन बाबी लक्षात ठेवा: percent signs script मध्येच आहेत, त्यामुळे cron चा नियम त्यांना लागू होत नाही; तसेच log path असा आहे, ज्यावर job चालवणारा user write करू शकतो.

उत्तर मिळताच ती crontab ओळ delete करा. प्रत्येक मिनिटाला चालणारा आणि file मध्ये append करणारा job लहान disk भरून टाकू शकतो. तो हे शांतपणे करेल.

शेड्यूल तुमच्या अपेक्षेप्रमाणे आहे का?

वापरकर्ता crontab मधील ओळ पाच fields ने सुरू होते: minute, hour, day of month, month, day of week. यांपैकी दोन fields अशा प्रकारे परस्परांवर परिणाम करतात की अनेकांना त्याचे आश्चर्य वाटते.

day of month आणि day of week हे दोन्ही restricted असतील, म्हणजे त्यांपैकी एकही * नसेल, तर cron job चालवतो जेव्हा कोणतेही एक field जुळते. 0 0 13 * 5 म्हणजे "Friday the 13th" नाही. ते प्रत्येक महिन्याच्या 13 तारखेला मध्यरात्री आणि प्रत्येक शुक्रवारी मध्यरात्री चालते. एखादा विशिष्ट दिवस निवडायचा असल्यास, या दोन fields पैकी एक * ठेवा आणि दुसऱ्या field ची पडताळणी script मध्ये करा.

cron system timezone वापरतो. अनेक VPS images UTC (coordinated universal time) वर सेट केलेल्या असतात. त्यामुळे 03:00 साठी schedule केलेले job 03:00 UTC वाजता चालते, जे तुमच्या स्थानिक वेळेनुसार दुपारच्या मध्यावर असू शकते. timedatectl तुमचे box प्रत्यक्षात कोणता timezone वापरते ते दाखवते. तुमच्या laptop चा timezone समान आहे असे गृहीत न धरता, तुमच्या system वरील timezone तपासा.

आणखी दोन schedule traps लक्षात ठेवण्यासारखे आहेत. @reboot cron स्वतः सुरू झाल्यावर चालते. हा network तयार होण्याचा क्षण नसतो. त्यामुळे DNS किंवा remote host आवश्यक असलेले job boot वेळी अपयशी ठरू शकते आणि त्यानंतर प्रत्येक manual run वेळी यशस्वी होऊ शकते. तसेच एखादे slow job आधीची copy अजून चालू असतानाच पुन्हा सुरू होण्यापासून काहीही रोखत नाही. त्यासाठी lock वापरा.

*/5 * * * * /usr/bin/flock -n /tmp/backup-site.lock /usr/local/sbin/backup-site.sh >> /var/log/backup-site.log 2>&1

lock आधीच held असल्यास flock -n लगेच थांबते. त्यामुळे overlapping run पहिल्या run वर जमा न होता थांबते.

systemd timer हे अधिक योग्य साधन कधी ठरते

cron एका कामासाठी चांगले आहे: ठरावीक वेळी एखादी command चालवणे. इतर सर्व बाबतींत ते मर्यादित आहे. timer मध्ये कोणताही redirect न करता journal उपलब्ध असते, नंतर तपासता येणारा exit status मिळतो, network-online.target नुसार ordering करता येते आणि randomized delay देता येतो. त्यामुळे शंभर servers एकाच सेकंदाला सुरू होत नाहीत. तुमच्या job ला यापैकी कोणतीही सुविधा आवश्यक असल्यास, VPS वर systemd service आणि timer वापरणे crontab line चे समर्थन करण्यापेक्षा कमी कामाचे आहे. Retry behaviour देखील तिथेच ठेवावे, कारण systemd restart policies failure नंतर काय होईल हे ठरवतात. cron कडे या प्रश्नाचे कोणतेही उत्तर नाही.

लहान jobs साठी cron वापरत राहा. Dependencies किंवा retry policy असलेली कोणतीही गोष्ट timer वर हलवा. दोन्ही एकाच server वर चालू शकतात. त्यामुळे हे migration एका बैठकीत पूर्ण करणे आवश्यक नाही.

FAQ

माझे cron job हाताने चालते, पण cron मधून का अपयशी ठरते?

कारण तुमच्या shell आणि cron चे environment वेगवेगळे असतात. तुमचा login shell /etc/profile आणि ~/.bashrc वाचतो. त्यातून PATH, locale आणि agent variables सेट होतात. cron यापैकी काहीही न घेता command सुरू करतो. तो वेगळ्या working directory मधून आणि कधीकधी वेगळ्या shell सह सुरू होतो. प्रत्येक command साठी absolute paths वापरा. आवश्यक settings crontab च्या सुरुवातीला किंवा script मध्ये सेट करा. एक मिनिटांनी चालणारा probe job schedule करा. तो env | sort, pwd आणि id चालवून त्यांचा output log file मध्ये लिहील. त्यामुळे अंदाज न लावता cron चे प्रत्यक्ष environment वाचता येईल.

cron ने माझे job प्रत्यक्ष चालवले का हे कसे तपासावे?

daemon चा log वाचा. Debian आणि Ubuntu वर journalctl -u cron वापरा. Fedora, Rocky आणि Alma वर journalctl -u crond वापरा. काही images हे messages rsyslog मार्फत /var/log अंतर्गत असलेल्या file मध्ये पाठवतात. तुमच्या schedule मध्ये दिलेल्या minute साठी entry शोधा. त्या entry मध्ये तुमच्या command चे नाव आहे का ते तपासा. कोणतीही entry नसल्यास cron कडे तो schedule कधीच पोहोचला नाही. त्यामुळे तुम्ही योग्य crontab संपादित केली का ते तपासा. Entry आहे पण result नाही, याचा अर्थ command सुरू होऊन बंद झाला. त्यामुळे redirect वापरून त्याचा output capture करा.

crontab मध्ये date +%Y का बिघडते?

cron command field मध्ये % ला विशेष अर्थ देतो. पहिले escape न केलेले % command समाप्त करते. त्यानंतरचा सर्व मजकूर त्या command कडे standard input म्हणून पाठवला जातो. पुढील प्रत्येक % newline मध्ये रूपांतरित होते. त्यामुळे date-formatted filename तुम्ही लिहिलेल्या program पर्यंत पोहोचत नाही. प्रत्येक percent साठी \% वापरा. किंवा command एका script मध्ये हलवा आणि cron मधून तो script call करा. Script मध्ये percent sign चा विशेष अर्थ नसतो.

माझ्या cron job चा output कुठे जातो?

तो local mail system कडे जातो. तो crontab च्या owner ला किंवा MAILTO ज्याचे नाव देते त्या पत्त्यावर पाठवला जातो. बहुतेक VPS images मध्ये mail transfer agent install केलेला नसतो. त्यामुळे message discard होतो आणि job ने काही केले नाही असे दिसते. >> /path/to/log 2>&1 वापरून output file मध्ये redirect करा. Standard error हा standard output नंतर जाईल यासाठी हा क्रम कायम ठेवा. किंवा output logger -t myjob मधून pipe करा आणि journalctl -t myjob वापरून तो परत वाचा. Debugging पूर्ण होईपर्यंत > /dev/null 2>&1 वापरू नका.

cron वापरावे की systemd timer?

ठरावीक वेळी एखादी साधी command चालवायची असल्यास cron वापरा. विशेषतः systemd न चालवणाऱ्या machine वर हे job हलवावे लागू शकते तेव्हा cron योग्य आहे. Redirect न करता output journal मध्ये हवा असल्यास timer वापरा. Query करता येणारा exit status, network सुरू झाल्यानंतरचे ordering, randomized start delay किंवा failure नंतर retry policy हवी असल्यासही timer वापरा. एकाच server वर दोन्ही चालू शकतात. त्यामुळे आवश्यकतेनुसार jobs एकावेळी एक असे हलवता येतात.