Penjadwal Tugas di Linux — Kapan Pakai Cron, Kapan Pakai systemd Timer?

Beberapa waktu lalu, aku lagi membangun backup otomatis untuk beberapa layanan di home server. Semua berjalan lancar pakai cron, sampai suatu hari aku butuh satu tugas yang jalan sekali setelah reboot, lalu diulang tiap jam, tapi hanya kalau hasil sebelumnya gagal. Di sinilah cron mulai terasa seperti sepeda ontel yang dipaksa bonceng lemari es: masih bisa jalan, tapi bikin keringat sendiri. Akhirnya, aku menyelami dunia systemd timer dan sadar bahwa Linux punya dua penjaga waktu yang cukup berbeda karakternya.

Cron: Penjaga Waktu Klasik yang Sudah Legendaris

cron adalah penjadwal tugas tertua yang paling dikenal di dunia Linux. Ia seperti jam dinding analog di rumah nenek: sederhana, tidak banyak fitur, tapi selalu bisa diandalkan dan hampir semua orang paham cara membacanya.

Cara kerjanya mudah ditebak. Kamu menulis jadwal di /etc/crontab, /etc/cron.d/, atau crontab -e, lalu daemon crond akan memeriksa setiap menit apakah ada tugas yang harus dijalankan. Formatnya sudah menjadi bahasa universal di kalangan sysadmin:

# menit jam tanggal bulan hari command
0 3 * * * /usr/local/bin/backup.sh

Baris di atas berarti: “jalankan backup.sh setiap pukul 03:00”. Lima kolom pertama adalah waktu, sisanya adalah perintah. Sederhana, kan? Itulah kekuatan utama cron: zero ceremony. Tidak perlu membuat unit file, tidak perlu memikirkan dependency, dan hampir semua distro punya bawaannya.

Tapi seiring waktu, aku menemukan beberapa batasan yang mulai mengganggu:

• Tidak ada logging bawaan yang rapi. Kalau tugas gagal, kamu harus mengalihkan output sendiri ke file log atau mengandalkan mail.
• Tidak bisa mengeksekusi tugas berdasarkan event. Cron hanya mengenal waktu, bukan kondisi seperti “setelah service X aktif” atau “setelah reboot”.
• Manajemen banyak job jadi berantakan. Semua tertumpuk di satu file crontab, sulit ditrace kalau sudah puluhan baris.
• Tidak ada mekanisme retry bawaan. Kalau perintah gagal karena jaringan sementara putus, cron tidak akan mencoba lagi sampai jadwal berikutnya.

systemd Timer: Penjaga Waktu Modern Berbasis Event

Masuklah systemd timer. Ia bukan pengganti cron secara mutlak, melainkan alternatif yang lebih kaya fitur. Bayangkan cron adalah alarm ponsel, sedangkan systemd timer adalah asisten pintar yang tahu kapan kamu tidur, kapan kamu bangun, dan bisa menyesuaikan tugas berdasarkan keadaan di sekitarmu.

Timer di systemd bekerja berpasangan dengan service unit. Kamu membuat dua file: satu untuk apa yang dikerjakan, satu lagi untuk kapan dikerjakan. Contohnya seperti ini:

# /etc/systemd/system/backup.service
[Unit]
Description=Backup harian server

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Timer backup harian

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Kemudian aktifkan dengan:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Yang menarik dari systemd timer adalah fleksibilitasnya. Selain waktu, kamu bisa memicu tugas berdasarkan:

• OnBootSec — jalan sekian detik setelah boot.
• OnUnitActiveSec — jalan sekian waktu setelah unit terakhir aktif.
• OnFailure — jalan kalau service lain gagal.
• OnCalendar — mirip cron, tapi sintaksnya lebih ekspresif.

Selain itu, systemd langsung menyediakan journalctl untuk logging. Tidak perlu lagi memikirkan file log manual, cukup ketik:

sudo journalctl -u backup.service -e

Perbandingan Langsung: Cron vs systemd Timer

Agar lebih jelas, aku buat tabel perbandingan berdasarkan pengalamanku menggunakan keduanya di home server:

Aspek	Cron	systemd Timer
Kemudahan setup	Sangat mudah, satu baris	Butuh dua file unit
Logging	Manual, ke file atau mail	Otomatis via journalctl
Dependency	Tidak ada	Bisa depend ke service/unit lain
Retry otomatis	Tidak ada	Bisa pakai Restart=on-failure
Event-based	Hanya waktu	Waktu + event
Portabilitas	Hampir semua Unix-like	Distro dengan systemd

Kapan Sebaiknya Tetap Pakai Cron?

Meski terdengar seperti cron sudah ketinggalan zaman, ada banyak situasi di mana cron masih menjadi pilihan terbaik:

• Skrip cepat dan sementara. Kalau cuma butuh “jalankan ini tiap jam selama tiga hari”, lebih cepat pakai crontab -e daripada membuat dua file unit.
• Server tanpa systemd. Beberapa distro minimal seperti Alpine atau container tertentu tidak pakai systemd.
• Kerja sama dengan pengguna yang berbeda. Cron milik per user cukup intuitif untuk server yang dikelola banyak orang.
• Tugas yang tidak butuh logging rumit. Backup sederhana ke USB eksternal misalnya, cukup dengan output ke file log sendiri.

Kapan Beralih ke systemd Timer?

Di sisi lain, systemd timer mulai mengambil alih saat tugasmu bertambah kompleks:

• Kamu butuh retry otomatis. Misalnya sinkronisasi ke cloud storage yang kadang gagal karena timeout.
• Tugas harus berjalan setelah service tertentu aktif. Seperti membersihkan cache setelah Nginx reload.
• Kamu ingin konsistensi logging. Semua log di satu tempat via journalctl.
• Job terkait erat dengan service yang sudah dikelola systemd. Contoh: backup database yang sebelumnya harus menunggu MariaDB aktif.

Contoh Praktis: Backup Otomatis yang Bisa Retry

Bayangkan kamu punya skrip backup yang mengirim data ke remote server via rsync. Kadang jaringan sedikit goyah, dan backup gagal. Dengan cron, kamu harus menunggu jadwal berikutnya. Dengan systemd timer, kamu bisa menambahkan retry:

# /etc/systemd/system/daily-backup.service
[Unit]
Description=Daily backup with retry

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Restart=on-failure
RestartSec=5min

# /etc/systemd/system/daily-backup.timer
[Unit]
Description=Run daily backup at 2 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Dengan konfigurasi ini, kalau backup.sh keluar dengan kode error, systemd akan mencoba lagi setiap 5 menit. Jauh lebih elegan daripada membuat skrip bash pembungkus.

Jadi, Mana yang Lebih Baik?

Jawaban singkatnya: tidak ada yang lebih baik secara mutlak. Cron dan systemd timer adalah dua alat untuk dua kebutuhan yang berbeda, meski fungsi utamanya sama-sama menjalankan tugas terjadwal.

Kalau aku boleh menyimpulkan dari pengalaman pribadi: pakai cron untuk tugas cepat dan sementara, pakai systemd timer untuk tugas yang butuh reliabilitas dan integrasi dengan service lain. Di home serverku sendiri, masih ada beberapa baris crontab yang sudah bertahun-tahun tidak perlu diubah, sementara tugas-tugas baru cenderung aku arahkan ke systemd timer karena lebih mudah dipantau.

Yang terpenting adalah memahami kapan sebuah alat mulai memberatkan. Kalau kamu merasa setup cron mulai dipenuhi skrip pembungkus, log manual, dan hack retry, itu tandanya sudah waktunya menjajal systemd timer.

Kamu lebih nyaman pakai cron atau sudah mulai migrasi ke systemd timer? Tulis di kolom komentar kalau ada pengalaman menarik soal penjadwal tugas di Linux. Jika artikel ini berguna, jangan ragu untuk membagikannya.