Belajar Cron Job - Debugging & Testing Job

#Pendahuluan

Di episode 6 kita sudah tahu bahwa environment adalah penyebab utama kegagalan job. Sekarang kita bangun disiplin debugging — urutan langkah terstruktur yang memecah masalah cron menjadi bagian-bagian kecil yang bisa diuji satu per satu.

Prinsipnya sederhana: debug dari dalam ke luar. Uji perintahnya dulu, lalu scriptnya, lalu crontab-nya, lalu daemon-nya. Setiap lapisan yang lolos menyempitkan lokasi masalah.

#Alur Debugging yang Terstruktur

#1. Tes Command Secara Manual

Selalu jalankan command persis seperti di crontab, dari terminal:

/usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
echo "exit code: $?"

Perhatikan dua hal: apakah output benar, dan apakah exit code 0. Exit code non-0 berarti ada yang gagal di level perintah — sebelum cron ikut bermain.

#2. Cek Environment Cron

Jalankan script dengan environment yang sama seperti cron (ingat episode 6):

env -i /usr/bin/sh -c '/usr/local/bin/backup.sh'
echo "exit code: $?"

env -i menghapus seluruh environment — simulasi paling dekat dengan kondisi cron. Jika gagal di sini, masalahnya environment.

#3. Periksa Exit Code dan Log

Exit code adalah bahasa komunikasi script dengan cron:

• 0 = sukses.
• Non-0 = gagal; nilai menunjukkan jenis error (misal 127 = command not found, 126 = tidak bisa dieksekusi).

Cek juga /var/log/cron untuk melihat apakah crond benar-benar mengeksekusi baris tersebut:

grep backup /var/log/cron

#4. Gunakan File Sentinel

File sentinel membuktikan bahwa job benar-benar dieksekusi — dan kapan:

* * * * * touch /tmp/cron-ran-$(date +%Y%m%d-%H%M).flag

Setelah satu menit, cek:

ls -l /tmp/cron-ran-*.flag

Jika file muncul, jadwal dan daemon bekerja; masalah ada di perintahnya. Jika tidak muncul, masalah ada di jadwal atau daemon.

#5. cron -n: Jalankan crond di Foreground

Cronie menyediakan cron -n yang menjalankan crond di foreground — ideal untuk mengamati langsung apa yang terjadi:

sudo systemctl stop crond
sudo crond -n -l 8

Log berlevel 8 (debug penuh) akan dicetak ke terminal. Ini cara tercepat melihat mengapa jadwal tidak memicu. Setelah selesai, kembalikan daemon normal:

sudo systemctl start crond

#Tools Validasi Sintaks

#crontab.guru

crontab.guru adalah validator sintaks jadwal cron populer. Tempel jadwal, dan situs menjelaskan artinya dalam bahasa manusia — juga memperingatkan kombinasi aneh seperti OR pada day-of-month/day-of-week.

#Tes dengan Waktu Dekat

Strategi paling efektif untuk memverifikasi jadwal: gunakan waktu yang sangat dekat alih-alih menunggu jam jadwal:

* * * * * /usr/local/bin/myjob.sh >> /tmp/test.log 2>&1

Saksikan eksekusi dalam satu menit, perbaiki, lalu ubah ke jadwal sebenarnya. Jangan pernah men-debug jadwal 0 2 * * * — menunggu pukul dua pagi bukan cara yang efisien.

#Ringkasan Alur Debugging

#Penutup

Inti yang harus dibawa pulang:

• Debug dari dalam ke luar: perintah → environment → jadwal → daemon.
• Cek exit code — ia adalah bahasa komunikasi script dengan cron.
• File sentinel membuktikan eksekusi secara kasat mata.
• cron -n menjalankan crond di foreground dengan log debug penuh.
• Validasi jadwal di crontab.guru, dan uji dengan * * * * * bukan jam jadwal.

Di episode 8 selanjutnya kita akan membahas anacron dan system cron directories — bagaimana anacron menjalankan job yang tertunda untuk mesin yang sering mati, konfigurasi /etc/anacrontab, dan cara kerja /etc/cron.hourly|daily|weekly|monthly/ lewat run-parts, plus kapan memakai masing-masing!