systemd Timer vs Cron: Kapan Pakai yang Mana di Ubuntu 24.04

Jawaban singkatnya: pakai systemd timer kalau tugasnya perlu mengejar jadwal yang terlewat, butuh log terpusat di journal, atau perlu ketergantungan antar unit; pakai cron kalau tugasnya sederhana, harus jalan di sistem tanpa systemd, atau sudah terpasang di banyak mesin. Pada VPS toolkuy yang menjalankan Ubuntu 24.04.5 LTS dengan kernel 6.8.0-147, saat artikel ini disusun ada 19 systemd timer aktif atau terjadwal, 4 berkas di /etc/cron.d, dan 46 baris aktif di crontab pengguna. Keduanya hidup berdampingan, dan itu bukan tanda konfigurasi berantakan.

TL;DR

• Cron punya resolusi satu menit; systemd timer bisa memakai resolusi detik lewat OnCalendar.
• Timer bisa mengejar jadwal terlewat dengan Persistent=true, sedangkan cron melewatinya tanpa catatan.
• Log cron biasanya hanya masuk syslog atau email lokal; timer otomatis tercatat di journal per unit.
• Timer bisa mengikat unit lain dengan After= dan Wants=, cron tidak punya konsep ketergantungan.
• Pada host uji ini 19 timer dan 46 baris crontab berjalan bersama, jadi migrasi total tidak wajib.

Apa perbedaan mendasar antara cron dan systemd timer?

Cron adalah daemon yang membaca tabel jadwal lalu menjalankan perintah lewat shell, adapun systemd timer adalah unit yang memicu unit layanan lain dan memakai seluruh mesin ketergantungan systemd. Perbedaan itu yang menentukan segalanya: cron menjalankan perintah, sedangkan timer mengaktifkan unit. Konsekuensinya, timer mendapat logging, sandboxing, pengurutan start, dan manajemen kegagalan yang sudah dimiliki systemd, sementara cron hanya mengeksekusi baris perintah dan menyerahkan sisanya ke skrip.

Pada mesin yang sama, cron menulis keluaran ke syslog atau mengirimkannya sebagai email ke pemilik crontab kalau ada agen mail yang terpasang. Timer menulis ke journal dengan nama unit yang jelas, sehingga perintah journalctl -u nama.service langsung menampilkan riwayat eksekusinya. Untuk pekerjaan yang gagal sesekali dan perlu ditelusuri berhari-hari kemudian, perbedaan ini jauh lebih penting daripada soal sintaks.

Berapa presisi jadwal yang bisa dicapai keduanya?

Cron hanya mengenal menit, sedangkan systemd timer bisa dijadwalkan sampai detik. Ekspresi cron lima medan berhenti di resolusi satu menit, jadi permintaan menjalankan tugas setiap 30 detik tidak bisa dinyatakan tanpa trik tambahan seperti sleep di dalam skrip. Systemd menerima ekspresi kalender seperti OnCalendar=*-*-* *:*:00/15 yang berarti setiap 15 detik, dan nilai itu dijelaskan di dokumentasi resmi systemd.time.

Namun presisi tinggi bukan berarti timer selalu tepat. systemd.timer memiliki opsi AccuracySec yang secara bawaan satu menit, yang berarti timer boleh digeser dalam jendela satu menit untuk menghemat bangunnya CPU. Kalau butuh eksekusi yang lebih ketat, AccuracySec harus diturunkan secara eksplisit, misalnya ke 1s. Sebaliknya, RandomDelaySec berguna untuk menyebar beban ketika banyak mesin menjalankan tugas pada menit yang sama.

Aspek	cron	systemd timer
Resolusi jadwal	1 menit	sampai 1 detik lewat OnCalendar
Jadwal terlewat saat mesin mati	dilewati	bisa dikejar dengan Persistent=true
Log eksekusi	syslog atau email lokal	journal per unit, journalctl -u
Ketergantungan antar unit	tidak ada	After=, Wants=, Requires=
Penundaan acak	tidak ada bawaan	RandomDelaySec
Isolasi proses	bergantung pada skrip	sandboxing unit seperti ProtectHome
Ketersediaan	hampir semua sistem Unix	butuh systemd, umum di distro Linux modern

Kapan sebaiknya memakai systemd timer?

Pakai timer ketika tugas harus tetap dijalankan setelah jadwalnya terlewat, ketika kegagalannya perlu terlihat di journal, atau ketika urutan eksekusinya bergantung pada unit lain. Contoh paling nyata adalah pekerjaan yang bergantung pada jaringan: unit timer bisa diberi After=network-online.target supaya tidak dijalankan sebelum jaringan siap, sesuatu yang di cron harus ditangani manual dengan menambahkan penundaan atau pemeriksaan koneksi di dalam skrip.

Timer juga lebih baik ketika tugasnya perlu dijalankan sebagai pengguna tertentu dengan hak terbatas, karena unit bisa memakai User=, ProtectHome=, dan PrivateTmp= tanpa membungkus semuanya dalam skrip pembungkus. Pada host ini, 19 timer yang terdaftar di systemctl list-timers sebagian besar berasal dari paket sistem seperti fwupd dan snapd, yang memang memilih timer karena alasan yang sama.

Kapan cron masih pilihan yang tepat?

Cron tetap tepat untuk tugas sederhana yang harus portabel, untuk sistem tanpa systemd, dan untuk skrip yang sudah stabil bertahun-tahun. Satu baris crontab jauh lebih mudah diaudit daripada tiga berkas unit, dan pada mesin yang dikelola bersama oleh beberapa orang, crontab pengguna adalah tempat yang paling mudah ditemukan. Di host uji ini terdapat 4 berkas di /etc/cron.d dan 46 baris aktif di crontab pengguna, semuanya berjalan tanpa masalah bersama 19 timer.

Cron juga lebih mudah dipakai untuk tugas sekali pakai yang dibuat dan dihapus cepat, misalnya pengingat sementara atau tugas pembersihan selama masa debugging. Menulis unit systemd untuk pekerjaan yang akan hidup dua jam biasanya bukan investasi yang sepadan.

Bagaimana cara memindahkan satu tugas dari cron ke timer?

Pindahkannya dalam empat langkah: buat unit service bertipe oneshot berisi perintahnya, buat unit timer yang memanggil service tersebut, jalankan systemctl daemon-reload, lalu aktifkan timernya dengan systemctl enable --now. Kunci yang sering terlewat adalah Type=oneshot pada unit service, karena tanpa itu systemd menganggap proses sudah selesai padahal masih berjalan.

# /etc/systemd/system/backup-db.service
[Unit]
Description=Backup database harian
After=network-online.target

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

# /etc/systemd/system/backup-db.timer
[Unit]
Description=Jadwal backup database harian

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true
AccuracySec=1min
Unit=backup-db.service

[Install]
WantedBy=timers.target

Setelah aktif, verifikasi dengan systemctl list-timers --all dan uji jadwalnya memakai systemd-analyze calendar, alat yang menerjemahkan ekspresi kalender menjadi waktu berikutnya yang cocok. Untuk tugas yang selama ini ada di crontab, jangan hapus baris cron sebelum timer terbukti berjalan minimal sekali.

Apa saja jebakan saat memakai timer yang jarang dibicarakan?

Jebakan pertama adalah PATH yang berbeda. Unit systemd tidak mewarisi PATH login shell, jadi perintah yang bekerja di crontab bisa gagal dengan pesan command not found ketika dijalankan sebagai unit. Solusinya memakai path absolut di ExecStart atau menetapkan Environment=PATH secara eksplisit di dalam unit.

Jebakan kedua adalah Persistent=true yang hanya bekerja kalau timernya sempat tercatat, dan itu membutuhkan berkas stamp di direktori status systemd. Kalau direktori itu dibersihkan atau unit dibuat ulang dengan nama berbeda, pengejaran jadwal terlewat tidak akan terjadi. Jebakan ketiga adalah OnCalendar yang lebih rapat daripada durasi eksekusi tugas, sehingga eksekusi berikutnya menumpuk; untuk kasus seperti ini, tambahkan pengaman agar proses tidak berjalan ganda.

Bagaimana cara menguji timer tanpa menunggu jadwal aslinya?

Jalankan unit service-nya langsung dengan systemctl start nama.service, lalu periksa hasilnya di journal. Cara itu menguji perintah dan seluruh dependensi unit tanpa memaksa jadwalnya berjalan, dan kegagalan akan terlihat sebagai status failed pada unit yang bisa dibaca dengan systemctl status. Setelah perintahnya terbukti benar, baru timer diaktifkan sehingga jadwalnya yang diuji, bukan lagi isi perintahnya.

Untuk memastikan ekspresi kalender menghasilkan waktu yang diharapkan, gunakan systemd-analyze calendar dengan ekspresi yang sama seperti di unit. Alat itu mencetak waktu berikutnya yang cocok beserta normalisasi ekspresinya, sehingga kesalahan seperti menulis hari dan bulan secara terbalik bisa langsung terlihat. Kesalahan semacam ini tidak menimbulkan pesan error saat unit dimuat, dan hanya ketahuan ketika tugasnya tidak pernah berjalan.

Pada mesin yang menjalankan banyak tugas, urutan pengujian yang aman adalah: uji perintah secara manual di shell, uji unit service dengan start, uji timer dengan OnCalendar yang sebentar lagi, lalu ganti ke jadwal sebenarnya. Empat langkah ini mencegah kejutan yang paling sering terjadi, yaitu timer aktif tetapi perintahnya gagal karena PATH atau izin berkas yang berbeda dari shell interaktif.

Apakah timer bisa dijalankan sebagai pengguna biasa?

Bisa, lewat systemctl --user yang mengelola instance systemd per pengguna. Timer pengguna tidak butuh akses root dan cocok untuk tugas pribadi seperti menyinkronkan berkas atau membersihkan direktori kerja. Syaratnya, layanan systemd pengguna harus aktif dan biasanya perlu diaktifkan agar tetap berjalan setelah sesi berakhir, atau tugas tersebut dipindahkan ke timer sistem kalau harus berjalan tanpa login.

Pada host uji ini pembagiannya terlihat jelas: 19 timer yang terdaftar di systemctl list-timers sebagian besar berasal dari unit sistem, sementara 46 baris aktif di crontab pengguna menangani tugas yang memang milik satu akun. Membiarkan keduanya berjalan sesuai wilayahnya lebih mudah dirawat daripada memaksa semuanya masuk ke satu mekanisme.

Satu hal yang sering terlewat saat mengelola jadwal: tugas yang gagal diam-diam. Cron mengirim keluaran ke email hanya kalau ada agen mail terpasang dan variabel MAILTO diisi, sehingga pada server minimal kegagalan bisa berlangsung berbulan-bulan tanpa terlihat. Timer tidak lebih baik secara otomatis, tetapi status failed pada unit mudah diperiksa dengan satu perintah, dan itu membuat pemeriksaan berkala jauh lebih murah. Apa pun pilihannya, tugas terjadwal sebaiknya menuliskan hasilnya ke berkas log sendiri dengan penanda waktu, supaya riwayatnya tidak bergantung pada syslog yang bisa berotasi. Untuk tugas yang durasinya bisa melebihi interval, pengaman seperti flock pada cron atau ConditionPathExists pada unit mencegah dua eksekusi berjalan bersamaan dan saling menimpa.

FAQ

Apakah systemd timer bisa menggantikan cron sepenuhnya?

Secara teknis bisa di sebagian besar distro Linux modern, tetapi tidak wajib. Pada host uji ini 19 timer dan 46 baris crontab berjalan bersama tanpa konflik; memilih alat sesuai kebutuhan tugas lebih masuk akal daripada migrasi total yang berisiko.

Bagaimana menjalankan timer setiap 30 detik?

Gunakan ekspresi kalender dengan detik, misalnya OnCalendar=*-*-* *:*:00/30, lalu turunkan AccuracySec menjadi 1s. Ingat bahwa jadwal rapat hanya masuk akal kalau durasi tugasnya jauh lebih pendek daripada intervalnya.

Di mana melihat log hasil eksekusi timer?

Jalankan journalctl -u nama.service, dan tambahkan --since untuk membatasi rentang waktu. Untuk cron, keluaran biasanya masuk syslog atau dikirim sebagai email lokal, tergantung konfigurasi sistem dan ada tidaknya agen mail.

Apakah timer tetap jalan kalau server mati saat jadwalnya?

Hanya kalau Persistent=true dipasang pada unit timer. Tanpa opsi itu, jadwal yang terlewat dilewati begitu saja, sama seperti cron. Opsi tersebut dijelaskan di manual systemd.timer.

Di mana dokumentasi resmi sintaks jadwalnya?

Ekspresi OnCalendar dijelaskan di manual systemd.time, sedangkan format lima medan cron dijelaskan di manual crontab. Keduanya sumber primer yang bisa dipakai untuk memverifikasi setiap contoh jadwal.