Cron vs timer systemd: mana yang sebaiknya Anda pakai?

Di distro modern, pakai timer systemd untuk semua job yang Anda miliki sendiri, dan sisakan cron untuk job satu baris milik pengguna serta server yang bukan Anda rakit sendiri. Timer mencatat setiap eksekusi ke journal, bisa mengejar jadwal yang terlewat saat mesin mati, dan bergantung pada unit file yang sama seperti segala hal lain di sistem. Cron unggul dalam keringkasan — satu baris crontab -e mengalahkan dua unit file — dan masih menjadi satu-satunya penjadwal yang dijamin ada di container minimal serta mesin Unix eksotis. Cacatnya: cron gagal dalam diam. Jika job Anda error pukul 3 pagi, cron mengirim surat ke mailbox lokal yang tidak dibaca siapa pun, sementara timer memberi Anda journalctl -u mytimer.service dengan output lengkap. Di bawah: perbedaan yang sesungguhnya, cara menguji masing-masing, kenapa timer bisa tidak berjalan, dan tabel keputusan.

Apa perbedaan cron dan timer systemd?

Cron adalah daemon yang membaca tabel baris — lima field waktu dan satu perintah — dan menjalankan tiap perintah saat jam dinding cocok. Itu seluruh modelnya. Ia tidak punya konsep job sebagai objek: tidak ada unit, tidak ada status, tidak ada dependensi, tidak ada catatan lognya sendiri.

Timer systemd adalah unit file (foo.timer) yang menembakkan unit file lain (foo.service) saat jadwalnya cocok. Job-nya adalah objek kelas satu dengan start, status, logs, dan pelacakan kegagalan seperti layanan lain. Penjadwalannya berbasis kalender (ala cron) atau monotonik (OnBootSec=15min, yang tidak bisa dikecoh oleh perubahan jam dinding).

Konsekuensi praktisnya:

• Logging: timer mencatat stdout/stderr ke journal per unit; cron paling banter mengirim surat ke pengguna lokal.
• Eksekusi yang terlewat: timer dengan Persistent=true berjalan sekali saat boot jika jadwalnya terlewat; cron begitu saja melewatkan.
• Dependensi: timer bisa menunggu network-online.target atau mount point; cron memaksa Anda merangkai sendiri logika retry di skrip.
• Sintaks: cron satu baris; timer dua file. Itulah seluruh biaya berpindah.

Sintaks jadwal mana yang lebih mudah — crontab atau OnCalendar?

Lima field cron adalah incumben yang ringkas: */15 * * * * berarti setiap 15 menit, dan kebanyakan admin bisa membacanya sambil tidur. OnCalendar= milik systemd lebih bertele-tele tetapi jelas lebih ekspresif, dan systemd-analyze calendar akan memberi tahu eksekusi berikutnya sebelum Anda berkomitmen — cron tidak punya dry-run yang setara.

# Cron: setiap hari pukul 03:30
30 3 * * * /usr/local/bin/backup.sh

# systemd: jadwal yang sama, bisa diverifikasi sebelum disimpan
systemd-analyze calendar "*-*-* 03:30:00"
# -> Next elapse: Fri 2026-09-11 03:30:00 ...

OnCalendar menangani hal-hal yang cron sungguh tak bisa ekspresikan dengan bersih: Mon..Fri *-*-* 09..17:00:00 (hari kerja, jam kerja), atau *:0/15 dengan RandomizedDelaySec=10m agar seribu mesin tidak menghantam satu server di detik yang sama.

Bagaimana menguji timer systemd tanpa menunggu?

Tiga perintah menjawab semuanya. Daftarkan apa yang terjadwal dan kapan berikutnya menyala, jalankan job dengan tangan persis seperti yang akan dilakukan timer, lalu baca lognya:

systemctl list-timers --all                 # semua timer, eksekusi berikutnya + terakhir
sudo systemctl start backup.service         # jalankan job sekarang, unit yang sama dengan milik timer
journalctl -u backup.service -f             # pantau outputnya secara live

Perhatikan pemisahannya: systemctl start backup.timer memasang jadwal; service-lah job-nya. Jika list-timers menampilkan timer Anda, systemctl status backup.service hijau, dan journal menampilkan output Anda, seluruh rantai berfungsi.

Bagaimana menjalankan cron job secara manual?

Cron job berjalan dengan lingkungan yang dipangkas, dan itulah sebabnya “jalan di shell saya, gagal di cron” adalah satu genre bug. Untuk mereproduksi cron secara setia, jalankan perintahnya melalui sh dengan lingkungan yang sama seperti yang akan dipakai cron:

crontab -l                                  # pastikan baris yang persis sama
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # apakah cron benar-benar menembakkannya? (Debian/Ubuntu)
journalctl -u cron -n 20                    # sama, di distro systemd

Baris env -i itulah uji manual yang jujur: lingkungan telanjang dengan PATH default cron. Sebagian besar kegagalan cron yang senyap adalah PATH kosong atau % yang tidak di-escape dalam perintah (cron memperlakukan % sebagai baris baru), dan keduanya langsung kelihatan lewat cara ini.

Kenapa timer systemd saya tidak berjalan?

Empat penyebab menutup hampir semua kasus, dalam urutan pemeriksaan:

1. Nama service dan timer tidak cocok. foo.timer menembakkan foo.service — OnFailure yang salah ketik atau unit yang di-rename membuat timer “berjalan” ke kehampaan. systemctl cat foo.timer menunjukkan dengan persis apa yang ditargetkannya.
2. Timer diedit tetapi tidak di-reload. Setelah mengubah unit file: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. Tanpa ini, jadwal baru Anda belum aktif.
3. Persistent=true tanpa semantik OnCalendar yang Anda bayangkan — atau Anda memeriksa systemctl status foo.timer (selalu tampak active meski idle), bukan list-timers.
4. Service yang ditembakkannya gagal seketika, sehingga tampak seperti timer yang mati. journalctl -u foo.service --since -1h akan menunjukkan crash yang disembunyikan list-timers.

Dan saat Anda memang melihat log, memo journalctl membahas filter (-u, --since, -f) yang mempercepat semua ini.

Cron vs timer systemd: tabel keputusan

	cron	timer systemd
Setup	satu baris crontab	dua unit file
Logging	surat lokal, biasanya tak dibaca	journal, per unit
Eksekusi terlewat (mesin mati)	dilewati	berjalan sekali dengan Persistent=true
Dependensi / urutan	tidak ada — DIY di skrip	dependensi unit penuh
Jeda acak	DIY dengan $RANDOM	RandomizedDelaySec=
Uji/dry-run jadwal	tidak ada	systemd-analyze calendar
Ada di mana-mana	ya — container, BSD, embedded	butuh systemd (PID 1)
Job pengguna tanpa root	crontab -e	unit systemd --user

Aturan praktis: menugaskan job di mesin systemd milik Anda sendiri → timer. Pengingat pribadi sekali jalan atau mesin yang bukan rakitan Anda → cron. Apa pun dengan dependensi, retry, atau kebutuhan tahu apakah ia benar-benar berjalan → timer, selalu. Pola yang umum adalah timer yang menjalankan job pemeliharaan — katakanlah backup rsync setiap malam — tempat Persistent=true menjamin backup tetap terjadi meski mesin sedang tidur pada menit terjadwal, sesuatu yang cron sederhananya tidak bisa tawarkan.