Anda tampaknya belum cukup menyukai timer systemd

 (blog.tjll.net)
8 poin oleh GN⁺ 2026-06-02 | 2 komentar | Bagikan ke WhatsApp
  • Timer systemd adalah pengganti praktis untuk cron, yang menjalankan unit seperti .service sesuai jadwal serta membuat pengelolaan riwayat, output, dan lingkungan lebih jelas
  • cron tradisional punya beberapa kelemahan praktis: $PATH yang ambigu, stdout/stderr yang mudah hilang, riwayat eksekusi yang sulit dilacak, dan sintaks jadwal yang sulit dibaca
  • Timer menghubungkan .timer dan .service dengan stem yang sama, dan mengekspresikan eksekusi berbasis waktu maupun event melalui OnCalendar, OnBootSec, dan OnUnitActiveSec
  • Dengan systemd-analyze calendar dan systemctl list-timers, Anda bisa memeriksa ekspresi waktu dan waktu eksekusi berikutnya, sementara WakeSystem= dapat membangunkan sistem untuk menjalankan tugas bahkan saat dalam mode suspend
  • RandomizedOffsetSec dan FixedRandomDelay= membantu mengurangi lonjakan eksekusi serentak, dan Persistent= menebus eksekusi yang terlewat saat offline segera setelah sistem kembali online

Alasan memakai timer systemd sebagai pengganti cron

  • Istilah cron job digunakan luas untuk menyebut elemen dasar komputasi yang menjalankan tugas berdasarkan jadwal seperti “jalankan ini setiap hari” atau “jalankan itu setiap bulan”, bahkan bila daemon cron yang sebenarnya tidak dipakai
  • Timer systemd adalah unit systemd yang menjalankan unit lain, biasanya .service, sesuai jadwal tertentu, dan dapat menjadi pengganti fungsional untuk daemon cron tradisional
  • cron tradisional memiliki beberapa kelemahan praktis
    • Konfigurasi $PATH yang ambigu membuat hasil eksekusi skrip sulit diprediksi
    • Output stdout dan stderr sering masuk ke lubang hitam atau dikirim ke sistem mail host
    • Riwayat eksekusi sulit dilacak dan di-query
    • Sintaks jadwal seperti 01,31 04,05 1-15 1,6 * tidak mudah dibaca atau intuitif bagi manusia
  • Timer systemd mengurangi masalah tersebut sambil tetap menyediakan pengaturan kalender yang mirip dengan gaya ekspresi cron

Struktur dasar: service dan timer

  • Timer systemd memerlukan target eksekusi, dan unit .service secara logis bisa dipandang seperti skrip
  • Sebagai contoh, jika Anda menaruh unit berikut di /etc/systemd/system/roulette.service, Anda akan memasang layanan yang mematikan komputer dengan peluang 1 banding 10
[Unit]
Description=1 in 10 chance to break your chains

[Service]
ExecStart=/usr/bin/env bash -c '[[ $(($RANDOM % 10)) == 0 ]] && systemctl poweroff || echo LIVE ANOTHER DAY'
  • ExecCondition= adalah cara yang lebih terintegrasi untuk mengekspresikan eksekusi bersyarat sebagai opsi layanan systemd, dan menampilkan “apakah ini harus terus dijalankan?” dengan lebih jelas di level unit
[Unit]
Description=1 in 10 chance to break your chains

[Service]
ExecCondition=/run/current-system/sw/bin/bash -c '[[ $(($RANDOM % 10)) == 0 ]]'
ExecStart=/run/current-system/sw/bin/systemctl poweroff
  • Jika kondisi tidak terpenuhi, jurnal akan mencatat pesan yang lebih jelas
May 05 11:05:32 diesel systemd[3117]: Condition check resulted in 1 in 10 chance to break your chains being skipped.
  • Secara umum, memanfaatkan opsi yang disediakan systemd memberi pengalaman yang lebih baik daripada menulis skrip sendiri
    • OnFailure= dapat dipakai saat ingin merespons kegagalan skrip layanan
    • Restart= dapat dipakai saat ingin mencoba pulih dari kegagalan sementara

Menghubungkan dan menjalankan unit timer

  • Jika Anda menaruh /etc/systemd/system/roulette.timer dengan stem file yang sama, Anda bisa menghubungkan timer ke roulette.service
[Unit]
Description=impending destruction

[Timer]
OnCalendar=10:00

[Install]
WantedBy=timers.target
  • Secara default, pengaturan Unit= pada timer akan memilih unit layanan dengan .service yang ditambahkan ke stem yang sama
    • Dalam contoh ini, yang dipilih adalah roulette.service
    • Jika ingin menjalankan unit layanan dengan nama lain, Anda bisa mengubah Unit=
  • Target ExecStart= secara default tidak dijalankan sebagai perintah shell
    • Target dengan path absolut harus diperlakukan sebagai skrip, atau sebagai interpreter yang mengharapkan skrip dalam argumen string
    • ExecStart=/usr/bin/echo Hello | /usr/bin/awk tidak akan bekerja di konteks ini karena pipe tidak bermakna
  • Argumen ExecStart= secara default tidak mewarisi variabel lingkungan selain beberapa default dari system manager
    • $PATH default nyaris kosong
    • Menjalankan /usr/bin/env menjadi perlindungan sederhana agar item seperti systemctl dapat digunakan
    • Jika hanya menulis ExecStart=/usr/bin/bash, $PATH akan berisi item default, tetapi memakai env adalah pengaman tambahan
  • Layanan bisa dijalankan langsung tanpa timer
systemctl start roulette
  • Layanan tanpa bagian [Install] tidak bisa di-enable, dan dalam struktur ini timer adalah cara standar untuk menjalankan layanan secara konsisten
  • systemctl secara default bekerja pada roulette.service meski akhiran tidak ditulis eksplisit
  • Menerapkan systemctl start pada unit .timer membuat timer menjadi aktif, tetapi tidak langsung menjalankan layanan target Unit=
systemctl start roulette.timer
  • status akan menunjukkan kapan timer akan dijalankan berikutnya
systemctl status roulette.timer

Trigger: Sat 2026-04-18 10:00:00 MDT; 35min left
  • Alur paling sederhana adalah membuat layanan target eksekusi, menaruh timer dengan jadwal di lokasi yang sama, lalu memulai timer, bukan targetnya
  • Jika [Install] pada unit timer memiliki WantedBy=, timer juga bisa dijalankan saat boot
systemctl enable roulette.timer

Ekspresi waktu: event kalender dan durasi

  • Dalam timer, cara mengekspresikan jadwal itu penting, dan perlu dibedakan antara rentang waktu berulang dengan event kalender atau stempel waktu
  • Manual systemd.time(7) punya cukup banyak contoh dan layak jadi referensi pertama saat menulis timer
  • systemd-analyze dapat memvalidasi dan menjelaskan ekspresi waktu
systemd-analyze calendar '*-*-* *:*:*'

Normalized form: *-*-* *:*:*
    Next elapse: Sat 2026-04-18 16:44:26 MDT
       (in UTC): Sat 2026-04-18 22:44:26 UTC
       From now: 431ms left
  • Timer systemd tidak hanya bisa mendefinisikan waktu berulang berbasis jam dinding, tetapi juga, tidak seperti cron tradisional, durasi berulang yang dihitung dari event sebelumnya
  • Bentuk lengkap daily berarti dijalankan setiap tahun, setiap bulan, setiap hari pada pukul 00:00:00
*-*-* 00:00:00
│ │ │ │  │  ╰── at second 00
│ │ │ │  ╰───── at minute 00
│ │ │ ╰──────── at hour 00
│ │ ╰────────── every day
│ ╰──────────── every month
╰────────────── every year
  • Anda bisa memakai singkatan seperti daily, bentuk lengkap, atau nilai lain yang didukung systemd.time(7), lalu memverifikasi asumsi dengan systemd-analyze

Saat eksekusi berbasis event lebih cocok

  • Dalam pekerjaan nyata, sering kali “jalankan setelah event lain” lebih cocok daripada “jalankan pada jam yang sama setiap hari”
  • Pekerjaan membersihkan direktori sementara mungkin hampir tidak punya apa pun untuk dibersihkan di /tmp jika ekspresi cron untuk sesaat setelah boot sudah terlewat
  • Mengekspresikannya sebagai “jalankan satu jam setelah komputer mulai, lalu setiap satu jam setelah itu” lebih sesuai dengan perilaku layanan yang sebenarnya dan logika penjadwalannya
[Timer]
OnBootSec=1h
OnUnitActiveSec=1h
  • OnBootSec=1h berarti dijalankan sekali satu jam setelah mesin menyala
  • OnUnitActiveSec=1h berarti dijalankan lagi satu jam setelah Unit= dieksekusi, sehingga timer secara implisit terus berulang
  • Ekspresi durasi periodik seperti ini lebih sering cocok untuk penggunaan “jalankan sesekali” daripada ekspresi seperti “jalankan pada menit ini setiap jam”
  • Dalam contoh bot Slack yang melakukan polling API Advent of Code, ekspresi cron */15 memang mematuhi kebijakan API “setiap 15 menit”, tetapi jika semua orang melakukan polling dengan cara yang sama, lalu lintas bisa menumpuk
  • Jika timer dimulai setelah perubahan kode lalu dijalankan setiap 15 menit sesudahnya, perilaku yang dibutuhkan tetap terpenuhi sambil berpotensi mengurangi masalah thundering herd

Melihat status timer secara sekilas

  • systemctl list-timers adalah perintah tingkat tinggi yang merangkum kondisi timer pada sebuah mesin
systemctl list-timers

NEXT                                 LEFT LAST                                  PASSED UNIT                         ACTIVATES
Mon 2026-04-20 15:15:00 MDT      1min 40s Mon 2026-04-20 15:00:05 MDT        13min ago zfs-snapshot-frequent.timer  zfs-snapshot-frequent.service
Mon 2026-04-20 15:32:16 MDT         18min Mon 2026-04-20 14:22:15 MDT        51min ago fwupd-refresh.timer          fwupd-refresh.service
Mon 2026-04-20 16:00:00 MDT         46min Mon 2026-04-20 15:00:05 MDT        13min ago logrotate.timer              logrotate.service
Mon 2026-04-20 16:00:00 MDT         46min Mon 2026-04-20 15:00:05 MDT        13min ago zfs-snapshot-hourly.timer    zfs-snapshot-hourly.service
Tue 2026-04-21 00:00:00 MDT            8h Mon 2026-04-20 09:43:22 MDT     5h 29min ago zfs-snapshot-daily.timer     zfs-snapshot-daily.service
Tue 2026-04-21 07:31:28 MDT           16h Sun 2026-04-19 20:15:47 MDT           7h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2026-04-27 00:00:00 MDT        6 days Mon 2026-04-20 09:43:22 MDT     5h 29min ago zfs-snapshot-weekly.timer    zfs-snapshot-weekly.service
Mon 2026-04-27 01:09:27 MDT        6 days Mon 2026-04-20 09:43:22 MDT     5h 29min ago fstrim.timer                 fstrim.service
Mon 2026-04-27 04:28:38 MDT        6 days Mon 2026-04-20 09:43:22 MDT     5h 29min ago zpool-trim.timer             zpool-trim.service
Fri 2026-05-01 00:00:00 MDT 1 week 3 days Wed 2026-04-01 10:07:51 MDT 1 week 1 day ago zfs-snapshot-monthly.timer   zfs-snapshot-monthly.service
Fri 2026-05-01 03:17:17 MDT 1 week 3 days Wed 2026-04-01 10:07:51 MDT 1 week 1 day ago zfs-scrub.timer              zfs-scrub.service

11 timers listed.
Pass --all to see loaded but inactive timers, too.
  • Dengan satu perintah, Anda bisa mendapatkan gambaran menyeluruh tentang item-item yang dijalankan menurut jadwal timer
  • list-timers adalah bagian dari keluarga subperintah systemd yang sering dipakai
    • list-units juga berguna
    • list-paths adalah subperintah yang lebih baru ditambahkan ke systemctl

Bangunkan sistem dari mode suspend untuk menjalankan tugas

  • WakeSystem= dapat membuat timer yang waktunya tiba membangunkan sistem dari mode suspend
WakeSystem=
    Takes a boolean argument. If true, an elapsing timer will
    cause the system to resume from suspend, should it be
    suspended and if the system supports this.
...
  • Fitur ini berguna saat skrip penting perlu dijalankan tanpa harus menunggu tindakan fisik seseorang membuka tutup laptop
  • Pada distribusi seperti Arch atau NixOS yang mendukung pengunduhan pembaruan paket sebelum dipakai, Anda bisa mengambil paket pembaruan larut malam dan melakukan pembaruan saat pagi hari sudah berada di depan keyboard
  • Manual menyebutkan bahwa jika ingin kembali masuk mode suspend setelah .service selesai, Anda harus menangani suspend ulang itu secara manual

Menyebarkan waktu eksekusi dan meredam thundering herd

  • Masalah thundering herd adalah masalah sistem yang terjadi saat banyak proses bangun pada saat yang sama
  • Jika semua sistem Debian di seluruh dunia di-hardcode untuk menjalankan apt update pada 00:00:00, tengah malam akan menjadi puncak trafik yang buruk bagi semua orang
  • FixedRandomDelay= dan RandomizedOffsetSec= membantu menyebarkan waktu eksekusi
FixedRandomDelay=
    Takes a boolean argument. When enabled, the randomized delay
    specified by RandomizedDelaySec= is chosen deterministically,
    and remains stable between all firings of the same timer,
    even if the manager is restarted. ...

RandomizedOffsetSec=
    Offsets the timer by a stable, randomly-selected, and evenly
    distributed amount of time between 0 and the specified time
    value. ...
  • Pengaturan seperti ini bisa dipakai pada sistem nyata yang memeriksa pembaruan perangkat lunak
  • Menyebarkan eksekusi secara merata membantu mengurangi masalah thundering herd, membuat perilaku lebih konsisten, dan membantu menghindari gangguan seperti restart daemon yang sedang mengoordinasikan layanan terdistribusi
  • Opsi timing secara umum sangat bisa dikonfigurasi dan memberi kontrol yang rinci

Segera menebus eksekusi yang terlewat

  • Persistent= sangat cocok terutama untuk skrip terjadwal yang tidak boleh terlewat hanya karena laptop sedang suspend, tetapi juga tidak sampai memerlukan WakeSystem=
Persistent=
    Takes a boolean argument. If true, the time when the service
    unit was last triggered is stored on disk. When the timer is
    activated, the service unit is triggered immediately if it
    would have been triggered at least once during the time when
    the timer was inactive. ...
  • Jika sistem yang menjadwalkan check-in manajemen konfigurasi mengalami downtime, cukup menaruh Persistent= pada .timer dapat membuatnya kembali menuju keadaan yang benar segera setelah online
  • Tanpa Persistent=, Anda mungkin harus menunggu sampai waktu eksekusi normal timer berikutnya, dan itu bisa memakan waktu lama
  • Pekerjaan lain yang juga tidak boleh menunggu saat aktivasi terlewat terdeteksi antara lain pembaruan sistem dan pemeriksaan batch job

Hal yang perlu diperhatikan saat menulis timer

  • Timer dalam konteks user manager yang dikelola dengan systemctl --user juga valid, tetapi perhatikan target yang dipakai di [Install]
  • Bergantung pada distribusinya, target yang tepat untuk timer pengguna bisa jadi default.target
  • Seperti pada cron, catatan umum bahwa jam sistem harus akurat tetap berlaku
  • Pengguna systemd dapat memeriksa status sinkronisasi dengan timedatectl timesync-status
  • Banyak editor sudah mendukung format file unit systemd secara bawaan, yang membantu saat file unit mulai membesar
  • Di Emacs, Anda bisa memakai paket emacs systemd

Bacaan terkait

2 komentar

 
GN⁺ 2026-06-02
Komentar Hacker News

  • Sulit membantah karena saya belum cukup banyak memakai systemd timer, tetapi saya kurang paham dengan pernyataan bahwa $PATH cron itu ambigu
    PATH bisa diatur langsung di dalam crontab, jadi saya tidak melihat alasan mengapa itu harus dianggap lebih sulit diprediksi dibanding pengaturan di tempat seperti /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, atau /etc/systemd/…
    Saya sudah memakai Linux sejak 1994, tetapi saya tidak menghafal sintaks cron. Namun, di komentar crontab sudah tertulis m h dom mon dow command, jadi tinggal memasukkan angka sesuai judul kolom
    Keluhan lainnya bisa saya pahami, dan lain kali kalau saya butuh pekerjaan cron, saya berniat mencoba systemd timer

    • “Tinggal memasukkan angka sesuai judul kolom” bukan ringkasan yang adil terhadap kritik awal. Itu bukan keseluruhan sintaksnya
      Ada koma, garis miring, tanda bintang, kombinasi, dan jika butuh pengacakan, biasanya itu tidak bisa dilakukan oleh cron sendiri sehingga harus dimasukkan ke dalam perintah. Menulis spesifikasi cron yang tidak sepele itu tidak mudah
    • Dari pengalaman menangani aplikasi yang mendukung ekspresi cron, angka hanyalah bagian paling dasar dari bahasanya
      Kalau seseorang memasukkan sesuatu seperti 5,3/4 4-8,11 1 4,5,6,9-11 */2, kita jadi mendapat hiburan dengan merekayasa balik apa sebenarnya maksudnya, dan biasanya itu bukan arti dari yang dia tulis
      Kalau ditambah ekstensi yang hanya didukung di sebagian lingkungan cron, jadinya makin rumit
      systemd timer jauh lebih mudah dikelola. Kemampuan mengendalikan apakah eksekusi ganda untuk pekerjaan yang berjalan lama diperbolehkan, atau menjalankan pekerjaan di antara waktu mulai-selesai alih-alih pada jam tetap, adalah peningkatan besar
      Dulu pernah ada pekerjaan backup yang masuk ke loop symbolic link dan membuat VPS mati, dan cron tetap terus meluncurkan pekerjaan backup baru meskipun backup sebelumnya belum selesai
      PATH khusus milik CRON yang membuat saya harus menulis ulang perintah dan skrip juga merepotkan, walaupun hal serupa bisa saja terjadi pada beberapa systemd timer. Meski begitu, kita tetap bisa menjalankan timer secara manual tanpa harus mengubah crontab agar berjalan 30 detik kemudian lalu menunggu
    • Saya tidak ingin meng-hardcode $PATH di crontab untuk menguji pekerjaan cron
      Jika tidak di-hardcode, maka $PATH saat cron mengeksekusi akan berbeda dari $PATH saat kita menguji perintah secara langsung. systemctl start foo.service menjalankan perintah dalam lingkungan yang sama seperti saat timer terpicu, jadi kita bisa tahu apakah perilakunya akan sama
      Sebaliknya, pekerjaan cron berjalan pada waktu yang ditentukan di crontab. systemd timer biasanya juga terpicu pada waktu yang ditentukan, tetapi karena bug logika systemd, bisa saja ia berjalan sekali pada 29 Februari lalu tidak pernah berjalan lagi, atau saat unit timer di-"restart" ia bisa terpicu atau tidak
    • Kelebihan lingkungan systemd adalah bahwa ia standar dan nyaris kosong. Sebaliknya, lingkungan crontab benar-benar berbeda dari lingkungan yang diwarisi skrip supervisord atau sysvinit, dan saya sering kena masalah karenanya
      Di systemd, apa pun pemicunya, unit yang benar-benar dijalankan tetap sama, jadi tidak ada jurang perbedaan
      Kita memang tetap perlu tahu lingkungan default-nya seperti apa, tetapi itu adalah lingkungan yang hampir bersih dan tidak terpengaruh shell. Menurut saya ini keunggulan systemd
    • Saya tidak akan menyebut PATH-nya sampai ambigu, tetapi cron memang punya masalah terkait PATH
      Nilai default-nya tidak mencakup hal-hal yang mungkin kita harapkan seperti /usr/local/bin atau /usr/sbin untuk root, dan beberapa distro seperti Arch Linux bahkan tidak mencantumkan path default maupun saran pengaturan di halaman manual
      Jika ingin menambahkan path hanya untuk satu skrip tertentu, kita harus membungkusnya dengan env, mengaturnya di skrip pembungkus, atau mengubah path sebelum entri lalu mengembalikannya setelah itu
      Kita juga tidak bisa memakai ~ atau $HOME di dalam PATH dan harus menulis path absolut lengkap, yang terutama merepotkan di crontab pengguna
      Solusinya memang tidak sulit, tetapi menurut saya pengalaman systemd timer lebih baik karena secara default memakai path yang sama dengan layanan lain

  • Saya pindah dari cronie ke systemd timer karena lebih tangguh terhadap waktu sistem mulai menyala
    Strategi backup saya adalah membuat entri arsip borg setiap hari pada waktu tetap, tetapi cronie mengharuskan sistem menyala pada waktu yang dijadwalkan. systemd timer tahan terhadap kondisi ini dan akan menjalankan layanan segera setelah sistem tersedia
    Repositori otomatisasi backup-nya ada di https://github.com/gchamon/borg-automated-backups

    • Cronie punya mekanisme untuk ini yang disebut anacron. Di sistem saya, cron memanggil /etc/cron.hourly/0anacron setiap jam dan menjalankan pekerjaan /etc/cron.{daily,weekly,monthly} meskipun waktu eksekusi paling awal sudah terlewat. Penundaan acak juga bisa diatur
      Dengan mengedit /etc/anacrontab, kita bisa membuat jadwal kustom
      Di level pengguna, mungkin kita bisa memasukkan entri seperti @hourly anacron -t /path/to/anacrontab -S /path/to/spooldir ke crontab pengguna, walaupun saya belum pernah mencobanya sendiri
      Banyak implementasi cron juga punya mekanisme serupa
    • cron punya opsi @reboot, dan saya memakainya di beberapa skrip; berfungsi dengan baik
    • Apakah Cronie tidak punya meta-trigger @reboot?

  • Saya tidak percaya nozzle printer Canon; kalau dibiarkan menganggur beberapa waktu bisa mampet. Jadi saya menyuruh Claude membuat skrip systemd agar setiap minggu mencetak foto anjing, dengan spektrum CMYK yang cukup penuh supaya printer benar-benar dipakai
    Setiap hari Senin, duduk di meja lalu tiba-tiba ada foto keluar dari printer itu jadi kejutan kecil yang cukup menyenangkan

    • Akan bagus kalau printer punya mode yang, alih-alih membuang tinta ke spons setiap beberapa hari, mencetak gambar acak dari album atau kalender
      Setidaknya bisa jadi ide proyek pameran sains anak-anak
    • Ayah saya dulu punya model yang mirip Deskjet 720
      Setelah beliau wafat, printer itu tidak dipakai selama beberapa tahun dengan kondisi mati total, lalu saat butuh cetak warna saya tinggal colokkan listrik dan langsung cetak
      Setelah sekitar 1/5 halaman pertama, semua warna kembali, dan setelah itu ia mencetak sekitar 20 halaman tanpa masalah
    • Waktu awal kuliah saya melakukan hal serupa dengan Samsung ML-2010 lama
      Masalahnya tampak lebih seperti software daripada hardware; kalau printer dibiarkan terhubung ke komputer lebih dari seminggu tanpa dipakai, pencetakan akan berhenti begitu saja
      Saya bisa saja membongkar log, tetapi sebagai gantinya saya membuat job cron yang mencetak halaman uji setiap Senin dan Kamis. Di bagian atas halaman uji itu hanya ada tulisan seperti LOL PRINTER WORKS
      Ternyata tidak terlalu boros. Saya mengambil banyak mata kuliah matematika jadi sangat butuh kertas bekas sisi balik untuk mengerjakan soal, dan saya selalu memakai hasil cetak gagal atau hasil cetak uji lebih dulu sebelum memakai kertas kosong
    • Jawabannya adalah printer laser. Penghematan bahan habis pakai saja sudah cukup untuk balik modal
    • Saya tadinya mau merekomendasikan printer warna LED OKI murah, tetapi mereka sudah keluar dari pasar konsumen
      Walau resolusi maksimumnya cuma 600dpi, warnanya sangat bagus dan merata, dan toner yang tidak mengering adalah kriteria pembelian utama kakak saya. Inkjet HP beberapa kali mampet

  • Saya sangat menyukai systemd timer. Saya pelan-pelan memindahkan semua job cron yang dulu saya deploy dengan Ansible menjadi timer, dan sekarang tinggal pakai salin-tempel Ansible saja
    Integrasinya dengan journalctl sangat bagus, dan pada OS modern seperti Debian 13 yang sudah tidak punya syslog, ini malah lebih bagus lagi. Bisa menjalankan service secara manual untuk debugging juga sangat praktis
    Job cron yang tidak jalan itu merepotkan karena harus copy-paste atau memakai skrip shell tambahan, belum lagi lubang hitam tempat stdout job cron menghilang
    Kita juga bisa memantau dan menerima notifikasi kegagalan seperti pada service systemd biasa. Saya juga senang melihat proyek open source makin sering merekomendasikan timer sebagai cara deployment

    • Tidak masalah kalau proyek merekomendasikan timer, tetapi saya baru puas kalau tetap bisa mengabaikannya dan memakai cron

  • NixOS memakai systemd secara bawaan, jadi ini diperlakukan sebagai komponen kelas satu untuk administrasi. Terutama terasa bagus kalau datang dari launchd di macOS
    Saya juga suka bahwa saat mendistribusikan tool untuk NixOS, kita bisa memanfaatkan systemd secara alami alih-alih menempelkannya sebagai tambalan
    Namun, kalau harus mendistribusikan tool dengan banyak pengelolaan siklus hidup ke seluruh pengguna Linux, saya penasaran bagaimana sebaiknya dilakukan karena systemd tidak ada di mana-mana
    Saya menjalankan scrub bulanan pada pool btrfs dengan systemd timer. Cukup berguna karena bisa menentukan apakah saat pengguna memulai scrub secara manual jadwal berikutnya dilewati, atau untuk pekerjaan bulanan ketika perangkat mati selama 6 bulan apakah tugas yang tertunda ditumpuk atau digabung jadi satu eksekusi saja

    • Di NixOS, job systemd memang sangat mudah. Mendefinisikan unit dengan Nix lebih baik daripada bergulat dengan file INI
      systemd.services.sync-recyclarr = { serviceConfig.Type = "oneshot"; path = [ pkgs.podman ]; script = '' podman exec -it recyclarr recyclarr sync radarr podman exec -it recyclarr recyclarr sync sonarr ''; };
      systemd.timers.sync-recyclarr = { timerConfig = { OnCalendar = "daily"; Persistent = true; Unit = "sync-recyclarr.service"; }; partOf = [ "sync-recyclarr.service" ]; requires = [ "podman-recyclarr.service" ]; wantedBy = [ "timers.target" ]; };
    • Saya penasaran apakah Anda mendefinisikannya langsung di dalam file flake.nix
      Saya juga memakai NixOS, tetapi semua konfigurasi saya tetap dipertahankan dalam format aslinya dan hanya diberi symbolic link lewat Nix. Dengan begitu konfigurasi itu tetap mudah dibawa ke sistem non-NixOS juga
      Masalahnya, NixOS tampaknya tidak menangkap dan menjalankan timer serta service systemd yang saya taruh di folder ~/.config/systems/user, dan hal seperti WantedBy=default.target juga tidak berpengaruh
      Karena itu, setelah saya me-restart semua service secara manual tiap selesai reboot, barulah saya setuju bahwa systemd timer memang keren

  • Timer ternyata cukup fleksibel karena bisa bekerja bukan hanya dengan unit service yang namanya sama, tetapi juga dengan unit arbitrer
    Di server saya ada timer yang memulai backup.target, yang menjalankan seluruh siklus backup restic backup, restic prune, dan restic forget, lengkap dengan waktu mulai acak tiap pagi dan notifikasi
    Unit restic-* yang sebenarnya adalah Podman Quadlet, jadi selama server punya Podman dan Systemd, konfigurasinya sendiri bisa berjalan tanpa tergantung isi server
    Meski begitu, untuk pemakaian sehari-hari timer adalah salah satu jenis unit systemd yang paling kikuk. Saya paham kenapa harus dipisah jadi dua file dan kenapa sintaks start dan enable berbeda, tetapi kadang saya cuma ingin membuat satu file, menjalankan skrip, lalu selesai

    • Saya memakai susunan serupa untuk backup. Kadang saya menonaktifkan timer karena ingin melakukan pekerjaan lain pada repositori restic, seperti membersihkan lock, lalu kena jebakan karena tidak sadar unit yang sudah terpicu sebelumnya masih tetap berjalan
    • Rasanya perlu ada satu lapisan abstraksi lagi di atas unit systemd. Akan bagus kalau ada semacam alat command line deklaratif yang menanganinya, alih-alih harus mengedit file secara langsung
      Mungkin di era LLM ini bukan masalah besar, tetapi tetap terasa sedikit merepotkan setiap kali
    • Saya penasaran kenapa waktu backup dibuat acak

  • Ada beberapa aspek systemd yang tidak selalu sangat saya sukai, tetapi saya pada umumnya setuju dengan kesan ini
    Untuk pekerjaan terjadwal tingkat “sistem”, saya hampir sepenuhnya berhenti memakai cron dan jadi lebih memilih timer systemd. Untuk penjadwalan dalam lingkup aplikasi tertentu, saya juga bisa memakai sesuatu seperti Quartz
    Alasannya agak samar dan sulit dijelaskan, tetapi pendekatan systemd terasa lebih rapi cocok dengan model di kepala saya tentang “beginilah seharusnya cara kerjanya”. Di masa lalu saya juga cukup sering mengalami eksekusi skrip cron yang sulit diprediksi karena PATH yang ambigu, meski itu bukan satu-satunya alasan
    Saya tidak akan mengklaim bahwa timer systemd secara universal dan objektif lebih baik daripada cron, tetapi setidaknya ia berhasil meyakinkan saya

  • Ini sangat bagus sebagai pengantar ke timer systemd, dan cukup meyakinkan hingga akhirnya membuat saya mencobanya
    Saya juga suka list-timers. Di cron, tidak mudah untuk memahami semua pekerjaan cron yang berjalan di satu mesin dalam sekali lihat. Kita harus memeriksa crontab semua pengguna, /etc/cron.d/, serta direktori daily/hourly/monthly
    Ada kasus penggunaan nyata di mana sesuatu perlu dijalankan sekali sekitar 5 menit setelah boot, lalu setiap sekitar 12 jam setelah itu, dan menyenangkan mengetahui timer systemd bisa menangani ini

    • Terima kasih atas kata-kata baiknya. Dalam situasi saat systemd dipakai seluas sekarang, rasanya benar-benar bernilai untuk mempelajari cara memakai alat seperti systemd-analyze dan systemctl list-timers

  • systemd terlihat rumit saat pertama dilihat, tetapi setelah dipakai, jadinya tidak ingin memakai yang lain. Mengelola semuanya dengan systemctl itu nyaman

    • Masih ada pilihan aneh dalam desainnya yang belum sepenuhnya saya pahami
      Misalnya, saya tidak mengerti mengapa definisi unit harus berupa file nyata di disk. Saat daemon memuat ulang, ia membaca ulang semua file, bukan hanya file yang berubah. Bukankah seharusnya bisa ada API untuk menambahkan unit secara terprogram? Ada sesuatu yang mirip, tetapi banyak batasannya dan tidak fleksibel
      Saya juga mempertanyakan mengapa beberapa unit tidak bisa dideklarasikan dalam satu file. Desain yang berpusat pada filesystem seperti itu, dan pilihan untuk tidak membuat abstraksi di tingkat lain, tidak terlihat cerdas. Itu juga tidak benar-benar mengikuti filosofi Unix
      Untuk format definisi unit, kalau TOML sudah ada saat itu, rasanya mereka akan memilih sesuatu yang lebih masuk akal
    • systemd memang punya halaman manual yang benar-benar berguna
    • Ada juga yang melihatnya secara berbeda. Setelah memakainya, justru jadi tidak ingin memakainya. Saya sungguh membenci systemd
      Tentu saja itu mungkin karena saya sudah tua. Jelas systemd-* adalah satu-satunya jalan yang benar, dan siapa pun yang berpandangan berbeda pasti cuma tukang menggurui
    • Saya masih tidak suka logging journald
    • Ini sudut pandang yang cukup modern. Saat systemd pertama kali muncul, orang-orang benar-benar membencinya, tetapi saya selalu menyukainya dan merasa pada akhirnya orang akan menerimanya. Senang melihat itu sekarang benar-benar terjadi

  • Saya sudah memakai Linux lebih dari 20 tahun, dan systemd lebih dari 10 tahun
    Meski begitu, selalu ada hal baru untuk dipelajari, dan ini benar-benar jadi sesuatu yang saya pertimbangkan sebagai alat berguna lainnya

    • Saya sudah memakai Linux sekitar 30 tahun, dan apparently selama puluhan tahun ini kita semua salah karena memakai cron
 
GN⁺ 2026-06-02
Opini Lobste.rs

  • systemd memang tidak sempurna, tetapi terasa banyak keputusan desainnya didasarkan pada pelajaran yang didapat dari cara-cara lama yang lebih tradisional
    Baru-baru ini saya mendengarkan lagi episode CRE tahun 2015 di mana Lennart Poettering menjelaskan latar belakangnya, dan itu masih layak direkomendasikan sampai sekarang

  • Saya termasuk pihak yang benar-benar tidak suka systemd, tetapi systemd.timers menurut saya adalah salah satu konsep yang “lumayan lebih baik” dalam produk ini
    Karena itu, agak mengejutkan melihat penulis membelanya dengan cara yang terkesan meremehkan orang-orang yang punya keluhan yang masuk akal
    Meski begitu, saya suka memakainya bersama perintah at. Untuk perintah yang dijalankan sekali pada waktu tertentu, pakai at, selain itu pakai timer systemd dan unit file sederhana
    Peningkatan yang paling ingin saya lihat adalah kemampuan mengetahui pengguna mana yang sedang menjalankan timer. Saya memang salah satu dari sedikit orang yang masih mengelola shellbox pada 2026, tetapi akan berguna jika saya bisa tahu pengguna mana yang membuat timer yang mengakses disk setiap detik

    • Untuk tujuan ini, mungkin bisa memakai unit pengguna alih-alih membuat semua orang memasang timer sistem
      Setahu saya, dengan loginctl enable-linger, itu bisa berjalan bahkan tanpa sesi pengguna yang aktif. Tentu saja ada kasus penggunaan yang mungkin tidak cukup ditangani dengan itu, dan saya tidak tahu situasi spesifiknya

  • Akan lebih baik kalau systemd timer punya hambatan awal yang lebih rendah, terutama di sisi pengelolaan pengguna
    Kalau melihat jumlah konfigurasi yang dibutuhkan, sangat sulit mengalahkan crontab -e

    • Pendekatan systemd yang membutuhkan beberapa file konfigurasi dan layanan untuk menyiapkan satu timer itu… sebagai pilihan API rasanya benar-benar tidak masuk akal

  • Saya sudah lama memikirkan cara mengumpulkan log skrip cron secara terstruktur, lalu sadar bahwa saya bisa langsung memakai systemd timer
    Masalah logging pun selesai. Sekarang tidak ada alasan untuk kembali memakai cron, dan saya berharap tahu ini lebih cepat

    • Bukankah bisa dipipe ke logger, atau ditambahkan ke file log dengan >>, atau dibiarkan default lalu menerima email?

  • Silakan bilang ini kuno, tapi saya masih menyiapkan email dari server untuk sampai ke saya
    Kalau diotomatisasi, itu ikut tersedia gratis di setiap host baru, dan dalam penggunaan sehari-hari juga cukup nyaman
    Misalnya, saya cukup membuka satu multiplexer lalu menjalankan long_running_process | mail root@localhost -s "done $?" dan melupakannya

  • Tulisan yang bagus, dan saya juga punya draf tulisan serupa yang belakangan harus saya rujuk lagi
    Jika Anda seperti saya dan masuk ke lubang kelinci systemd, saya sarankan membuat tautan simbolis untuk unit file dan timer di folder proyek terkait ke /etc/systemd/system/
    Salah satu keluhan saya terhadap systemd adalah distribusi tidak membedakan unit yang dipasang distro dengan unit yang saya tulis sendiri, dan dengan tautan simbolis saya bisa menjaga pemisahan itu sendiri

    • Sebenarnya, yang menangani pembedaan itu adalah path
      Unit sistem/paket/distribusi masuk ke /usr/lib/systemd/system, sedangkan override lokal atau unit lokal masuk ke /etc/systemd/system