Jumat, 10 Juli 2026

Meninggalkan Cron? Memahami Konsep Systemd Timer di Linux (Panduan DevOps)

Halo temen-temen infra dan sysadmin! Kalau ngomongin soal task scheduling di server Linux, pasti tools pertama yang muncul di kepala kita adalah Cron.

Cron emang legendaris dan battle-tested. Tapi, sejak systemd jadi standar baku di hampir semua distro Linux modern (Ubuntu, RHEL, CentOS, Debian), ada satu komponen yang secara perlahan mulai menggeser takhta cron. Dia lebih traceable, lebih terstruktur, dan jauh lebih ke-DevOps-an: Systemd Timer.

Di tulisan kali ini, kita bakal bedah bareng soal konsep .timer di systemd, alasan kenapa kalian harus mulai ninggalin legacy cron, dan gimana cara setup-nya di production.


Konsep Dasar File .timer

Gampangnya, file .timer itu mekanisme native dari systemd buat nge-trigger service lain berdasarkan waktu.

Satu aturan main yang perlu diingat: file .timer ini nggak bisa mengeksekusi script atau biner secara langsung. Tugas dia murni cuma jadi "alarm". Begitu waktunya tiba, dia bakal ngebangunin unit systemd pasangannya (biasanya file .service). Nah, file .service inilah yang nanti bakal kerja mengeksekusi perintah.

Beda sama crontab yang nyampur jadwal dan command di satu baris yang kadang bikin sakit mata, systemd misahin logic-nya jadi dua:

  1. File .service: Urusan action (skrip apa yang mau jalan, file biner apa yang dieksekusi).

  2. File .timer: Urusan scheduling (kapan si service ini harus jalan).

Secara default, kalau kalian bikin file backup.timer, systemd bakal pinter nyari dan ngejalanin backup.service. Rapi kan?


Kenapa Mesti Repot-repot Pindah dari Cron?

Pasti ada yang mikir, "Kalau cron masih jalan normal, ngapain diganti? If it ain't broke, don't fix it, kan?" Faktanya, tren industri sekarang pelan-pelan mulai ninggalin cron. Distro enterprise modern kayak Amazon Linux 2023, CentOS Stream 9, sampe Arch Linux bahkan udah nggak bundling cron (cronie) secara bawaan. Semua tugas maintenance sistem dari OS sekarang murni di-handle sama systemd timer.

Buat kita yang di DevOps, observabilitas itu harga mati. Dan di sinilah systemd timer unjuk gigi:

  1. Logging-nya Terpusat (Journald): Ini fitur favorit saya. Semua output dan error dari job yang jalan otomatis masuk ke journalctl. Tinggal ketik journalctl -u nama-service, log langsung keluar. Nggak usah lagi repot-repot mainan redirect >> /var/log/custom.log 2>&1.

  2. Dependency Management: Kita bisa bikin aturan ketat. Misalnya, timer ini cuma boleh jalan kalau service database udah running. (Tinggal set Requires= atau After= di file service-nya).

  3. Bebas Tumpang Tindih (Overlapping): Pernah ngalamin skrip cron jalannya kelamaan, terus jadwal berikutnya keburu ke-trigger sampe resource server habis? Systemd nggak gitu. Kalau service dari jadwal sebelumnya belum kelar, jadwal barunya nggak bakal ke-trigger. Aman.

  4. Fitur Catch-up (Persistent): Nah, ini yang cron nggak punya. Misal kalian set jadwal jam 2 pagi, tapi kebetulan server lagi down atau restart jam segitu. Kalau pake cron, jadwal itu ya lewat gitu aja. Kalau pake timer systemd (dengan mode persistent), begitu server up, systemd bakal nyadar ada jadwal yang bolong dan langsung nge-run saat itu juga.


Dua Tipe Timer di Systemd

Waktu kalian setup systemd timer, ada dua paradigma waktu yang bisa dipake:

1. Monotonic Timers (Waktu Relatif)

Timer ini nggak peduli jam dinding. Dia jalan berdasarkan event atau waktu yang udah lewat. Opsi yang sering dipake:

  • OnBootSec=15min: Jalanin 15 menit setelah server beres booting.

  • OnStartupSec=5min: Mirip OnBootSec, tapi dihitung dari systemd manager start. Enak dipake kalau kalian nge-run timer di level user (non-root) atau di dalem container.

  • OnUnitActiveSec=1h: Jalanin sejam setelah service target terakhir jalan.

  • OnUnitInactiveSec=2h: Jalanin 2 jam setelah service target beres jalan (stopped). Cocok buat ngasih jeda antar job yang berat.

  • Kapan pakenya? Paling pas buat housekeeping kayak bersihin cache, atau health-check internal.

2. Realtime Timers (Waktu Kalender)

Kalau yang ini feeling-nya persis banget kayak pake cron. Mainannya jam dan tanggal (RTC).

  • OnCalendar=Mon, *-*-* 02:00:00: Tiap Senin jam 2 pagi.

  • OnCalendar=*-*-* 00:00:00: Tiap tengah malem tiap hari.

  • Kapan pakenya? Jelas buat rotasi log, backup database, atau nge-generate report.

Pro-tip: Nggak usah ngafalin semua sintaksnya. Kalau lagi butuh nyontek kalender, ketik aja man systemd.time di terminal. Kalau mau liat parameter timer lengkap, ketik man systemd.timer.


Hands-on: Bikin Systemd Timer Pertama Kita

Biar lebih kebayang, mending kita langsung praktek bikin job backup harian. Semua custom unit systemd biasanya kita taruh di /etc/systemd/system/.

Langkah 1: Siapin Service-nya (Si Eksekutor)

Bikin file /etc/systemd/system/daily-backup.service:

[Unit]
Description=Layanan Pencadangan Data Aplikasi Harian

[Service]
Type=oneshot
# Ganti path ini ke script backup kalian
ExecStart=/usr/local/bin/script-backup.sh

(Catatan: Jangan kasih blok [Install] di file ini, soalnya dia bakal dipanggil dari timer).

💡 Belum terlalu fasih bikin file .service? > Kalau kalian butuh deep-dive cara nge-build file .service dari nol buat ngejalanin biner, saya udah nulis panduan lengkapnya di sini: Cara Membuat Service Systemd di Linux.

Langkah 2: Siapin Timer-nya (Si Penjadwal)

Sekarang, bikin pasangannya di /etc/systemd/system/daily-backup.timer:

[Unit]
Description=Timer untuk pencadangan harian tiap jam 1 pagi
# Nggak usah nulis Requires=daily-backup.service di sini. 
# Systemd otomatis nge-link-in ke file .service yang namanya sama persis.

[Timer]
# Jalan tiap jam 01:00 pagi
OnCalendar=*-*-* 01:00:00
# Biar kalau server mati pas jadwal, tetep di-eksekusi pas server up lagi
Persistent=true

[Install]
WantedBy=timers.target

Cara Manage dan Cek Status Timer

Kalau file-file di atas udah ready, workflow buat nyalainnya di terminal tuh gini:

  1. Reload systemd daemon biar ngebaca konfigurasi baru:

    sudo systemctl daemon-reload

  2. Enable dan Start timer-nya (Inget ya, yang di-start itu timer-nya, bukan service-nya):

    sudo systemctl enable --now daily-backup.timer

  3. Validasi! Cek daftar timer yang lagi running di server kalian:

    systemctl list-timers

    Output-nya bakal rapi kayak gini:

    NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Sat 2026-07-11 01:00:00 WIB 5h 56min left Fri 2026-07-10 01:00:15 WIB 18h ago      daily-backup.timer           daily-backup.service
Sat 2026-07-11 06:45:00 WIB 11h left      Fri 2026-07-10 07:15:33 WIB 11h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service

2 timers listed.
Pass --all to see loaded but inactive timers, too.

    Lihat kolom NEXT dan LEFT, cakep kan? Jauh lebih enak dilihat daripada nebak-nebak jadwal crontab -l.


Wrapping Up

Pindah dari habit cron ke systemd timer emang butuh sedikit effort di awal karena kita harus maintain dua file. Tapi percaya deh, buat environment production, benefit yang dikasih—terutama urusan logging via journalctl dan pencegahan sistem macet karena job overlapping—jauh lebih berharga daripada overhead bikin filenya.

Gimana, udah siap migrasiin cron jobs legacy kalian ke systemd timer? Kalau nemu error atau punya trik custom systemd sendiri, ramaikan di kolom komentar di bawah ya! Cheers!

at

Tidak ada komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)