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

तुमची cron job का चालत नाही

“कधीच चालत नाही” असे वाटणारी cron job जवळजवळ नेहमीच एकदा तरी चाललेली असते. ती तुमच्या 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 ने job सुरू केली का? “cron ने job कधीच सुरू केली नाही” आणि “job सुरू झाली आणि बंद पडली” या काहीही साम्य नसलेल्या वेगळ्या समस्या आहेत. त्यामुळे प्रथम या प्रश्नाचे उत्तर शोधा.

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 म्हणतात. दिलेल्या मशीनवर यापैकी फक्त एकच name अस्तित्वात असते. त्यामुळे दोन command पैकी एका command ने unknown unit दाखवणे सामान्य आहे आणि ती त्रुटी नाही.

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

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

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

unit आणि log दोन्ही अस्तित्वात नसतील, तर cron install केलेले नसण्याची शक्यता आहे. 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 उपलब्ध नसतो

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

तुमच्या 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 स्थापित करतात. cron job ही file कधीही वाचत नाही. Versioned binary ला absolute path ने call करा किंवा तुमच्या script मधील पहिल्या ओळीत manager ची init script source करा.

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

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

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 पूर्णपणे बाहेर ठेवणे ही अधिक सुरक्षित सवय आहे. तो 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 करणे सोपे असते.

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

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

• crontab -e ही command चालवणाऱ्या user चा crontab संपादित करते. sudo crontab -e root चा crontab संपादित करते. एकाच server वर troubleshooting करणारे दोन लोक अनेकदा दोन वेगळ्या फाइल्स वाचत असतात.
• sudo crontab -l -u deploy दुसऱ्या user चा crontab दाखवते. Job ज्या account ने चालवायला हवा, त्या account साठी प्रत्यक्षात काय install केले आहे हे यामुळे पडताळता येते.
• /etc/crontab आणि /etc/cron.d मधील प्रत्येक फाइलमध्ये schedule आणि command यांच्या मध्ये एक अतिरिक्त field असतो: job कोणत्या user म्हणून चालवायचा ते. User crontab मधील पाच-field ची ओळ /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 आणि त्याच्या समकक्ष directory मध्ये ठेवलेल्या scripts ना हाच naming rule लागू होतो. त्यांच्यावर execute bit देखील असणे आवश्यक आहे. execute bit नसल्यास script शांतपणे skip केली जाते.
• /etc/cron.allow आणि /etc/cron.deny कोणाला crontab install करण्याची परवानगी आहे हे ठरवतात. तुमच्या server वर यापैकी कोणतीही फाइल असल्यास, user ला crontab वापरण्याची परवानगी आहे असे गृहीत धरण्यापूर्वी ती वाचा.

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

मालक permissions देखील ठरवतो. root च्या crontab मधील job root-owned files तयार करते. त्या files वाचणाऱ्या application ला त्यामध्ये लिहिता येणार नाही. सामान्य 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 ज्याचे नाव देते त्या ठिकाणी पाठवतो. मर्यादित सुविधांच्या VPS वर सहसा MTA (mail transfer agent) स्थापित केलेला नसतो, त्यामुळे हा मजकूर वितरित होत नाही. तुमची त्रुटी काही क्षण अस्तित्वात होती आणि नंतर कुठेही पोहोचली नाही. त्यामुळे बिघडलेले job शांत असल्यासारखे दिसते.

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

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

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

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

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

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

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

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

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

Command सापडल्यानंतर आणि त्याचे 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 मध्ये जा. एखादे job “मी ते हाताने चालवतो तेव्हा काम करते” याचे सर्वात सामान्य एकमेव कारण relative path असते.
• Locale हे तुमच्या session मधील locale नसते. Date किंवा number format करणारी अथवा text sort करणारी कोणतीही गोष्ट वेगळ्या LANG अंतर्गत वेगळे output देऊ शकते. पुढील step त्या output चे parsing करत असल्यास, अपेक्षा ठेवण्याऐवजी script मध्ये locale सेट करा.
• TTY (terminal) उपलब्ध नसतो. Confirmation मागणारी, editor उघडणारी किंवा progress bar दाखवणारी command hang होऊ शकते किंवा exit होऊ शकते. Tool देत असलेला non-interactive flag जो आवश्यक असेल तो जोडा.
• SSH agent उपलब्ध नसतो. SSH_AUTH_SOCK हे cron च्या environment मध्ये नसते. त्यामुळे तुमचा agent loaded असल्यामुळे चाललेली ssh किंवा rsync command आता authenticate होण्यात अपयशी ठरते. Job साठी स्वतंत्र key द्या आणि ती job च्या user च्या मालकीची ठेवा.
• User session bus उपलब्ध नसतो. त्यामुळे XDG_RUNTIME_DIR सेट करेपर्यंत cron job मधून systemctl --user अपयशी ठरते. 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 मध्ये चालवून त्यांच्याशी तुलना करा. PATH ओळ, working directory आणि locale यांमुळे failure चे कारण सहसा स्पष्ट होते. या setup मधील दोन गोष्टी लक्षात ठेवा: percent signs script मध्ये आहेत, त्यामुळे cron चा नियम त्यांना लागू होत नाही; तसेच log path असा आहे, ज्यावर job चालवणारा user write करू शकतो.

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

तुमच्या अपेक्षेप्रमाणे schedule आहे का?

वापरकर्त्याच्या 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 तुमचा server प्रत्यक्षात कोणता timezone वापरतो ते दाखवते. तुमच्या laptop सारखाच timezone आहे असे गृहीत न धरता तो तपासा.

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

*/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 चे समर्थन करण्यापेक्षा सोपे ठरते. service चा भाग लिहिताना cron कधीही विचारत नाही असा एक प्रश्न systemd विचारते: unit ला प्रत्यक्ष काम सुरू झाले आहे हे कसे कळेल? त्यामुळे आधी simple, forking आणि notify units साठी Type= चा अर्थ काय आहे हे वाचा. Default type अंतर्गत एखादी script स्वतःला daemonize करत असल्यास, प्रत्यक्ष प्रक्रियेशिवाय unit active दिसत राहते. 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 यापैकी काहीही न वापरता, वेगळ्या working directory मधून आणि कधीकधी वेगळ्या shell सह command सुरू करतो. प्रत्येक command साठी absolute paths वापरा. crontab च्या सुरुवातीला किंवा script मध्ये आवश्यक variables सेट करा. तसेच एक मिनिटांनी चालणारे probe job schedule करा. ते env | sort, pwd आणि id log file मध्ये लिहील. त्यामुळे अंदाज न लावता cron चे वास्तविक environment पाहता येईल.

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

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

crontab मध्ये date +%Y का अयशस्वी ठरते?

cron command field मध्ये % ला विशेष अर्थ देतो. पहिले escape न केलेले % command संपवते. त्यानंतरचा सर्व मजकूर त्या command कडे standard input म्हणून पाठवला जातो. त्यानंतरची प्रत्येक % नवीन ओळ बनते. त्यामुळे 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 वापरा. Exit status query करता यावा, network सुरू झाल्यानंतर job चालावा, randomized start delay हवा किंवा failure नंतर retry policy हवी असल्यासही timer वापरा. दोन्ही एकाच server वर चालू शकतात. त्यामुळे गरज निर्माण झाल्यावर jobs एकावेळी एक असे हलवता येतात.