systemd Timers

Cron menuntaskan penjadwalan klasik dengan satu file teks, tetapi ia punya batas: log tugas tersebar ke file yang harus diatur sendiri, jadwal yang terlewat saat mesin mati tidak pernah dikejar, dan resolusinya berhenti di menit. Distribusi Linux modern menjawabnya dengan systemd timer — penjadwalan bawaan systemd, init yang menjadi leluhur semua proses. Sebuah timer adalah pasangan dua file unit: satu berisi jadwal, satu berisi pekerjaan, lengkap dengan log terstruktur di journald. Chapter ini menutup Section Process dan Jobs dengan membedah pasangan unit tersebut, sintaks OnCalendar, dan cara memantaunya — lalu membandingkannya dengan cron.

Pasangan Unit: .timer Menyalakan .service #

Nama unit timer dan service harus sama: backup.timer menjalankan backup.service. File .service berisi pekerjaannya — biasanya bertipe oneshot, artinya berjalan sekali lalu selesai — sedangkan file .timer berisi jadwal kapan service itu dinyalakan. Mari kita tulis pasangan pertama kita:

cat > backup.service << 'EOF'
[Unit]
Description=Backup harian berkas kerja

[Service]
Type=oneshot
ExecStart=/bin/tar -czf /var/backups/kerja.tar.gz /home/budi/kerja
EOF

cat > backup.timer << 'EOF'
[Unit]
Description=Jalankan backup tiap hari pukul 03:00

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemd-analyze verify backup.service backup.timer && echo "kedua unit lolos pemeriksaan sintaks"

Output yang Dihasilkan:

kedua unit lolos pemeriksaan sintaks

Mari kita telaah blok di atas:

1. Baris 1-8 (cat > backup.service): unit service dengan Type=oneshot karena backup adalah pekerjaan sekali jalan, dan ExecStart memuat perintah intinya — di sistem nyata gantilah dengan path skrip backup Anda sendiri.
2. Baris 10-20 (cat > backup.timer): unit timer dengan dua directive kunci di bagian [Timer] — OnCalendar=daily menjadwalkan service setiap hari tepat pukul 00:00, dan Persistent=true memerintahkan systemd untuk mengejar jadwal yang terlewat saat mesin sedang mati.
3. Baris 22 (systemd-analyze verify ... && echo ...): memeriksa kedua file unit tanpa menjalankannya — layaknya bash -n untuk shell script. Verifikasi lolos tanpa keluhan, ditandai pesan sukses dari cabang &&.

Pada sistem nyata, kedua file itu disalin ke /etc/systemd/system/ (dengan sudo), lalu diaktifkan dengan systemctl daemon-reload agar systemd membaca ulang unit, diikuti systemctl enable --now backup.timer untuk mengaktifkan sekaligus menyalakannya.

Menulis Jadwal dengan OnCalendar #

Nilai OnCalendar berformat hari-pekan tahun-bulan-tanggal jam:menit:detik — misalnya Mon *-*-* 03:00:00 berarti setiap Senin pukul 03:00. Bagian yang tidak ditulis menjadi *: *-*-* 03:00 berarti setiap hari pukul 03:00. Nama hari boleh singkatan tiga huruf (Mon, Tue) atau daftar koma (Mon,Fri). Alih-alih menghafal, kita bisa menguji setiap ekspresi secara offline dengan systemd-analyze calendar — berikut empat ekspresi populer beserta bentuk bakunya:

for ekspresi in daily weekly 'Mon *-*-* 03:00' '*-*-* 03:00:30'; do
  printf '%-18s => %s\n' "$ekspresi" "$(systemd-analyze calendar "$ekspresi" | sed -n 's/^ *Normalized form: //p')"
done

Output yang Dihasilkan:

daily              => *-*-* 00:00:00
weekly             => Mon *-*-* 00:00:00
Mon *-*-* 03:00    => Mon *-*-* 03:00:00
*-*-* 03:00:30     => *-*-* 03:00:30

Mari kita telaah blok di atas:

1. Baris 1 (for ekspresi in ...): mengulang empat ekspresi jadwal, dua di antaranya dikutip karena mengandung spasi.
2. Baris 2 (printf ... systemd-analyze calendar ...): untuk tiap ekspresi, systemd-analyze calendar mencetak analisis lengkap berikut kapan jadwal berikutnya jatuh tempo; sed -n 's/^ *Normalized form: //p' hanya menyaring baris Normalized form — bentuk baku setelah systemd melengkapi bagian yang kosong — dan membuang sisanya, karena tanggal jatuh tempo berbeda setiap hari.
3. Baris 3 (done): penutup loop.

Hasilnya memberi dua wawasan: alias daily ternyata hanyalah *-*-* 00:00:00, dan weekly menunjuk Senin (Mon) sebagai hari acuan — keduanya bisa ditulis eksplisit bila ingin menghindari alias. Ekspresi keempat menunjukkan detik boleh ditulis untuk ketepatan di bawah menit — sesuatu yang tidak bisa diberikan cron.

Satu keluarga jadwal lain tidak memakai kalender, melainkan jam monoton relatif: OnBootSec menghitung berapa lama setelah sistem menyala, dan OnUnitActiveSec menghitung jarak sejak eksekusi terakhir. Timer berikut memakai keduanya:

cat > sinkronisasi.timer << 'EOF'
[Unit]
Description=Cek sinkronisasi berkala

[Timer]
OnBootSec=2min
OnUnitActiveSec=15min

[Install]
WantedBy=timers.target
EOF
grep '^On' sinkronisasi.timer

Output yang Dihasilkan:

OnBootSec=2min
OnUnitActiveSec=15min

Timer ini pertama kali menyala dua menit setelah boot, lalu berulang setiap 15 menit sejak eksekusi terakhirnya — cocok untuk tugas kecil seperti sinkronisasi jam atau pengecekan update. Kombinasi kedua keluarga jadwal dalam satu file juga sah, dan Persistent=true tetap berguna untuk jadwal OnCalendar yang terlewat saat mesin mati. Sintaks lengkapnya — termasuk RandomizedDelaySec untuk menyebarkan beban — ada di systemd.timer(5) .

Memantau Timer dan Lognya #

Keunggulan praktis terbesar systemd timer terasa setelah tugas berjalan: seluruh riwayatnya terekam di journald tanpa perlu konfigurasi. Dua perintah adalah pintu masuknya. Perintah systemctl list-timers merangkum semua timer yang terpasang beserta jadwal berikutnya:

NEXT                         LEFT      LAST                         PASSED    UNIT                ACTIVATES
Tue 2026-01-20 03:00:00 WIB 14h left  Mon 2026-01-19 03:00:01 WIB 9h ago    backup.timer        backup.service
Tue 2026-01-20 00:00:00 WIB 11h left  Mon 2026-01-19 00:00:03 WIB 14h ago   logrotate.timer     logrotate.service
Tue 2026-01-20 10:15:00 WIB 3min left Mon 2026-01-19 10:15:02 WIB 23h ago   sinkronisasi.timer  sinkronisasi.service

3 timers listed.

Kolom NEXT dan LEFT menampilkan jadwal berikutnya dan jaraknya, LAST dan PASSED eksekusi terakhir — begitu terlihat timer mana yang diam padahal seharusnya berjalan. Log per eksekusi dibaca dengan journalctl -u diikuti nama unit service; berikut contoh tampilan hasil eksekusi backup kita:

Jan 19 03:00:01 server-kantor systemd[1]: Starting backup.service - Backup harian berkas kerja...
Jan 19 03:00:03 server-kantor tar[812]: tar: removing leading '/' from member names
Jan 19 03:00:03 server-kantor systemd[1]: backup.service: Deactivated successfully.
Jan 19 03:00:03 server-kantor systemd[1]: Finished backup.service - Backup harian berkas kerja.

Empat baris itu memuat siklus utuh sebuah timer: systemd memulai service, tar bekerja dua detik dan mencatat keluarannya sendiri, lalu service selesai dengan sukses — semuanya ber-timestamp dan bisa disaring dengan journalctl -u backup.service --since today, atau dipantau langsung dengan -f (follow). Tidak ada file log yang perlu diputar manual; journald mengurus retensinya.

systemd timer atau cron? #

Keduanya sama-sama matang, jadi pilihannya adalah soal kecocokan. Perbandingan menyeluruhnya:

Aturan praktisnya: untuk tugas sederhana milik user — reminder, script pribadi — cron tetap ringan dan portabel; teknik pengamanannya seperti flock dan environment minimal kita bahas tuntas di Chapter Scheduling Scripts . Untuk tugas sistem yang butuh log terstruktur, pengejaran jadwal, dan jangkar ke lifecycle service lain, systemd timer adalah pilihan modernnya — dan kumpulan contoh ekspresi kalendernya dirangkum rapi di wiki Arch tentang systemd timers .

Dengan cron dan systemd timer, repertoar kita mengelola proses kini lengkap dari menit pertama kelahirannya sampai jadwal panjangnya. Pergeseran berikutnya bukan lagi tentang proses, melainkan tentang service — program yang dikelola init system secara keseluruhan. Itulah pembuka Section systemd dan Services.