Cron dan systemd Timer: Menjadwalkan Tugas di Linux

Otomasi adalah jantung dari administrasi sistem Linux. Selama puluhan tahun, cron telah menjadi standar industri untuk menjalankan tugas terjadwal, seperti backup harian atau pembersihan log. Namun, seiring dengan dominasi systemd, muncul alternatif yang lebih modern dan kuat: systemd Timer.

Bagi banyak sysadmin, pertanyaan utamanya adalah: “Apakah saya masih perlu menggunakan cron, atau haruskah saya bermigrasi sepenuhnya ke systemd timer?”

Artikel ini akan membedah perbedaan keduanya, kapan harus menggunakan salah satu, dan bagaimana menangani masalah umum seperti tugas yang tumpang tindih (overlapping jobs).

Ringkasan

• Cron: Sederhana, berbasis file teks (crontab), tetapi memiliki keterbatasan dalam logging dan dependensi.
• systemd Timer: Lebih kompleks (membutuhkan dua file: .service dan .timer), tetapi menawarkan fitur canggih seperti monotonic timers, randomized delay, dan integrasi log journalctl.
• OnCalendar: Sintaks penjadwalan systemd yang lebih fleksibel daripada ekspresi cron tradisional.
• Persistent=true: Fitur systemd yang memastikan tugas tetap berjalan jika mesin dalam keadaan mati saat jadwal seharusnya dieksekusi.
• flock: Tool esensial untuk mencegah dua instance dari tugas yang sama berjalan bersamaan.

Mengapa Cron Terasa Terbatas?

Cron sangat efisien untuk tugas sederhana. Namun, saat kebutuhan otomasi meningkat, cron mulai menunjukkan kelemahannya:

1. Logging yang Terfragmentasi: Cron biasanya mengirim output ke email lokal atau file log terpisah. Mencari tahu mengapa tugas gagal seringkali mengharuskan Anda mencari di /var/log/syslog.
2. Ketiadaan Dependensi: Cron tidak tahu jika network sudah aktif atau disk sudah terpasang sebelum menjalankan skrip.
3. Presisi Rendah: Cron hanya memiliki resolusi per menit. Jika Anda butuh tugas berjalan setiap 30 detik, cron tidak bisa melakukannya secara native.
4. Missed Events: Jika server mati saat jam 02:00 (jadwal backup), cron tidak akan menjalankan tugas tersebut saat server menyala kembali pada jam 03:00.

Kekuatan systemd Timer

systemd Timer memisahkan apa yang dijalankan (Service) dan kapan itu dijalankan (Timer).

1. Fleksibilitas OnCalendar

Sintaks OnCalendar jauh lebih manusiawi daripada format bintang-bintang di cron.

2. Monotonic Timers (Relative Timing)

Berbeda dengan cron yang hanya mengenal waktu absolut (jam dinding), systemd timer bisa dijadwalkan secara relatif:

• OnBootSec=15min: Jalan 15 menit setelah booting.
• OnUnitActiveSec=1h: Jalan 1 jam setelah terakhir kali servis aktif.

3. Fitur Persistent=true

Salah satu fitur terbaik systemd timer adalah Persistent=true. Jika server mati saat jadwal eksekusi, systemd akan menandai tugas tersebut sebagai “terlewat” dan segera menjalankannya segera setelah sistem booting kembali.

Implementasi Lengkap: Membuat systemd Timer

Agar Anda bisa langsung mempraktikkannya, berikut adalah langkah-langkah membuat timer untuk tugas backup.

Langkah 1: Buat Service File

Buat file di /etc/systemd/system/my-backup.service. File ini mendefinisikan apa yang akan dijalankan.

[Unit]
Description=Daily Backup Service
After=network-online.target

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

Langkah 2: Buat Timer File

Buat file di /etc/systemd/system/my-backup.timer. File ini mendefinisikan kapan service tersebut dipicu.

[Unit]
Description=Run My Backup Daily

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=my-backup.service

[Install]
WantedBy=timers.target

Langkah 3: Aktivasi

Jalankan perintah berikut untuk memuat konfigurasi dan mengaktifkan timer:

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

Untuk melihat semua timer yang aktif dan kapan jadwal eksekusi berikutnya, gunakan:

systemctl list-timers

Analisis: Mengapa pola ini lebih baik?

Dengan pola ini, jika skrip backup.sh crash, systemd akan mencatat exit code-nya. Anda bisa melihat log detail menggunakan journalctl -u my-backup.service, sesuatu yang sangat sulit dilakukan di cron tanpa pengalihan output manual ke file. Selain itu, dengan After=network-online.target, Anda menjamin skrip tidak akan berjalan sebelum koneksi jaringan tersedia, mencegah error “connection refused” pada backup cloud.

Strategi Penjadwalan yang Efektif: Tips Tambahan

Selain memilih antara cron dan systemd, ada beberapa praktik terbaik yang harus diterapkan untuk menjaga stabilitas sistem:

1. Gunakan Absolute Path

Salah satu penyebab utama kegagalan tugas terjadwal adalah perbedaan PATH environment. Cron memiliki PATH yang sangat minimal. Selalu gunakan path absolut untuk binary dan file:

• Salah: backup.sh
• Benar: /usr/local/bin/backup.sh

2. Kelola Output dengan Cermat

Jangan biarkan tugas terjadwal menghasilkan output yang menumpuk di /var/spool/mail (default cron). Arahkan output ke log file dengan timestamp:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

3. Monitoring Keberhasilan Tugas

Menjalankan tugas adalah satu hal, mengetahui bahwa tugas itu berhasil adalah hal lain. Gunakan tool monitoring seperti “Healthchecks.io” atau “Dead Man’s Snitch”. Konsepnya sederhana: skrip Anda mengirim HTTP request ke layanan eksternal di akhir eksekusi. Jika layanan tersebut tidak menerima request dalam waktu yang ditentukan, Anda akan menerima notifikasi bahwa tugas gagal berjalan.

Menangani Overlapping Jobs dengan flock

Masalah umum dalam penjadwalan adalah ketika tugas yang seharusnya selesai dalam 5 menit ternyata memakan waktu 10 menit karena beban sistem. Jika tugas baru dimulai saat tugas lama masih berjalan, hal ini bisa menyebabkan resource exhaustion atau korupsi data.

Solusi terbaik adalah menggunakan flock (file lock).

Contoh Skrip Backup yang Aman:

#!/bin/bash
LOCKFILE="/tmp/backup.lock"

# Buka file lock pada descriptor 200
exec 200>$LOCKFILE

# Coba kunci file. Jika gagal (-n), langsung keluar.
if ! flock -n 200; then
    echo "Tugas backup masih berjalan. Melewatkan eksekusi kali ini."
    exit 1
fi

# Jalankan logika backup di sini
echo "Melakukan backup..."
sleep 60

Dengan menambahkan flock di awal skrip, Anda menjamin bahwa hanya ada satu instance tugas yang berjalan, terlepas dari apakah itu dijalankan oleh cron atau systemd timer.

Perbandingan Final: Kapan Menggunakan Apa?

Kesimpulan

Cron tetap relevan untuk tugas-tugas kecil dan cepat. Namun, untuk infrastruktur produksi yang membutuhkan reliabilitas tinggi dan observabilitas, systemd timer adalah pilihan yang jauh lebih unggul. Integrasi dengan journalctl memudahkan debugging, dan kemampuan menangani event yang terlewat memastikan tidak ada backup yang hilang.

Untuk referensi lebih lanjut, Anda dapat mempelajari:

• Man Page systemd.timer(5) untuk detail konfigurasi timer.
• Dokumentasi Crontab(1) untuk referensi sintaks cron tradisional.
• Panduan systemd.time(7) untuk memahami format waktu OnCalendar secara mendalam.