Mengenal Cron Job: Cara Linux Menjalankan Tugas Sesuai Jadwal

Ada pekerjaan di server yang nggak bisa nunggu manusia ingat untuk melakukannya. Backup perlu jalan tiap malam. File log lama perlu dibersihkan tiap minggu. Sebuah laporan perlu dikirim lewat email tiap Senin jam 8 pagi. Kamu bisa saja pasang alarm dan mengerjakannya manual selamanya — atau kamu serahkan saja tugas itu ke cron, bagian dari Linux yang seluruh tujuan hidupnya memang menjalankan sesuatu sesuai jadwal, diam-diam, tanpa perlu kamu tongkrongin.

Cron termasuk perkakas yang sudah ada puluhan tahun dan sampai sekarang masih dipakai di mana-mana. Begitu kamu paham satu barisnya yang terlihat agak misterius itu — jadwal lima kolom — kamu bisa mengotomasi hampir semua tugas berulang di sebuah server. Yuk kita bedah pelan-pelan, mulai dari nol.

Cron job itu sebenarnya apa

Cron job adalah sebuah perintah (atau skrip) plus jadwal yang memberi tahu sistem kapan perintah itu harus jalan. Jadwal dan perintahnya tinggal bareng dalam satu baris, dan sistem menyimpan daftar baris-baris itu untukmu.

Di balik layar, ada sebuah program latar kecil — sebuah service — bernama cron daemon (sering ditulis cron atau crond). Dia bagian dari keluarga program latar yang selalu menyala, yang sudah kita bahas di proses dan service. Daemon ini bangun kira-kira tiap menit, melihat setiap baris jadwal yang dia ketahui, lalu bertanya satu hal sederhana: apakah sekarang waktunya menjalankan yang ini? Kalau jawabannya iya, dia jalankan perintahnya. Kalau belum, dia tidur lagi dan mengecek ulang semenit kemudian.

Cuma itu intinya. Cron sendiri nggak mengerjakan tugasnya — dia cuma penjaga jam yang sabar, yang meluncurkan perintah milikmu pada waktu yang kamu tentukan. Daftar baris-baris jadwal tadi disebut crontab, singkatan dari “cron table”.

Membaca jadwal lima kolom

Bagian yang terkenal (dan terkenal bikin bingung) dari cron adalah jadwalnya itu sendiri. Bentuknya lima angka berderet, masing-masing menggambarkan satu satuan waktu, dari yang terkecil ke yang terbesar:

 ┌───────────── menit         (0 - 59)
 │ ┌─────────── jam           (0 - 23)
 │ │ ┌───────── tanggal       (1 - 31)
 │ │ │ ┌─────── bulan         (1 - 12)
 │ │ │ │ ┌───── hari          (0 - 6, Minggu = 0)
 │ │ │ │ │
 *  *  *  *  *   perintah-yang-dijalankan

Bacanya dari kiri ke kanan: menit, jam, tanggal, bulan, hari, baru perintahnya. Tanda bintang (*) di kolom mana pun berarti “semua nilai” — setiap menit, setiap jam, dan seterusnya.

Jadi jadwal paling sederhana dari semuanya adalah lima bintang:

* * * * * /path/ke/script.sh

Itu dibaca sebagai “setiap menit di setiap jam di setiap hari” — job-nya jalan sekali tiap menit, selamanya. Berguna buat tes; jarang yang kamu mau di lingkungan produksi.

Biar lebih jelas, ini contoh jadwal yang benar-benar kepakai, lengkap dengan bacaan polosnya satu per satu:

# Pukul 02:30 tiap malam — waktu klasik buat backup
30 2 * * * /opt/scripts/backup.sh

# Tiap 15 menit, sepanjang hari
*/15 * * * * /opt/scripts/health-check.sh

# Pukul 08:00 tiap Senin — Senin = hari ke-1
0 8 * * 1 /opt/scripts/weekly-report.sh

# Tanggal 1 tiap bulan, tengah malam
0 0 1 * * /opt/scripts/monthly-cleanup.sh

# Tiap jam, pas di awal jam
0 * * * * /opt/scripts/sync.sh

Kunci yang membuka semuanya: ketika sebuah kolom berisi *, dia nggak memasang batasan apa-apa. Job-nya jalan kapan pun kolom-kolom yang bukan bintang semuanya cocok. Pada 30 2 * * *, cuma menit (30) dan jam (2) yang dipatok, jadi dia cocok sekali sehari — pukul 02:30, tiap hari, tiap bulan, nggak peduli hari apa.

Jurus tambahan: step, daftar, dan rentang

Kamu nggak harus menulis satu angka tunggal di tiap slot. Cron mengerti beberapa pola kecil yang bikin jadwal jauh lebih luwes:

• */n — step. */15 di kolom menit berarti “tiap 15 menit” (di menit :00, :15, :30, :45). */2 di kolom jam berarti “tiap 2 jam”.
• a,b,c — daftar. 0 9,12,17 * * * jalan pukul 9 pagi, tengah hari, dan 5 sore — tiga jam yang spesifik.
• a-b — rentang. 0 9-17 * * 1-5 jalan tiap jam dari pukul 9 pagi sampai 5 sore, Senin sampai Jumat — pola “jam kerja, hari kerja”.

Kamu juga bisa menggabungkannya. 0 8-18/2 * * * berarti “tiap 2 jam antara pukul 8 pagi dan 6 sore”. Baca jadwal yang rumit satu kolom demi satu kolom, dan dia selalu kebuka dengan rapi.

Mengedit crontab-mu

Tiap user di sistem punya crontab pribadinya sendiri. Kamu nggak mengedit file-nya langsung pakai text editor — sebagai gantinya kamu pakai perintah crontab, yang membuka daftarmu dengan aman lalu memuat ulang isinya begitu kamu selesai.

# Buka crontab MILIKMU untuk diedit
crontab -e

# Tampilkan (cetak) crontab-mu sekarang tanpa mengedit
crontab -l

# Hapus seluruh crontab-mu — hati-hati, tanpa konfirmasi
crontab -r

Pertama kali kamu menjalankan crontab -e, dia mungkin menanyakan mau pakai text editor yang mana; pilih yang kamu nyaman. Di dalamnya, tiap baris yang bukan kosong dan bukan komentar adalah satu job. Baris yang diawali # adalah komentar dan diabaikan — pas banget buat memberi label apa fungsi tiap job.

Crontab yang rapi dan terdokumentasi dengan baik kelihatannya begini:

# Backup database tiap malam pukul 02:30
30 2 * * * /opt/scripts/backup-db.sh

# Bersihkan file sementara tiap Minggu pukul 04:00
0 4 * * 0 /opt/scripts/clean-temp.sh

# Perpanjang sertifikat dua kali sehari (irama yang disarankan)
0 0,12 * * * /opt/scripts/renew-certs.sh

Ada juga crontab sistem di /etc/crontab dan folder titip-an kecil seperti /etc/cron.d/, plus direktori praktis bernama /etc/cron.daily/, /etc/cron.weekly/, dan seterusnya. Apa pun yang kamu taruh di cron.daily bakal jalan sekali sehari tanpa kamu perlu menulis jadwal sama sekali — sistem yang mengatur waktunya. Itu berguna buat tugas berskala sistem, tapi untuk job pribadimu, crontab -e milikmu sendiri biasanya tempat paling bersih untuk mulai.

Cara cron job sebenarnya berjalan (dan kenapa ini bikin orang kaget)

Ini bagian yang hampir selalu menjegal orang di percobaan pertama. Saat cron menjalankan perintahmu, dia tidak menjalankannya dengan cara yang sama seperti shell interaktifmu. Dia jalan di lingkungan yang serba minim:

 sesi terminal-mu                   lingkungan cron
 ─────────────────                  ───────────────
 PATH lengkap (banyak folder)       PATH mungil (sering cuma /usr/bin:/bin)
 env variable-mu sudah dimuat       hampir nggak ada env variable
 direktori = posisimu sekarang      direktori = folder home-mu
 konfigurasi shell di-load          file konfigurasi TIDAK di-load

Dampak praktisnya: sebuah skrip yang jalan sempurna saat kamu ketik manual bisa gagal diam-diam di bawah cron. Dua biang kerok yang biasanya muncul:

1. Perintah “not found”. Shell-mu tahu di mana python, node, atau pg_dump berada karena PATH-mu kaya. PATH milik cron melompong, jadi dia nggak bisa menemukannya. Solusinya: pakai path absolut lengkap ke tiap program dan file di job-mu — /usr/bin/python3 /opt/scripts/job.py, bukan sekadar python3 job.py. (Kalau kamu butuh penyegaran soal apa itu PATH, lihat environment variable.)
2. Env variable yang hilang. Kalau skrip-mu bergantung pada sebuah variabel yang biasanya diset saat login shell, cron nggak punya itu. Set yang kamu butuhkan secara eksplisit di dalam skrip, atau definisikan di bagian atas crontab.

Kebiasaan yang paling bisa diandalkan: arahkan cron ke sebuah skrip, lalu biarkan skrip itu menyiapkan dunianya sendiri — path absolut, variabelnya sendiri, direktori kerjanya sendiri. Dengan begitu cron cukup meluncurkan satu hal, dan skripnya yang mengurus sisanya.

Menangkap output, atau dia lenyap

Secara bawaan, apa pun yang dicetak job-mu — output normal dan pesan error — bakal dikirim lewat email ke user, itu pun kalau mail memang diatur. Di server biasa, mail nggak diatur, jadi output itu cuma lenyap begitu saja. Saat sebuah job gagal jam 3 pagi dan kamu nggak tahu kenapa, inilah biasanya alasannya: error-nya ada, tapi nggak ada yang menangkapnya.

Solusinya: arahkan sendiri output-nya ke sebuah file log:

# Kirim output normal DAN error ke sebuah file log
30 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1

Ada dua bagian yang bekerja di sini. >> /var/log/backup.log menambahkan output normal ke file log (tanda dobel >> artinya tambahkan, jadi kamu menyimpan riwayat alih-alih menimpanya). Lalu 2>&1 berkata “kirim error ke tempat yang sama dengan output normal”, supaya kegagalan ikut mendarat di log. Dengan satu tambahan itu, job yang tadinya bisu dan misterius berubah jadi job yang benar-benar bisa kamu telusuri — tinggal baca log-nya.

Kapan sebaiknya beralih ke systemd timer

Cron itu hebat untuk job sederhana yang berbasis waktu, dan dia nggak akan ke mana-mana. Tapi di sistem Linux modern ada penjadwal kedua yang layak kamu kenal: systemd timer. Dia bagian dari sistem systemd yang sama yang mengelola service (sudah dibahas di dasar systemd), dan dia menukar sedikit kerepotan setup dengan beberapa kelebihan nyata:

• Logging bawaan. Output sebuah timer mengalir otomatis ke journal sistem, jadi kamu bisa membacanya dengan perkakas journal standar — nggak perlu pengalihan manual.
• Mengejar run yang terlewat. Sebuah timer bisa disuruh menjalankan job yang terlewat gara-gara server mati saat waktunya tiba. Cron tinggal melewatkan run yang terlewat itu sepenuhnya.
• Ketergantungan dan syarat. Sebuah timer bisa menunggu sampai jaringan hidup, atau cuma jalan kalau syarat tertentu terpenuhi — hal-hal yang nggak bisa diungkapkan cron.

Pedoman jujurnya: untuk tugas singkat semacam “jalankan skrip ini tiap malam”, cron biasa lebih cepat diatur dan sudah lebih dari cukup. Untuk sesuatu yang lebih penting — di mana kamu peduli pada run yang terlewat, log yang rapi, atau urutan — systemd timer adalah pilihan yang lebih kokoh. Keduanya punya tempatnya masing-masing; menguasai keduanya berarti kamu memilih alat yang tepat alih-alih memaksa satu alat mengerjakan segalanya.

Kenapa cron layak dipelajari

Otomasi adalah salah satu hal yang memisahkan server yang harus kamu tongkrongin dari server yang mengurus dirinya sendiri. Cron adalah cara tertua, paling sederhana, paling universal untuk mewujudkan itu, dan kamu bakal menemuinya di hampir tiap mesin Linux yang pernah kamu sentuh. Backup, pembersihan, pembuatan laporan, perpanjangan sertifikat, pengecekan kesehatan — pekerjaan kasar yang nggak keren tapi penting dalam menjalankan server, sangat sering adalah sebuah cron job di balik layar.

Jadwal lima kolom itu terlihat misterius selama kira-kira sepuluh menit, lalu setelahnya dia nggak pernah lagi bikin kamu bingung. Belajar membacanya, biasakan memakai path absolut dan mencatat output-mu, dan kamu sudah punya robot kecil yang bisa diandalkan untuk mengerjakan tugas membosankan selagi kamu tidur.

Penutup

Ini rangkuman semuanya dalam satu tempat:

• Cron job adalah sebuah perintah plus jadwal yang memberi tahu sistem kapan menjalankannya otomatis.
• Cron daemon adalah service latar yang bangun tiap menit dan menjalankan job mana pun yang sudah tiba waktunya.
• Jadwalnya punya lima kolom — menit, jam, tanggal, bulan, hari — diikuti perintahnya. * berarti “semua nilai”.
• Step (*/n), daftar (a,b,c), dan rentang (a-b) bikin jadwal jadi luwes: tiap 15 menit, hari kerja jam 9–5, tanggal 1 tiap bulan, dan seterusnya.
• Edit job-mu dengan crontab -e, tampilkan dengan crontab -l. Beri komentar tiap baris supaya tujuannya jelas.
• Cron jalan di lingkungan yang melompong — pakai path absolut, set variabel yang kamu butuhkan, dan arahkan output ke log (>> file 2>&1) supaya kegagalan nggak tak kelihatan.
• Untuk mengejar run yang terlewat, logging otomatis, dan syarat, pertimbangkan systemd timer sebagai gantinya.

Dengan tugas terjadwal sudah kamu kuasai, kamu kini sudah melihat sebagian besar perkakas harian untuk menjalankan server Linux: menjelajahinya, mengamankannya, memindahkan file ke dalamnya, dan sekarang mengajarinya mengerjakan tugas berulangnya sendiri sesuai jam.