cron merupakan daemon penjadwal tugas bawaan sistem operasi berbasis Unix dan Linux yang berjalan di latar belakang untuk mengeksekusi perintah pada waktu tertentu. Alat ini telah menjadi fondasi otomasi sistem selama puluhan tahun—dari pekerjaan rutin administrator server hingga skrip pemeliharaan sederhana di komputer pribadi. Dengan menguasai cron, pengguna dapat menghemat waktu dan menghindari pekerjaan repetitif yang rentan kesalahan manusia.
Pembelajaran cron sebaiknya dilakukan pada sistem milik sendiri atau lingkungan uji yang diizinkan. Menjalankan tugas terjadwal pada perangkat yang bukan milik pengguna—tanpa izin eksplisit—merupakan pelanggaran etika dan dapat melanggar hukum. Portal seperti kalilinux.net dan kalilinux.info sering menyediakan panduan lanjutan yang relevan untuk eksperimen di lingkungan yang aman dan terkontrol.
Artikel ini menjelaskan sintaks dasar crontab, menjabarkan lima kolom waktu yang menjadi inti penjadwalan, lalu membahas dua jebakan paling umum—zona waktu dan output kosong—yang sering membuat pemula bingung saat tugas cron tidak berjalan sesuai harapan.
Memahami Lima Kolom Waktu cron
cron menjalankan perintah terjadwal berdasarkan lima kolom waktu. Format lengkap satu baris di berkas crontab terdiri dari lima kolom waktu diikuti satu perintah shell. Kolom-kolom tersebut secara berurutan menentukan menit, jam, tanggal bulanan, bulan, dan hari dalam seminggu.
.---------------- menit (0 - 59)
| .-------------- jam (0 - 23)
| | .------------ tanggal (1 - 31)
| | | .---------- bulan (1 - 12)
| | | | .-------- hari (0 - 7) (Minggu=0 atau 7)
| | | | |
* * * * * /path/to/command arg1 arg2
Tanda bintang * berarti “setiap nilai”. Jadi * * * * * berarti perintah dijalankan setiap menit. Untuk menjalankan perintah setiap hari pukul 02:30 pagi, barisnya menjadi:
30 2 * * * /path/to/command
cron juga mendukung koma untuk daftar nilai, tanda hubung untuk rentang, dan garis miring untuk interval. Contoh:
0,15,30,45 * * * * /path/to/command
Baris di atas menjalankan perintah pada menit 0, 15, 30, dan 45 setiap jam. Sedangkan interval setiap 5 menit ditulis:
*/5 * * * * /path/to/command
Rentang juga bisa digunakan—misalnya 0 9-17 * * 1-5 berarti menjalankan perintah setiap jam penuh dari pukul 09:00 hingga 17:00, hari Senin hingga Jumat. Pemahaman mendalam terhadap lima kolom ini menjadi dasar sebelum melangkah ke konfigurasi yang lebih kompleks.
Ada beberapa hal yang perlu diperhatikan. Kolom hari dalam seminggu menerima nilai 0 hingga 7, di mana baik 0 maupun 7 sama-sama merepresentasikan Minggu. Kolom tanggal bulanan dan hari dalam seminggu bisa bekerja secara bersamaan atau terpisah tergantung implementasi cron yang digunakan. Pada beberapa sistem, jika kedua kolom ini diisi dengan nilai spesifik (bukan *), perintah dijalankan saat salah satu kondisi terpenuhi. Perilaku ini berbeda antara implementasi Vixie cron, dcron, dan lainnya—jadi dokumentasi sistem lokal selalu menjadi rujukan terbaik.
Menyunting Jadwal dengan crontab -e
crontab -e menyunting jadwal milik pengguna saat ini. Perintah ini membuka berkas crontab pengguna di editor teks default—biasanya nano atau vi—sehingga pengguna dapat menambah, mengubah, atau menghapus baris jadwal.
Setiap pengguna di sistem memiliki berkas crontab terpisah. Mengetik crontab -e sebagai pengguna biasa hanya memengaruhi jadwal pengguna tersebut—bukan pengguna lain dan bukan sistem secara keseluruhan. Untuk menjadwalkan tugas tingkat sistem, diperlukan akses root dan konfigurasi melalui berkas di direktori /etc/cron.d atau berkas /etc/crontab.
Langkah menyunting jadwal:
- Buka terminal pada sistem milik sendiri atau yang diizinkan.
- Jalankan
crontab -e. - Tambahkan baris baru pada akhir berkas, contoh:
0 3 * * * /home/user/backup.sh
Baris tersebut menjalankan skrip backup.sh setiap hari pukul 03:00.
- Simpan berkas dan keluar dari editor. cron otomatis memuat ulang jadwal tanpa perlu restart layanan.
Untuk melihat jadwal yang aktif, gunakan crontab -l. Untuk menghapus seluruh jadwal, crontab -r—namun perintah ini tidak meminta konfirmasi, jadi gunakan dengan hati-hati.
Beberapa sistem menyediakan editor pilihan melalui variabel lingkungan EDITOR atau VISUAL. Jika editor default tidak nyaman, pengguna dapat menjalankan:
export EDITOR=nano
crontab -e
Hal ini mengubah editor hanya untuk sesi terminal saat ini. Perubahan permanen dilakukan dengan menambahkan baris export EDITOR=nano ke berkas ~/.bashrc atau ~/.profile.
Penting untuk diingat bahwa cron berjalan dengan lingkungan minimal. Variabel lingkungan seperti PATH sering kali berbeda dari shell interaktif pengguna. Oleh karena itu, selalu gunakan path absolut untuk perintah dan skrip. Alih-alih menulis backup.sh, tulis /home/user/scripts/backup.sh. Pendekatan ini menghindari kegagalan akibat perintah tidak ditemukan.
Izin berkas juga perlu diperhatikan. Skrip yang dijadwalkan harus memiliki bit eksekusi aktif. Gunakan chmod +x /home/user/scripts/backup.sh untuk mengaktifkannya. Tanpa izin eksekusi, cron mencatat kesalahan di log sistem tetapi tidak menjalankan skrip. Pemula sering mengabaikan langkah ini dan kemudian bingung mengapa tugas tidak berjalan.
Jebakan Zona Waktu yang Sering Mengganggu
Salah satu jebakan paling umum dalam penjadwalan cron adalah zona waktu. cron membaca waktu berdasarkan zona waktu sistem tempat daemon berjalan—bukan zona waktu pengguna. Jika server berada di UTC tetapi pengguna berpikir dalam WIB (Waktu Indonesia Barat, UTC+7), tugas yang dijadwalkan pukul 02:30 sebenarnya berjalan pukul 09:30 WIB.
Perbedaan ini menjadi sumber kebingungan yang sangat sering dijumpai. Pemula sering mengira tugas cron gagal berjalan, padahal sebenarnya tugas tersebut berjalan—hanya pada waktu yang berbeda dari yang diasumsikan.
Untuk memastikan zona waktu yang digunakan cron:
timedatectl
Perintah tersebut menampilkan zona waktu aktif sistem. Outputnya menyertakan baris seperti “Time zone: Asia/Jakarta (WIB, +0700)” atau “Time zone: UTC (UTC, +0000)”.
Jika server cloud atau VPS baru disetel ke UTC secara default, pengguna perlu menyesuaikan jadwal cron dengan UTC atau mengubah zona waktu sistem. Mengubah zona waktu sistem memengaruhi seluruh layanan—bukan hanya cron—jadi pertimbangkan dampaknya terlebih dahulu. Pada lingkungan produksi yang menjalankan banyak layanan, sering kali lebih aman menyusun jadwal cron dalam UTC daripada mengubah zona waktu sistem.
Selain itu, transisi daylight saving time (DST) dapat menyebabkan tugas tertentu dilewati atau dijalankan dua kali di zona yang menerapkan DST. Indonesia tidak menerapkan DST, jadi masalah ini jarang dihadapi—namun penting diketahui jika sistem berkomunikasi dengan server di zona yang menerapkannya.
Memverifikasi zona waktu sebelum menulis jadwal cron adalah kebiasaan yang menghemat banyak waktu troubleshooting. Catat zona waktu sistem, konversikan ke zona waktu lokal jika perlu, lalu tulis jadwal berdasarkan zona waktu sistem—bukan asumsi pribadi.
Jika pengguna ingin cron menggunakan zona waktu tertentu tanpa mengubah zona waktu sistem, beberapa implementasi cron modern mendukung variabel CRON_TZ di dalam berkas crontab. Contoh:
CRON_TZ=Asia/Jakarta
0 9 * * * /home/user/morning-report.sh
Dukungan CRON_TZ bervariasi antar implementasi. Vixie cron pada distribusi Debian dan turunannya umumnya mendukungnya, namun verifikasi dokumentasi sistem lokal untuk memastikan kompatibilitas.
Menangani Output Kosong dan Berkas Log
Jebakan kedua yang sering membuat pemula kebingungan adalah output kosong. Secara default, cron mengirimkan keluaran stdout dan stderr dari setiap tugas melalui email lokal kepada pemilik crontab. Jika sistem tidak memiliki mail server yang terkonfigurasi, keluaran tersebut hilang begitu saja. Tugas mungkin gagal tanpa pesan kesalahan yang terlihat—seolah-olah cron diam-diam mengabaikan perintah.
Menyimpan keluaran ke berkas log memudahkan memastikan tugas benar-benar berjalan. Redirect sederhana ke berkas log cukup untuk mulai:
0 3 * * * /home/user/backup.sh >> /home/user/backup.log 2>&1
Notasi >> menambahkan keluaran ke akhir berkas log tanpa menghapus isi sebelumnya. 2>&1 mengarahkan stderr ke stdout sehingga pesan kesalahan ikut tercatat. Tanpa redirect ini, pesan error bisa hilang dan debugging menjadi sangat sulit.
Untuk pengelolaan log yang lebih baik, beberapa praktik umum dapat diterapkan.
Pertama, beri timestamp pada setiap entri log. Skrip shell dapat menambahkan timestamp dengan:
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backup started"
Kedua, rotasi log perlu dipertimbangkan. Berkas log yang terus tumbuh tanpa rotasi dapat memenuhi ruang disk. Utilitas logrotate tersedia di kebanyakan distribusi Linux untuk mengelola rotasi otomatis—atau pengguna dapat menulis skrip sederhana yang memindahkan dan mengompresi log lama secara berkala.
Ketiga, uji skrip secara manual sebelum dijadwalkan. Jalankan skrip langsung dari terminal untuk memastikan tidak ada kesalahan sintaks atau masalah izin. Jika skrip berjalan baik secara manual tetapi gagal saat dijalankan cron, kemungkinan masalahnya terletak pada lingkungan—PATH berbeda, variabel lingkungan tidak tersedia, atau izin berkas berbeda saat dijalankan dalam konteks cron.
Mendiagnosis masalah cron yang tidak menghasilkan output apapun bisa membuat frustrasi. Langkah pertama yang baik adalah memeriksa log sistem cron itu sendiri. Pada distribusi berbasis Debian dan Ubuntu, aktivitas cron tercatat di /var/log/syslog. Pada distribusi berbasis Red Hat, periksa /var/log/cron. Gunakan grep untuk memfilter entri yang relevan:
grep CRON /var/log/syslog
Baris tersebut menampilkan semua entri yang berkaitan dengan cron, termasuk waktu eksekusi dan pengguna yang menjalankan tugas. Jika tugas tidak muncul di log sama sekali, kemungkinan