Cron Görevi Sessizce Çalışmıyorsa: PATH, Ortam ve Mail ile 5 Kontrol

Cron görevi iz bırakmadan kaybolunca ilk refleks scriptin kendisine bakmak oluyor. Benim ortamımda asıl sessiz katil genelde kullanıcının etkileşimli kabuğu ile cron'un verdiği minimal ortam arasındaki uyumsuzluk. Aşağıda cron'un neden çalışmadığını ortaya çıkarmak için kullandığım beş pratik adımı yazıyorum: PATH, ortam değişkenleri ve mail çıktısı.

1. Cron'un gördüğü PATH'i doğrula

Cron senin kullanıcının $PATH'ini miras almaz. Tipik olarak /usr/bin:/bin gibi çok kısıtlı bir set ile çalışır. Scriptin /usr/local/bin, /opt/... hatta ~/bin altındaki araçları çağırıyorsa iş "command not found" ile düşer; hatayı aramadığın sürece de görmezsin.

Cron'un gerçekten ne kullandığını görmek için ortamı dosyaya basan sahte bir iş koş:

* * * * * /usr/bin/env > /tmp/cron_env_$(date +\%s).txt 2>&1

Bir dakika sonra dosyaya bak. PATH satırının kısa olduğunu görürsün. Çözüm iki şekilde:

• Scriptte/komutta mutlak yol kullan (mytool yerine /usr/local/bin/mytool).
• crontab'ın tepesine PATH koy:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
* * * * * /usr/local/bin/mytool --option

2. Diğer ortam değişkenlerini kontrol et

PATH dışında cron çoğu değişkeni temizler. HOME, LOGNAME veya güvendiğin özel değişkenler (AWS_PROXY, JAVA_HOME) eksik olabilir. Aynı env-dump hilesi neyin geldiğini gösterir.

İhtiyacın olan değişkenleri crontab satırında veya bir sarmalayıcı scriptte tanımla:

AWS_PROFILE=production
HOME=/home/furkan
* * * * * /usr/local/bin/aws s3 sync /data s3://my-bucket/backup

Alternatif olarak bir profil dosyasını source et:

* * * * * . /home/furkan/.profile && /usr/local/bin/mytool

3. Çıktıyı ve maili yakala

Varsayılan olarak cron stdout/stderr'i crontab sahibinin yerel kutusuna postalar. Mail kurulu değilse hiçbir şey görmezsin. Önce sistemin mail atabildiğini doğrula:

echo "test" | mail -s "cron test" $(whoami)

"mail: cannot send message: process exited with error status" alırsan bir MTA kur (postfix, exim, ssmtp) veya MAILTO= ile dış adrese yönlendir:

[email protected]
* * * * * /usr/local/bin/mytool

Maile güvenmek istemezsen çıktıyı log dosyasına al:

* * * * * /usr/local/bin/mytool >> /var/log/mytool.log 2>&1

Sonra tail -f ile izle. İş çalışıyor ama görünür hata üretmiyorsa da işine yarar.

4. Sistem loglarında cron hatalarına bak

Mail düşse bile cron daemon kendi denemelerini yazar. systemd'li sistemlerde:

journalctl -u cron --since "10 minutes ago"

Eski SysVinit'te /var/log/syslog veya /var/log/cron. Tipik satırlar şöyle durur:

CRON[12345]: (furkan) CMD (/usr/local/bin/mytool)
CRON[12345]: (furkan) MAIL (mailed 1 byte of output; but got exit status 1)

(furkan) CMD (...) görüp devamı yoksa iş başlamış ama hemen çıkmış demektir — büyük ihtimalle eksik PATH veya env.

İpucu: Debian/Ubuntu'da geçici olarak /etc/default/cron içinde EXTRA_OPTS="-L 15" koyup cron'u restart edersen her işin exit kodunu loglar.

5. İşi cron benzeri ortamda test et

Sorunu yeniden üretmenin en sağlam yolu, komutu cron'un kullandığı ortamla koşmak. env -i ve minimal PATH ile simüle edebilirsin:

env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOME=$HOME /usr/local/bin/mytool

Bu düşerse cron hatasını yeniden üretmişsindir. Komut veya sarmalayıcı başarılı olana kadar düzelt, çalışan satırı crontab'a geri koy.

Linux'ta yüksek CPU ayıklarken yazdığım gibi: sistematik izolasyon tahminden iyidir. Aynı prensip burada da geçerli: bir seferde bir değişkeni değiştir, sonucu izle, devam et.

PATH'i kontrol etmek, ortamı denetlemek, çıktıyı yakalamak, daemon loglarına bakmak ve temiz env'de test etmek — sessiz cron kaçışlarını duyulur, aksiyon alınabilir uyarılara çevirmenin yolu bu.

Kapak görseli: njn.icon6 · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/145773616@N02/46414869341