Görünüşe göre systemd zamanlayıcılarını yeterince sevmiyorsunuz

 (blog.tjll.net)
8 puan yazan GN⁺ 2026-06-02 | 2 yorum | WhatsApp'ta paylaş
  • systemd zamanlayıcıları, cron için pratik bir alternatif olup programa göre .service gibi üniteleri çalıştırır ve geçmiş, çıktı ile ortam yönetimini daha açık hale getirir
  • Geleneksel cron, belirsiz $PATH, kolayca kaybolabilen stdout/stderr, izlenmesi zor çalışma geçmişi ve okunması güç zamanlama sözdizimi gibi zayıf yönlere sahiptir
  • Zamanlayıcılar aynı köke sahip .timer ve .service dosyalarını bağlar; OnCalendar, OnBootSec, OnUnitActiveSec ile saat ve olay tabanlı çalıştırmayı ifade eder
  • systemd-analyze calendar ve systemctl list-timers ile zaman ifadeleri ve bir sonraki çalışma zamanı kontrol edilebilir; WakeSystem= ise askı durumundayken bile sistemi uyandırıp çalıştırabilir
  • RandomizedOffsetSec ve FixedRandomDelay= eşzamanlı çalışma zirvelerini azaltır; Persistent= ise devre dışı kalınan sürede kaçırılan çalıştırmaları sistem yeniden çevrimiçi olur olmaz telafi eder

cron yerine neden systemd zamanlayıcısı kullanılmalı

  • cron job, gerçek cron arka plan süreci olmasa bile “bunu her gün çalıştır”, “şunu her ay çalıştır” gibi takvime göre işleri yürüten temel bir bilişim yapıtaşını anlatmak için yaygın biçimde kullanılır
  • systemd zamanlayıcısı, belirli bir programa göre başka bir systemd ünitesini, genellikle bir .service ünitesini çalıştıran bir systemd ünitesidir ve geleneksel cron arka plan sürecinin işlevsel yerine geçebilir
  • Geleneksel cronun pratikte bazı zayıf yönleri vardır
    • Belirsiz $PATH ayarı yüzünden betiklerin nasıl çalışacağını öngörmek zordur
    • stdout ve stderr çıktıları sık sık bir kara deliğe gider ya da makinenin posta sistemine gönderilir
    • Çalışma geçmişini izlemek ve sorgulamak zordur
    • 01,31 04,05 1-15 1,6 * gibi zamanlama sözdizimi insanlar için ne kolay okunur ne de sezgiseldir
  • systemd zamanlayıcıları bu sorunları azaltırken cron tarzı ifadelere benzeyen takvim yapılandırmaları da sunar

Temel yapı: servis ve zamanlayıcı

  • systemd zamanlayıcılarının çalıştıracağı bir hedefe ihtiyacı vardır; .service ünitesi mantıksal olarak bir betik gibi düşünülebilir
  • Örneğin /etc/systemd/system/roulette.service içine aşağıdaki üniteyi koyarsanız, bilgisayarı 10'da 1 ihtimalle kapatan bir servis kurmuş olursunuz
[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=, koşullu çalıştırmayı systemd servis seçeneği olarak ifade etmenin daha bütünleşik bir yoludur ve “çalışmaya devam edilmeli mi?” sorusunu ünite seviyesinde daha açık gösterir
[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
  • Koşul sağlanmazsa günlükte daha açık bir ifade kalır
May 05 11:05:32 diesel systemd[3117]: Condition check resulted in 1 in 10 chance to break your chains being skipped.
  • Genel olarak systemd'nin sunduğu seçeneklerden yararlanmak, her şeyi kendiniz betiklemeye göre daha iyi bir deneyim sağlar
    • OnFailure= servis betiği başarısız olduğunda tepki vermek için kullanılabilir
    • Restart= geçici hatalardan kurtulmayı denemek için kullanılabilir

Zamanlayıcı ünitesini bağlama ve çalıştırma

  • Aynı dosya köküne sahip bir /etc/systemd/system/roulette.timer dosyası oluşturarak zamanlayıcıyı roulette.service ile bağlayabilirsiniz
[Unit]
Description=impending destruction

[Timer]
OnCalendar=10:00

[Install]
WantedBy=timers.target
  • Varsayılan olarak zamanlayıcının Unit= ayarı, aynı köke sahip .service uzantılı servis ünitesini seçer
    • Bu örnekte roulette.service seçilir
    • Farklı isimli bir servis ünitesini çalıştırmak istiyorsanız Unit= değerini değiştirebilirsiniz
  • ExecStart= hedefi varsayılan olarak kabuk komutu olarak çalıştırılmaz
    • Mutlak yol hedefleri, betik olarak ya da bir betiği dize argümanı olarak bekleyen yorumlayıcı gibi ele alınmalıdır
    • ExecStart=/usr/bin/echo Hello | /usr/bin/awk burada boru anlam taşımadığından çalışmaz
  • ExecStart= argümanları varsayılan olarak, bazı sistem yöneticisi varsayılanları dışında ortam değişkenlerini miras almaz
    • Varsayılan $PATH neredeyse boş sayılabilecek durumdadır
    • /usr/bin/env çalıştırmak, systemctl gibi öğelerin kullanılabilmesini sağlayan basit bir koruma olur
    • Yalnızca ExecStart=/usr/bin/bash kullanılsaydı $PATH içine varsayılan girdiler gelirdi, ama env kullanımı ek bir güvenlik önlemidir
  • Servisi zamanlayıcı olmadan da doğrudan çalıştırabilirsiniz
systemctl start roulette
  • [Install] bölümü olmayan servisler enable edilemez; bu yapıda zamanlayıcı, servisi tutarlı biçimde çalıştırmanın standart yoludur
  • systemctl, açıkça sonek verilmemiş olsa bile varsayılan olarak roulette.service üzerinde işlem yapar
  • .timer ünitesine systemctl start uygulamak zamanlayıcıyı etkin duruma getirir, fakat gerçek Unit= hedef servisini hemen çalıştırmaz
systemctl start roulette.timer
  • status, zamanlayıcının bir sonraki ne zaman çalışacağını gösterir
systemctl status roulette.timer

Trigger: Sat 2026-04-18 10:00:00 MDT; 35min left
  • En basit akış, çalıştırılacak servisi oluşturmak, aynı yerde programı olan bir zamanlayıcı tanımlamak ve hedef yerine zamanlayıcıyı başlatmaktır
  • Zamanlayıcı ünitesinin [Install] bölümünde WantedBy= varsa, açılışta da etkinleşmesi sağlanabilir
systemctl enable roulette.timer

Zaman ifadeleri: takvim olayları ve süreler

  • Zamanlayıcılarda zamanın nasıl ifade edildiği önemlidir; yinelenen zaman aralıkları ile takvim olayları veya zaman damgaları arasındaki farkı ayırmak gerekir
  • systemd.time(7) kılavuzu bol örnek içerir ve zamanlayıcı yazarken ilk başvurulacak kaynak olmaya uygundur
  • systemd-analyze, zaman ifadelerini doğrulayabilir ve açıklayabilir
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
  • systemd zamanlayıcıları yalnızca yinelenen duvar saati zamanlarını değil, geleneksel crondan farklı olarak, önceki bir olaya göre yinelenen süreleri de tanımlayabilir
  • daily ifadesinin tam açılımı, her yıl, her ay, her gün saat 00:00:00'da çalışmasıdır
*-*-* 00:00:00
│ │ │ │  │  ╰── at second 00
│ │ │ │  ╰───── at minute 00
│ │ │ ╰──────── at hour 00
│ │ ╰────────── every day
│ ╰──────────── every month
╰────────────── every year
  • daily gibi kısaltmalar, tam biçim ve systemd.time(7) içindeki diğer desteklenen değerler kullanılabilir; varsayımlarınızı systemd-analyze ile doğrulayabilirsiniz

Olay tabanlı çalıştırmanın daha uygun olduğu durumlar

  • Gerçek işlerde çoğu zaman “her gün aynı saatte çalıştır” yerine “başka bir olaydan sonra çalıştır” yaklaşımı daha uygundur
  • Geçici dizinleri temizleyen bir işte, açılıştan hemen sonra cron ifadesindeki saat geçmişse /tmp içinde temizlenecek çok az şey olabilir
  • “Bilgisayar açıldıktan bir saat sonra çalıştır, ardından her saat tekrar çalıştır” ifadesi, servisin gerçek davranışıyla ve zamanlama mantığıyla daha iyi örtüşür
[Timer]
OnBootSec=1h
OnUnitActiveSec=1h
  • OnBootSec=1h, makine açıldıktan bir saat sonra bir kez çalıştırmak anlamına gelir
  • OnUnitActiveSec=1h, Unit= çalıştırıldıktan bir saat sonra tekrar çalıştırmak anlamına gelir ve zamanlayıcının örtük olarak tekrar etmesini sağlar
  • Bu tür periyodik süre ifadeleri, “her saatin şu dakikasında çalıştır” ifadesine göre “arada bir çalıştır” türü işler için daha sık uygundur
  • Advent of Code API'sini sorgulayan Slack botu örneğinde */15 cron ifadesi API'nin “15 dakikada bir” kuralına uyar, ancak herkes aynı şekilde sorgularsa trafik yığılabilir
  • Kod değişikliğinden sonra zamanlayıcıyı başlatıp her 15 dakika geçtiğinde çalışacak şekilde ayarlamak, gereken davranışı karşılayıp thundering herd sorununu azaltabilir

Zamanlayıcı durumunu tek bakışta görmek

  • systemctl list-timers, bir makinedeki zamanlayıcı durumunu özetleyen üst düzey bir komuttur
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.
  • Tek bir komutla, zamanlayıcı takvimine göre çalışan öğelerin genel görünümünü elde edebilirsiniz
  • list-timers, sık kullanılan systemd alt komutları ailesinin bir parçasıdır
    • list-units de kullanışlıdır
    • list-paths, systemctle daha yakın zamanda eklenen bir alt komuttur

Askı durumundayken uyandırıp çalıştırma

  • WakeSystem=, süresi dolan bir zamanlayıcının sistemi askı durumundan uyandırmasını sağlayabilir
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.
...
  • Bu özellik, birinin dizüstü bilgisayar kapağını açmasına gerek kalmadan önemli betiklerin çalışması gerektiğinde kullanışlıdır
  • Arch ya da NixOS gibi, kullanımdan önce paket güncellemesi indirmeyi destekleyen dağıtımlarda, gece geç saatlerde güncelleme paketleri önceden indirilebilir ve sabah klavye başına geçtiğinizde güncelleme yapılabilir
  • Kılavuzda, .service tamamlandıktan sonra sistemin yeniden askıya alınmasını istiyorsanız bunun elle yeniden yapılması gerektiği belirtilir

Çalışma zamanlarını dağıtma ve thundering herd etkisini azaltma

  • thundering herd sorunu, birçok sürecin aynı anda uyanmasıyla ortaya çıkan bir sistem problemidir
  • Dünyadaki tüm Debian sistemleri 00:00:00 anında apt update çalıştıracak şekilde sabit kodlanmış olsaydı, gece yarısı herkes için kötü bir trafik zirvesi olurdu
  • FixedRandomDelay= ve RandomizedOffsetSec= çalışma zamanlarını dağıtmaya yardımcı olur
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. ...
  • Bu ayarlar, yazılım güncellemelerini kontrol eden gerçek sistemlerde kullanılabilir
  • Çalıştırmaları eşit dağılımla yaymak, thundering herd sorununu azaltmaya; davranışı tutarlı hale getirmeye ve dağıtık servisleri koordine eden arka plan süreçlerinin yeniden başlatılması gibi bozucu faaliyetlerden kaçınmaya yardımcı olur
  • Zamanlama seçenekleri genel olarak çok yapılandırılabilir ve ince taneli denetim sunar

Kaçırılan çalıştırmaları hemen telafi etme

  • Persistent=, özellikle askıdaki dizüstü bilgisayar yüzünden kaçırılmaması gereken ama WakeSystem= kadar da gerekli olmayan zamanlanmış betikler için uygundur
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. ...
  • Yapılandırma yönetimi check-in'i planlanmış bir sistem kesinti yaşadıysa, .timer içine yalnızca Persistent= eklemek bile sistem çevrimiçi olur olmaz doğru duruma yakınsamasını sağlayabilir
  • Persistent= yoksa zamanlayıcının normal çalışma anını beklemeniz gerekebilir ve bu süre uzun olabilir
  • Kaçırılan etkinleştirmeyi fark ettiğinde beklememesi gereken başka işler arasında sistem güncellemeleri ve toplu iş kontrolleri de vardır

Zamanlayıcı yazarken dikkat edilmesi gerekenler

  • systemctl --user ile yönetilen kullanıcı yöneticisi bağlamındaki zamanlayıcılar da geçerlidir, ancak [Install] içinde kullanılacak hedefe dikkat etmek gerekir
  • Dağıtıma bağlı olarak kullanıcı zamanlayıcıları için uygun hedef default.target olabilir
  • Tıpkı cronda olduğu gibi, sistem saatinin doğru tutulmasına dair genel uyarı burada da geçerlidir
  • systemd kullanıcıları eşzamanlama durumunu timedatectl timesync-status ile kontrol edebilir
  • Birçok düzenleyici systemd ünite dosyası biçimini varsayılan olarak destekler; bu da ünite dosyaları büyüdüğünde yardımcı olur
  • Emacs'te emacs systemd paketi kullanılabilir

İlgili okumalar

2 yorum

 
GN⁺ 2026-06-02
Hacker News görüşleri

  • systemd timer’ları yeterince kullanmadığım için karşı çıkmam zor ama cron’un $PATH’inin belirsiz olduğu sözüne pek katılamıyorum
    PATH, crontab içinde doğrudan ayarlanabiliyor; bunun /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/… gibi yerlerde ayarlanmaktan daha öngörülemez olduğunu düşünmek için bir neden göremiyorum
    1994’ten beri Linux kullanıyorum ama cron sözdizimini ezbere bilmiyorum. Yine de crontab yorumlarında m h dom mon dow command zaten yazıyor; başlıklara uygun sayıları koymanız yeterli
    Diğer şikayetleri anlıyorum ve bir dahaki cron işine ihtiyaç duyduğumda systemd timer’ı denemeyi düşünüyorum

    • “Başlıklara uygun sayıları koymanız yeterli” demek, asıl eleştirinin adil bir özeti değil; çünkü bu tüm sözdizimi değil
      Virgüller, eğik çizgiler, yıldızlar ve bunların kombinasyonları var; rastgeleleştirme gerekiyorsa da bunu genelde cron’un içinde değil komutun içinde yapmanız gerekiyor. Önemsiz olmayan bir cron tanımı yazmak kolay değil
    • Cron ifadelerini destekleyen uygulamalarla çalışmış biri olarak, sayılar dilin sadece en temel kısmı
      Biri 5,3/4 4-8,11 1 4,5,6,9-11 */2 gibi bir şey girince aslında neyi kastettiğini tersine mühendislikle çözmek gibi bir eğlence başlıyor; üstelik çoğu zaman kastettiği şey yazdığı şey olmuyor
      Buna yalnızca bazı cron ortamlarında desteklenen uzantılar da eklenince iş daha da karmaşıklaşıyor
      systemd timer’lar çok daha yönetilebilir geldi. Uzun süren işlerin eşzamanlı tekrar çalışmasına izin verilip verilmeyeceğini kontrol etmek ya da işi sabit bir anda değil, bir başlangıç-bitiş aralığında çalıştırabilmek büyük bir iyileştirme
      Bir zamanlar bir yedekleme işi sembolik bağlantı döngüsüne girip VPS’yi çökertmişti; cron, bitmemiş bir yedekleme varken bile yeni yedekleme işleri başlatmaya devam etmişti
      Sadece CRON’a özgü PATH yüzünden komutları ve betikleri yeniden yazmak zorunda kalmak da can sıkıcıydı; gerçi bazı systemd timer’larda da benzeri olabilir. Yine de crontab’ı 30 saniye sonrasına ayarlayıp beklemek yerine timer’ı elle çalıştırabilmek güzel
    • Bir cron işini test etmek için crontab’a $PATH’i sabit yazmak istemem
      Sabit yazmazsanız, cron’un çalıştırdığı andaki $PATH ile komutu elle denerkenki $PATH farklı oluyor. systemctl start foo.service, komutu timer tetiklendiğinde olduğu gibi aynı ortamda başlattığı için aynı şekilde çalışıp çalışmayacağını bilebiliyorsunuz
      Buna karşılık cron işi crontab’da belirtilen saatte çalışır. systemd timer’lar da çoğu zaman belirtilen anda tetiklenir ama systemd’deki mantık hataları yüzünden 29 Şubat günü bir kez çalıştıktan sonra bir daha hiç çalışmayabilir ya da timer birimini “restart” ettiğinizde tetiklenebilir de tetiklenmeyebilir de
    • systemd ortamının avantajı, standart ve neredeyse boş olması
      Buna karşılık crontab ortamı, supervisord ya da sysvinit betiklerinin devraldığı ortamdan tamamen farklı ve bu bana sık sık sorun çıkardı
      systemd’de ne tetiklerse tetiklesin, gerçekten çalışan birim aynı olduğu için böyle bir kopukluk yok
      Varsayılan ortamın ne olduğunu yine de bilmeniz gerekir ama shell’den etkilenmeyen, neredeyse temiz bir ortamdır. Bence bu systemd’nin bir avantajı
    • PATH’in belirsiz olduğunu söylemem ama cron’da PATH ile ilgili sorunlar var
      Varsayılan değerde /usr/local/bin ya da root için /usr/sbin gibi beklenen yollar eksik ve Arch Linux gibi bazı dağıtımlar, kılavuz sayfalarında ne varsayılan yolu ne de bir yapılandırma önerisini belirtiyor
      Yolu yalnızca belirli bir betiğe eklemek istiyorsanız env ile sarmalamanız, bir sarmalayıcı betikte ayarlamanız ya da girdiden önce yolu değiştirip sonra geri almanız gerekiyor
      PATH içinde ~ ya da $HOME kullanamayıp tam mutlak yolu yazmak zorunda kalmak da özellikle kullanıcı crontab’larında can sıkıcı
      Etrafından dolaşmak zor değil ama varsayılan olarak diğer servislerle aynı yolu kullanan systemd timer daha iyi bir deneyim sunuyor

  • Cronie’den systemd timer’a geçmemin nedeni, sistem açılış zamanı konusunda daha esnek olmasıydı
    Yedekleme stratejim, her gün sabit bir saatte bir borg arşiv girdisi oluşturmak; cronie’de sistemin planlanan saatte açık olması gerekiyor. systemd timer bu duruma dayanıyor ve sistem kullanılabilir olur olmaz servisi çalıştırıyor
    Yedekleme otomasyonu deposu https://github.com/gchamon/borg-automated-backups

    • Cronie’de bunun için anacron adlı bir mekanizma var. Benim sistemimde cron her saat /etc/cron.hourly/0anacron çağırıyor ve en erken çalışma zamanını kaçırmış olsa bile /etc/cron.{daily,weekly,monthly} işlerini yürütüyor. Rastgele gecikme de ayarlanabiliyor
      /etc/anacrontab dosyasını düzenleyerek özel zamanlamalar oluşturabilirsiniz
      Kullanıcı düzeyinde de @hourly anacron -t /path/to/anacrontab -S /path/to/spooldir gibi bir girdiyi kullanıcı crontab’ına koymak mümkün olmalı ama bunu bizzat denemedim
      Birçok cron uygulamasında da benzer mekanizmalar var
    • cron’da @reboot seçeneği var ve bunu birkaç betikte kullanıyorum; iyi çalışıyor
    • Cronie’de @reboot meta tetikleyicisi yok mu?

  • Canon yazıcı nozulları bir süre boş kalınca tıkanabiliyor, bu yüzden onlara güvenemiyorum. Bu yüzden Claude’a bir systemd betiği yazdırıp her hafta köpek fotoğrafı bastırmasını sağladım; ayrıca yazıcıyı yeterince çalıştırması için içinde bolca CMYK spektrumu olmasına dikkat ettim
    Pazartesi günleri masama oturduğumda yazıcıdan aniden bir fotoğraf çıkması oldukça hoş bir sürpriz oluyor

    • Yazıcının birkaç günde bir mürekkebi süngere boşaltarak israf etmesi yerine, albümden ya da takvimden rastgele görseller bastıran bir modu olsa güzel olurdu
      En azından çocukların bilim fuarı projesi için bir fikir olabilir
    • Babamda Deskjet 720’ye benzer bir model vardı
      Vefatından sonra yıllarca kapalı ve kullanılmadan kaldı, ama renkli çıktı gerektiğinde sadece fişe takıp bastım
      Sayfanın yaklaşık 1/5’i geçince tüm renkler geri geldi ve sonrasında yaklaşık 20 sayfayı sorunsuz bastı
    • Üniversitenin ilk yıllarında eski bir Samsung ML-2010 ile benzer bir şey yapmıştım
      Donanımdan çok yazılım sorunu gibi görünüyordu; yazıcı bilgisayara bağlıyken bir haftadan fazla boşta kalırsa çıktılar tamamen duruyordu
      Logları kurcalayabilirdim ama onun yerine pazartesi ve perşembe günleri bir test sayfası bastıran bir cron işi yaptım. Test sayfasının üstünde sadece LOL PRINTER WORKS gibi bir ifade vardı
      Düşündüğüm kadar israf da değildi. Çok fazla matematik dersi alıyordum ve soru çözerken arka yüzü boş kağıt çok lazım oluyordu; önce başarısız çıktıları ya da test çıktıları kullanıyor, sonra temiz kağıda geçiyordum
    • Çözüm lazer yazıcı. Sadece sarf malzemesi tasarrufuyla bile kendini amorti eder
    • Ucuz bir OKI LED renkli yazıcı önerecektim ama tüketici pazarından çekildiler
      Azami çözünürlüğü sadece 600dpi olsa da renkleri çok iyi ve tutarlıydı; ayrıca tonerinin kurumaması kardeşimin temel satın alma kriteriydi. HP inkjet ise defalarca tıkandı

  • systemd timer’larını çok seviyorum. Ansible ile dağıttığım cron işlerini yavaş yavaş tamamen timer’lara taşıdım; artık sadece Ansible ile kopyalamam yetiyor
    Özellikle journalctl ile entegrasyonu çok iyi ve Debian 13 gibi syslog’un ortadan kalktığı yeni işletim sistemlerinde daha da iyi. Hata ayıklamak için servisleri elle başlatabilmek de kullanışlı
    Çalışmayan cron işleri ise kopyala-yapıştır ya da ek shell betikleri gerektiren sinir bozucu bir uğraştı; cron işlerinin standart çıktısının kaybolduğu kara delikten hiç bahsetmiyorum bile
    Her zamanki gibi systemd servislerini izleyebiliyor ve hata bildirimleri alabiliyorsunuz. Açık kaynak projelerin dağıtım yöntemi olarak giderek daha fazla timer önermesini de olumlu buluyorum

    • Projenin timer önermesi sorun değil ama görmezden gelip cron kullanabilmeliyim; ancak o zaman memnun olurum

  • NixOS’ta systemd zaten varsayılan olduğu için yönetimin birinci sınıf parçası olarak kullanılıyor. Özellikle macOS’te launchd kullanmışsanız çok iyi geliyor
    NixOS için araç dağıtırken systemd’yi sonradan eklenmiş bir yama gibi değil, doğal bir şekilde kullanabilmek de güzel
    Yine de tüm Linux kullanıcılarına yönelik, yaşam döngüsü yönetimi yoğun bir araç dağıtıyorsanız ne yapmak gerekir merak ediyorum; çünkü systemd her yerde yok
    btrfs havuzunun aylık scrub işlemini bir systemd timer ile çalıştırıyorum. Kullanıcı scrub’ı elle başlatırsa bir sonraki zamanlamayı atlamak ya da aylık bir işte cihaz 6 ay kapalı kaldığında işleri biriktirmek yerine tek çalıştırmaya indirmek gibi seçenekler sunması oldukça faydalı

    • NixOS’ta systemd işleri gerçekten çok kolay. INI dosyalarıyla boğuşmaktansa üniteleri Nix ile tanımlamak daha iyi
      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" ]; };
    • Bunları doğrudan flake.nix dosyasının içinde mi tanımlıyorsunuz, merak ettim
      Ben de NixOS kullanıyorum ama tüm yapılandırmalarımı özgün biçimlerinde tutup sadece Nix ile sembolik bağ veriyorum. Böylece yapılandırmaları non-NixOS sistemlerde de kolayca kullanabiliyorum
      Sorun şu ki NixOS, ~/.config/systems/user klasörüne koyduğum systemd timer ve servisleri algılayıp çalıştırmıyor gibi görünüyor; WantedBy=default.target gibi şeyler de etkisiz kalıyor
      Bu yüzden her yeniden başlatmadan sonra tüm servisleri elle yeniden başlatmak zorunda kaldığınızda, systemd timer’larının ne kadar harika olduğuna katılmaya başlıyorsunuz

  • Timer’lar sadece aynı isimdeki servis üniteleriyle değil, keyfi ünitelerle de çalışabildiği için şaşırtıcı derecede esnek
    Sunucumda, her sabah rastgele bir başlangıç saati ve bildirimle birlikte restic backup, restic prune, restic forget içeren tüm yedekleme döngüsünü çalıştıran backup.target bir timer ile başlatılıyor
    Asıl restic-* üniteleri Podman Quadlet olduğu için, sunucuda sadece Podman ve Systemd varsa yapılandırma sunucunun içeriğinden bağımsız şekilde çalışıyor
    Yine de timer’lar, günlük kullanım için systemd’nin en kaba ünite türlerinden biri. Neden iki dosyaya bölündüğünü ve start ile enable sözdiziminin neden farklı olduğunu anlıyorum ama bazen sadece tek dosya oluşturup bir betik çalıştırmak ve işi bitirmek istiyorum

    • Yedeklemelerde benzer bir düzen kullanıyorum. Bazen restic deposunda kilit temizleme gibi başka işler yapmak için timer’ı devre dışı bırakıyordum ama önceden tetiklenmiş bir ünitenin hâlâ çalıştığını fark etmeyip sıkıntı yaşadığım oldu
    • systemd ünitelerinin üstünde bir soyutlama katmanı daha olmalı gibi geliyor. Dosyaları elle düzenlemek yerine bunu bildirimsel bir komut satırı aracı halletse güzel olurdu
      LLM çağında bu belki büyük bir sorun değildir ama her seferinde az da olsa uğraştırıcı geliyor
    • Yedekleme zamanlarını neden rastgeleleştirdiğinizi merak ettim

  • systemd'nin bazı yönlerini her zaman çok sevmiş değilim ama bu görüşe genel olarak katılıyorum
    “Sistem” düzeyindeki zamanlanmış işler için cron kullanmayı neredeyse tamamen bırakıp systemd timer tercih etmeye başladım. Belirli uygulama kapsamındaki zamanlama için Quartz gibi bir şey de kullanılabilir
    Nedeni biraz belirsiz ve açıklaması zor ama systemd yaklaşımı, “bir şeyler böyle çalışmalı” şeklindeki zihinsel modelime daha temiz oturuyor. Geçmişte cron betiklerinin çalıştırılmasında PATH belirsiz olduğu için öngörülemez durumlar da epey yaşadım; mesele sadece bu da değil
    systemd timer'ların evrensel ve nesnel olarak cron'dan daha iyi olduğunu iddia etmiyorum ama en azından beni ikna etmeyi başardı

  • systemd timer'lara giriş için çok iyiydi; hatta sonunda denememi sağlayacak kadar ikna ediciydi
    list-timers da hoşuma gitti. cron'da tek bir makinede çalışan tüm cron işlerini bir bakışta görmek kolay değildi. Tüm kullanıcıların crontab'lerini, /etc/cron.d/ dizinini ve daily/hourly/monthly dizinlerini kontrol etmek gerekiyordu
    Gerçekten de açılıştan yaklaşık 5 dakika sonra bir kez çalıştırıp ardından yaklaşık her 12 saatte bir çalıştırmam gereken bir kullanım durumum var; bunu systemd timer'ın halledebilmesi güzel

    • Güzel sözler için teşekkürler. systemd'nin artık bu kadar yaygın kullanıldığı bir ortamda systemd-analyze ve systemctl list-timers gibi araçların kullanımını öğrenmenin gerçekten değerli olduğunu düşünüyorum

  • systemd ilk bakışta karmaşık ama kullandıkça başka bir şey kullanmak istemez hale geliyorsun. Her şeyi systemctl ile yönetmek rahat

    • Tasarımında hâlâ tam anlayamadığım tuhaf seçimler var
      Örneğin unit tanımlarının neden mutlaka disk üzerindeki gerçek dosyalar olması gerektiğini anlamıyorum. Daemon yeniden yüklendiğinde sadece değişen dosyaları değil, tüm dosyaları yeniden okuyor. Unit'leri programatik olarak eklemeye yönelik bir API olamaz mıydı diye düşünüyorum. Benzeri şeyler var ama çok kısıtlı ve esnek değil
      Tek bir dosya içinde birden fazla unit tanımlanamaması da garip geliyor. Dosya sistemi merkezli tasarlanmış olması ve başka soyutlama katmanları düşünülmemiş olması akıllıca görünmüyor. Zaten pek Unix felsefesini de izlemiyor
      Unit tanım biçimi konusunda da, o zamanlar TOML olsaydı muhtemelen daha mantıklı bir şey kullanılırdı diye düşünüyorum
    • systemd'nin gerçekten işe yarayan man sayfaları var
    • Buna farklı bakanlar da var. Deneyip kullandıktan sonra bir daha kullanmak istemeyen taraftayım. systemd'den gerçekten nefret ediyorum
      Tabii bunun sebebi yaşlanmış olmamdır herhalde. Sonuçta tek doğru yol elbette sadece systemd-* ve farklı düşünen herkes koltuk yorumcusu olsa gerek
    • Hâlâ journald loglamasından hoşlanmıyorum
    • Oldukça modern bir bakış açısı. systemd ilk çıktığında insanlar ondan gerçekten nefret ediyordu ama ben onu hep sevdim ve insanların sonunda kabulleneceğini düşünüyordum. Şimdi bunun gerçekten gerçekleştiğini görmek güzel

  • Linux'u 20 yılı aşkın, systemd'yi ise 10 yılı aşkın süredir kullanıyorum
    Buna rağmen hâlâ öğrenilecek yeni şeyler çıkıyor ve bunu gerçekten bir başka faydalı araç olarak değerlendirmeye başlıyorum

    • Linux'u yaklaşık 30 yıldır kullanıyorum; görünüşe göre onlarca yıldır cron kullanarak hepimiz yanlış yapıyormuşuz
 
GN⁺ 2026-06-02
Lobste.rs görüşleri

  • systemd mükemmel değil ama birçok tasarım kararının daha geleneksel eski yaklaşımlardan çıkarılan derslere dayandığı hissine kapılıyorum
    Yakın zamanda Lennart Poettering’in bunun arka planını anlattığı CRE’nin 2015 tarihli bölümünü yeniden dinledim; hâlâ tavsiye etmeye değer

  • İçten içe systemd’den hiç hoşlanmayan taraftayım ama systemd.timers’ın bu üründeki “eh işte daha iyi” fikirlerden biri olduğunu düşünüyorum
    Bu yüzden yazarın, geçerli şikâyetleri olan insanları küçümser gibi savunmaya geçmesi biraz şaşırtıcıydı
    Yine de at komutuyla birlikte kullanmak güzel. Belirli bir zamanda bir kez çalıştırılacak komutlar için at, diğer her şey içinse systemd zamanlayıcıları ve basit unit dosyaları kullanıyorum
    En çok görmek istediğim iyileştirme, zamanlayıcıyı hangi kullanıcının çalıştırdığını görebilmek. 2026’da shell box işleten sayılı insanlardan biri olabilirim ama her saniye diske vuran bir zamanlayıcıyı hangi kullanıcının oluşturduğunu bilmek faydalı olurdu

    • Bu amaç için, herkesin sistem zamanlayıcısı kurmasını sağlamak yerine kullanıcı unit’leri kullanılabilir diye düşünüyorum
      loginctl enable-linger ile etkin bir kullanıcı oturumu olmadan da çalışabildiklerini sanıyorum. Elbette bunun yetmeyeceği kullanım örnekleri de vardır, somut durumu bilmiyorum

  • Özellikle kullanıcı yönetimi tarafında systemd zamanlayıcılarının başlangıç yükü daha düşük olsa iyi olurdu
    Gerekli yapılandırma miktarına bakınca crontab -e’yi geçmek gerçekten zor

    • Tek bir zamanlayıcı kurmak için birden fazla yapılandırma dosyası ve servis gerektiren systemd yaklaşımı… API tercihi olarak savunulamayacak kadar kötü

  • Cron betiği loglarını düzenli biçimde toplamanın bir yolunu uzun süre düşündükten sonra, aslında sadece systemd zamanlayıcıları kullanmam gerektiğini fark ettim
    Loglama sorunu çözülmüş oldu. Artık cron’a geri dönmek için bir nedenim yok; keşke bunu daha önce bilseydim

    • logger ile pipe etmek ya da log dosyasına >> ile eklemek veya varsayılanı bırakıp e-posta almak yeterli değil mi?

  • İstediğiniz kadar eski kafalı deyin ama sunucudan bana ulaşan e-postayı hâlâ yapılandırıyorum
    Otomatikleştirince her yeni hostta bedavaya geliyor ve günlük kullanımda da oldukça pratik
    Örneğin bir multiplexer açıp long_running_process | mail root@localhost -s "done $?" çalıştırıyor ve sonra unutuyorum

  • Güzel bir yazı; benim de benzer bir yazının taslağı vardı ve yakın zamanda tekrar başvurmam gerekti
    Benim gibi systemd tavşan deliğine girerseniz, ilgili proje klasöründeki unit dosyalarını ve zamanlayıcıları /etc/systemd/system/ içine sembolik bağlantı ile koymanızı öneririm
    systemd ile ilgili bir şikâyetim, dağıtımın kurduğu unit’lerle benim yazdığım unit’leri ayırt etmemesi; sembolik bağlantılarla bu ayrımı kendiniz koruyabilirsiniz

    • Aslında bu ayrımı yol belirliyor
      Sistem/paket/dağıtım unit’leri /usr/lib/systemd/system altında olur, yerel override’lar veya yerel unit’ler ise /etc/systemd/system altında yer alır