Perintahnya diketik di terminal, jalan. Ditaruh di crontab, diam aja. Nggak ada error, nggak ada file, nggak ada apa-apa.
Ini keluhan paling sering, dan penyebab nomor satunya selalu sama.
PATH cron itu pendek banget
Cron nggak baca .bashrc, .profile, atau setelan shell Anda. Dia jalanin perintah dengan lingkungan yang hampir kosong.
Artinya php yang jalan di terminal Anda bisa jadi nggak ketemu sama sekali sama cron.
Jalan keluarnya tulis jalur penuh ke tiap program:
# Salah, jalan di terminal tapi diam di cron
0 2 * * * php /var/www/app/spark cnp:cron
# Bener
0 2 * * * /usr/local/bin/php /var/www/app/spark cnp:cronCari jalur penuhnya pakai which php.
Hal yang sama berlaku buat file yang dipanggil script Anda. Jalur relatif di dalam script cron dihitung dari folder home, bukan dari letak scriptnya.
Output cron jadi email, bukan ilang
Tanpa pengalihan, tiap baris output dikirim jadi email lokal ke pemilik crontab. Kalau kotak email itu nggak pernah dibuka, dan di server biasanya nggak, pesan errornya ada di situ, nggak kebaca, sementara file mail-nya numpuk sampai penuh.
Alihin ke file biar kebaca:
0 2 * * * /usr/local/bin/php /var/www/app/spark cnp:cron >> /var/log/cron-app.log 2>&12>&1 itu penting. Tanpa itu cuma output biasa yang kecatat, dan pesan errornya justru masuk ke aliran lain.
Zona waktu server, bukan zona waktu Anda
Server yang disetel UTC bakal jalanin jadwal "jam 2 pagi" di jam 9 pagi WIB.
timedatectlIni sering kelewat soalnya jadwalnya tetap jalan, cuma di waktu yang salah. Dan "pekerjaan berat jalan di jam sibuk" itu gejala yang susah dihubungin ke penyebabnya.
Tanggal sama hari itu "atau", bukan "dan"
Kalau medan tanggal sama medan hari dua-duanya diisi, cron jalanin tugas di tanggal yang cocok atau di hari yang cocok.
Jadi 0 0 1 * 1 itu bukan "tanggal 1 kalau jatuh Senin". Artinya "tiap tanggal 1, dan juga tiap Senin". Jauh lebih sering dari yang dimaksud.
Kalau yang diinginkan beneran irisan dua-duanya, cron nggak bisa nyatain itu. Cek harinya di dalam script.
Pembaca & Penyusun Jadwal Cron nerjemahin ekspresi jadi kalimat sekalian ngitung berapa kali sehari dia jalan. Angka kedua itu yang biasanya bikin kaget.
Tugas yang numpuk
Jadwal tiap menit dengan tugas yang butuh tiga menit itu ngasilin tiga salinan jalan bareng, terus enam, terus server kehabisan memori.
Bungkus pakai flock:
* * * * * /usr/bin/flock -n /tmp/tugas.lock /usr/local/bin/php /var/www/app/spark queue-n artinya "kalau lagi kekunci, lewatin aja", bukan nunggu.
Kapan systemd timer lebih bagus
Buat server yang sering dimatiin, timer punya satu keunggulan yang nentuin. Persistent=true jalanin tugas yang kelewat gara-gara mesinnya lagi mati. Cron ngelewatin gitu aja.
Di server yang dimatiin tiap malam, itu artinya backup harian yang nggak pernah jalan sama sekali. Dan nggak ada yang ngasih tahu.
Timer juga nyatet hasilnya rapi di journal, journalctl -u nama, dan bisa nyebar waktu mulai secara acak biar puluhan mesin berjadwal sama nggak nabrak server tujuan bareng-bareng.
Generator Unit systemd nyusun dua-duanya. Satu hal yang sering kebalik: di pola timer, yang di-enable itu timer-nya, bukan service-nya. Nge-enable service bikin dia jalan sekali pas boot terus nggak pernah lagi.