- Linux sunucularında yaz saati uygulaması (DST) geçişi sırasında ortaya çıkan cron işi hatalarına dikkat çeken bir yazı
- Her yıl iki kez, pazar sabahı 2:00 veya 3:00’te saat dilimi değişirken cron işlerinin yinelenmesi ya da atlanması sorunu yaşanabiliyor
- Gerçek bir örnek olarak, vixie-cron ortamında 3:00~3:01 arasındaki bir işin 1 saniye aralıklarla 60 kez tekrar çalıştığı ve e-posta karmaşası yarattığı aktarılıyor
- Çözüm olarak UTC saat dilimi kullanımı veya bu saatlerde iş planlamaktan kaçınma, ayrıca daha iyi bir açık kaynak zamanlayıcı geliştirilmesi öneriliyor
- Sunucu yöneticileri ve DevOps mühendislerine saat dilimi geçişi risklerini yönetmenin önemini hatırlatan bir örnek
Yaz saati uygulaması ile cron işlerinin çakışması
- Pazar sabahı 2:00 veya 3:00’e cron işi koyarsanız, bu zaman yaz saati uygulaması (DST) geçiş anıyla çakıştığı için beklenmedik çalıştırma hataları oluşabilir
- DST başlarken saat bir saat ileri alınır, biterken ise bir saat geri alınır; bu da saatin yinelenmesine veya atlanmasına yol açar
- Bunun sonucunda belirli saatlerdeki işler iki kez çalışabilir ya da hiç çalışmayabilir
- Özellikle her pazar sabahı çalışan işler, yılda iki kez yaşanan DST geçişlerinden etkilenir
- Normalde sorunsuz çalışsalar da, DST geçiş günlerinde anormal tekrar çalıştırmalar görülebilir
Gerçek örnek: vixie-cron’un tekrar çalıştırma sorunu
- Linux ortamındaki vixie-cron üzerinde, DST başlangıcında 3:00~3:01 arasındaki bir işin 1 saniye aralıklarla yaklaşık 60 kez çalıştığı bir vaka aktarılıyor
- İşler birbirleriyle çakışarak e-posta bildirimlerinde patlamaya benzer bir karmaşa yarattı
- Neyse ki ilgili iş kritik değildi, bu yüzden sistemde hasar oluşmadı
- Bu tür sorunlar, cron’un basit zaman tabanlı zamanlama yapısından kaynaklanır
- Cron, saat dilimi değişikliklerini veya DST geçişlerini algılamaz; yalnızca belirtilen saatte çalıştırır
Olası çözümler ve alternatifler
- En basit yöntem, pazar sabahı 2:00 ve 3:00 saatlerine iş koymamaktır
- Bu saatlerden kaçınırsanız, DST geçişinden kaynaklanan çift çalıştırma sorununu tamamen önleyebilirsiniz
- Sunucunun saat dilimini UTC olarak ayarlamak da etkili bir alternatiftir
- UTC’de yaz saati uygulaması olmadığı için saat değişimi yaşanmaz
- Daha köklü bir çözüm olarak, daha akıllı bir iş zamanlayıcısı geliştirilmesi öneriliyor
- Çift çalıştırmayı önleme, çalışma süresi sınırı, saat dilimi farkındalığı gibi özelliklere sahip bir açık kaynak alternatif araca ihtiyaç var
Uzun vadeli öneri: yaz saati uygulamasının kaldırılması
- Yazının yazarı, en ideal çözüm olarak kamu düzeyinde DST’nin kaldırılmasını öne sürüyor
- Yılda iki kez yapılan saat değişikliği, hem sistem işletiminde hem de insan yaşamında gereksiz karmaşıklık yaratıyor
- Ancak gerçekte DST sürdüğü sürece, sistem yöneticileri ve DevOps mühendislerinin önleyici tedbirler alması gerekiyor
- Özellikle otomatik batch işleri, yedekleme, log döndürme gibi zamana bağlı işlerin yönetiminde dikkatli olunmalı
Sonuç: güvenli cron zamanlaması ilkeleri
- DST geçiş anındaki 2:00~3:00 zaman aralığındaki işlerden kaçınılmalı
- Mümkünse UTC tabanlı sunucu işletimi ile saat dilimi sorunları ortadan kaldırılmalı
- Cron’un sınırlamaları kabul edilmeli ve daha dayanıklı zamanlama araçlarının kullanımı değerlendirilmeli
- DevOps ortamlarında saat dilimi yönetimi ve otomasyon güvenilirliğinin sağlanması temel bir gerekliliktir
2 yorum
Ben de gece 2'ye ayarladığım işlerde sorun yaşadıktan sonra (bazen iki kez çalışıp bazen hiç çalışmıyordu) özellikle o saatten kaçınıyorum.
Hacker News görüşleri
DST (yaz saati uygulaması) bence tamamen yanlış bir sistem
Hiçbir sorunu çözmüyor, aksine sadece rahatsızlık yaratıyor
Sadece standart saate sabit kalınmalı, onun yerine çalışma saatleri yaz aylarındaki gibi bir saat öne alınmalı
Örneğin mağazalar 7 yerine 6'da açılıp 10 yerine 9'da kapanabilir
Nasıl olsa yılda iki kez uyum süreci yaşanıyor, bunu bir kez yapmak yeterli olur
İşten sonra daha fazla gün ışığı görmek istiyorum. Kışın özellikle daha da fazla
İşe giderken güneşin doğmuş olması umurumda değil
Zaten 9 saat kapalı alanda olacağım, boş vaktim varken güneş görmek istiyorum
Örneğin 1973-1975 arasında ABD'de yıl boyu DST deneyi yapıldı
Başta enerji tasarrufu ve suç oranının düşmesi gibi nedenlerle destek yüksekti,
ancak karanlık sabahlarda okula gidiş sırasında yaşanan kazalar nedeniyle kamuoyu hızla tersine döndü ve uygulama sonunda kaldırıldı
(Wikipedia alıntısı)
Hatta kulağa daha büyük bir zaman kaydırması istiyormuşsunuz gibi geliyor
Sadece standart saat ve yaz saati uygulaması var
“Kış saatini” sürekli kullanalım demek psikolojik olarak cazip gelmiyor
İnsanlar güneş doğmuşken güne başlamak istiyor
Programcılar DST yüzünden zorlanıyor ama bence bu, edge case işleme konusunun düzgün ele alınması gereken bir mesele
Herkesin uyku düzeni farklı olduğuna göre, insanlar kendine uygun çalışma saatini seçebilse bu çatışma azalır
Eskiden reddit sunucularını kurarken hepsini Arizona saat dilimine ayarlamıştık
Arizona DST kullanmadığı için Kaliforniya ile fark sadece 1 saatti
UTC kullanmamamızın nedeni log okurken “8 çıkarmaktansa 1 çıkarmanın daha kolay olması”ydı
Şimdi küresel bir ekip var, bu yüzden UTC'ye geçildi
En iyisi baştan her şeyi UTC'de standartlaştırmak
Dünyanın her yerinde bu tür değişiklikler sık sık oluyor; takvim uygulaması geliştirenler için gerçekten baş ağrısı
UTC'yi seçtiyseniz, YYYY-MM-DD 24 saat biçimini anlayabildiğiniz varsayılmalı
ama kurum içinde herkes bunu kendine göre PST'ye çevirince loglarda saatler birbirini tutmaz hale gelmişti
Sonunda ekip lideri devreye girip tüm uygulamaları ve veritabanlarını PST'de standartlaştırdı
Yine de artık UTC'yi içgüdüsel olarak yorumlayabiliyorum
Eskiden şirket sunucularını BST'ye (Britanya Yaz Saati) ayarlamıştım ve cron'u yoğun kullanıyordum,
her yıl iki kez aynı karmaşa tekrar ediyordu
Sonunda şirket batana kadar bunu düzeltemedik
Çıkarılacak ders basit: özel bir neden yoksa UTC kullanın
Örneğin kullanım kotası sıfırlama ya da faturalama batch işleri bölgesel saate göre çalışıyor
Örneğin Birleşik Krallık'ta saat 8 raporunun UTC karşılığı DST'ye göre değişiyor
Bu yüzden sadece UTC yetmez; saat dilimi bilgisini de birlikte saklamak gerekir
Bazı ülkelerde (Cuba, Egypt, Lebanon) DST değişikliği gece yarısında gerçekleşiyor
(ilgili bağlantı)
Brezilya'da 00:00-01:00 ya da 00:00-23:00 arasında değişmesi yaygındı
DST geçiş günlerinde ölüm oranı ve acil servis başvurularının keskin biçimde arttığını gösteren araştırmalar var
(ScienceAlert yazısı)
Bu artık sadece cron sorununun ötesinde; DST sağlığa da zararlı bir uygulama
Bu sorun aslında uzun zaman önce OpenBSD ve Debian üzerinde çözülmüştü
Debian'ın cron(8) kılavuzunda, DST geçişlerinde 3 saatten kısa zaman kaymalarının nasıl ele alındığı açıklanıyor
(patch bağlantısı,
kılavuz,
bug raporu)
Tavsiye şu: işleri gece yarısına (00:00) koymayın
Tarih kolayca karıştığı için 00:01 ya da 01:45 gibi tam denk gelmeyen saatleri kullanmak daha iyi
Sistem belirli bir anda tuhaf davranırsa sebebini izlemek daha kolay oluyor
Yalnız 12 saatlik saat kullanan ortamlarda karışıklık çıkabiliyor
Saat dilimi sorunlarıyla karşılaşana kadar fark etmemiştim ama
dünyada var olmayan saatler ve belirsiz saatler diye bir şey var
Örneğin 2'den 3'e geçerken 2:30 diye bir saat hiç oluşmuyor,
saat geri alınırken ise 2:30 iki kez yaşanıyor
Ülkeden ülkeye DST geçiş saati değiştiği için, Şili'de olduğu gibi gece yarısının yok olduğu durumlar bile olabiliyor
(ilgili blog)
Java ile Ruby bunu farklı biçimde ele alıyordu; Stripe'ta çalıştığım ilk dönemde bunun yüzünden arka arkaya üç kez olay yaşandığını hatırlıyorum
cron işlerini saat başına koymaktan kaçınıyor, mümkünse sabah 4'ten sonraya ya da gece yarısından öncesine alıyorum
Çünkü paylaşımlı altyapıda tam saatte kaynak rekabeti daha yoğun oluyor
sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ;gibi bir kod ekleyip 0-59 dakika rastgele gecikme vermek de iyi bir yöntem
Önemli zamanlanmış işler mümkün olduğunca idempotent (tekrar çalıştırıldığında güvenli) olacak şekilde tasarlanmalı
Özellikle kuyruk sistemleri işin içine girince, bu yaklaşım sorunları önlemenin anahtarı oluyor