VPS saat sapması neden olur ve nasıl düzeltilir?

VPS saatiniz neden sapar

Bir VPS saati, onu düzelten bir mekanizma olmadığı için sapar. Çekirdek, zamanı biraz hızlı veya biraz yavaş çalışan bir donanım sayacından hesaplar; zaman eşitleme istemcisi çalışmadığında bu küçük hata her saat başı büyür. Sanal makine içerisinde ikinci bir neden daha vardır: konuk sistem, fiziksel işlemciyi diğer konuklarla paylaşır; bu nedenle işlemcinin atanmadığı anlar, zamanın sayılamadığı anlardır.

Güncel bir KVM konuğunda sayacın kendisi nadiren asıl sorundur. kvm-clock paravirtual kaynağı, ana makinenin (host) tuttuğu bir değeri okur; bu nedenle sağlıklı bir konuk, ana makinesini yakından takip eder. Gözle görülür şekilde yanlış olan saatler genellikle daha basit bir nedenden dolayı hatalıdır. Ya hiçbir eşitleme servisi (daemon) çalışmıyordur, ya iki servis aynı anda çalışıp çakışıyordur ya da giden UDP 123 numaralı port trafiği sağlayıcınızın ağından çıkamıyordur. Bir konuk, zaman disiplinini kendi osilatöründen değil, ana makineden veya NTP (network time protocol) üzerinden alır.

Yanlış bir saat aslında neleri bozar

• TOTP (zamana dayalı tek kullanımlık şifre) iki faktörlü doğrulama kodları eşleşmeyi durdurur; bu nedenle şifresi ve anahtarı doğru olan bir sunucuya erişiminiz engellenir.
• Bir dakika önce düzenlenmiş bir sertifika reddedilir ve curl, SSL certificate problem: certificate is not yet valid çıktısını verir.
• apt update, E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) içeren bir depoyu reddeder.
• Zamanlanmış işler yanlış zamanda tetiklenir; ileri geri atlayan bir saat, bir işin iki kez çalışmasına veya diğerinin atlanmasına neden olabilir.
• İki farklı sunucudan gelen loglar hizalanamaz; bu nedenle bir olay zaman çizelgesi tahminlerle oluşturulmak zorunda kalır.

Tolerans, çoğu insanın beklediğinden daha düşüktür. Aşağıdaki rakamlar belgelenmiş varsayılan değerlerdir, test ölçümleri değildir.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Bir TOTP kodu, her 30 saniyede bir ilerleyen bir sayaçtan hesaplanır ve çoğu doğrulayıcı her iki yönde bir adımı kabul eder. Her yönde yarım dakikalık bir hata, tüm bütçeyi tüketir. Kerberos, 300 saniyelik varsayılan sapma payı ile çok daha esnektir. Bir sertifika ise hiç esnek değildir: 0 saniyelik bir müsamaha süresi ile sabit anlara göre kontrol edilir; bu nedenle bir saniye ileride olan bir saat, tamamen geçerli bir sertifikayı reddeder.

Üç saat ve hangisinin önemli olduğu

Sistem saati, önemli olan saattir. Bu saat, çekirdeğin CLOCK_REALTIME değeridir: 1 Ocak 1970 UTC'den bu yana geçen saniye sayısıdır; bellekte tutulur ve zaman damgası kullanan her şey tarafından okunur. Günlük satırları, sertifika kontrolleri, TOTP kodları ve dosya değiştirme zamanlarının tamamı bu saatten gelir. Birisi sunucunun zamanının yanlış olduğunu söylediğinde, kastettiği saat budur.

Donanım saati, diğer adıyla RTC (gerçek zamanlı saat), makine kapalıyken de çalışmaya devam eden ayrı bir sayaçtır. Fiziksel bir makinede bu, pille desteklenen bir çiptir. Bir konuk sistemin içinde ise hipervizör tarafından taklit edilir, bu nedenle büyük ölçüde ana makineye ait bir yapıdır. Linux, başlangıç değeri olarak bunu açılışta bir kez okur ve ardından kendi sayacını tutar. timedatectl, bu değeri RTC time satırında yazdırır. Bir VPS üzerinde bu satıra bakarak hata ayıklamayın; çünkü bu satır sistem saatinizin eşitleme durumundan ziyade ana makinenin zaman algısı hakkında bilgi verir. Bir konteyner içinde genellikle hiç /dev/rtc bulunmaz, bu nedenle hwclock --show komutu hwclock: Cannot access the Hardware Clock via any known method. hatasıyla başarısız olur.

Saat kaynağı (clocksource), çekirdeğin bu okumalar arasında sayım yapmak için kullandığı mekanizmadır. Çekirdeğinize hangisini seçtiğini sorun:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

KVM üzerinde genellikle kvm-clock görürsünüz. Bu, ana makine tarafından korunan bir değeri okur; bu yüzden NTP istemcisi olmayan bir KVM konuğu bile bir süre boyunca yaklaşık olarak doğru zamanda kalır. tsc, işlemcinin kendi sayacıdır. Xen konukları xen, Hyper-V konukları ise hyperv kaynağını bildirir. Ölçülebilir bir nedeniniz olmadıkça bu ayarı değiştirmeyin, çünkü çekirdek zaten o donanımda güvendiği en iyi kaynağı otomatik olarak seçer.

Bazı ana makineler konuğa bir PTP (hassas zaman protokolü) aygıtı da sunar; bu, chrony'nin ana makine saatini ağ üzerinden değil doğrudan okumasını sağlar. Bunu kontrol etmekte fayda vardır, ancak paylaşımlı VPS üzerinde genellikle kullanılamaz:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Eğer modprobe başarısız olursa veya hiçbir aygıt görünmezse, ana makineniz bunu sunmuyordur ve çözümünüz ağ tabanlı NTP'dir. Eğer clock_name, KVM sanal saatini belirtiyorsa, chrony bunu yapılandırma dosyasındaki bir refclock PHC /dev/ptp0 poll 2 satırı ile kullanabilir.

Kendi makinenizdeki zaman durumunu okuyun

Tek bir komutla başlayın. Bu komut, "saati doğru tutan bir şey var mı" sorusunu tek bir ekranda yanıtlar.

timedatectl

Aklınızda kalan bir sayıya güvenmek yerine şu satırları okuyun:

• Local time ve Universal time, kendi zaman diliminizde ve UTC olarak yazdırılan aynı anı ifade eder. Eğer bunlar aynıysa, makine zaten UTC üzerindedir.
• RTC time, yukarıda açıklanan donanım saatidir. Bir VPS üzerinde bunu görmezden gelin.
• Time zone, sistemin yerel saati biçimlendirmek için kullandığı değerdir.
• System clock synchronized, çekirdeğin kendi bayrağıdır. Bir zaman servisi (daemon), kaynaklarına güvendiği anda bu bayrağı ayarlar; bu nedenle no, sistem açıldığından beri saatin hiçbir şekilde düzenlenmediği anlamına gelir.
• NTP service, özellikle systemd-timesyncd hakkında rapor verir. n/a, chrony çalıştıran bir makinede normaldir çünkü timesyncd orada yüklü değildir. System clock synchronized: yes ve NTP service: n/a birlikte, chrony'nin işini yaptığını ve çekirdeğin de bunu onayladığını gösterir.

Ardından, ne kadar sapma olduğunu sorgulayın. Telefonunuzla kıyaslayarak tahmin yürütmeyin. Eğer chrony çalışıyorsa:

chronyc tracking
chronyc sources -v

chronyc tracking, soruyu yanıtlayan sayıları yazdırır. System time, NTP zamanından mevcut sapmadır; ardından fast veya slow kelimesi gelir. Last offset, en son yapılan düzeltmenin boyutudur. Frequency, chrony'nin saatinizde ölçtüğü ve halihazırda telafi ettiği hata oranıdır. Leap status, Normal değerini göstermelidir. Eğer Not synchronised değerini gösteriyorsa ve Reference ID değeri 00000000 () ise, chrony henüz bir kaynağa karar vermemiştir.

chronyc sources -v, sembolleri hatırlamak zorunda kalmamanız için listenin üzerinde bir açıklama yazdırır. Anlamın büyük kısmını iki sütun taşır. Her satırın başındaki durum karakteri, chrony'nin o kaynağı nasıl derecelendirdiğini gösterir; * şu anda kullanılan kaynağı işaret ederken, her satırdaki ? hiçbir kaynağın yanıt vermediği anlamına gelir. Reach, son sekiz sorgunun yanıt geçmişini sekizlik tabanda yazdırır: 377, sekiz sorgunun da yanıtlandığı, 0 ise hiçbirinin yanıtlanmadığı anlamına gelir.

Eğer bunun yerine systemd-timesyncd görevliyse:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status, iletişim kurduğu sunucuyu, sorgulama aralığını ve bir Offset değerini yazdırır. Eğer komut durum bilgisini yazdırmak yerine servis hakkında bir hata döndürürse, bu makinede görevli olan daemon timesyncd değildir; bu durum zaten sorunuzun cevabıdır.

Ek araçlar kullanmadan dış dünyayla kaba bir kontrol yapmak için saatinizi, GMT cinsinden ve bir saniyelik çözünürlükle sunulan genel bir HTTP Date başlığı ile karşılaştırın:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Buradaki bir veya iki saniyelik fark normaldir ve bir anlam ifade etmez. Bir dakikalık fark ise sizin hatanızdır.

VPS üzerinde chrony veya systemd-timesyncd kullanımı

Ubuntu ve Debian, varsayılan olarak systemd-timesyncd ile gelir. Bu bir SNTP (basit ağ zaman protokolü) istemcisidir: tek seferde bir sunucuya sorgu gönderir ve saati o sunucuya göre hafifçe ayarlar. Sürekli çevrimiçi kalan ve başlangıçta yaklaşık olarak doğru bir saate sahip makineler için bu yeterlidir ve çalışması neredeyse hiçbir kaynak tüketmez.

chrony, tam bir NTP uygulamasıdır ve kendi çıktısında da görebileceğiniz nedenlerden dolayı sanal makineler için daha iyi bir varsayılandır. Aynı anda birden fazla kaynağı sorgular ve tutarsız olanları eler. Saatinizdeki sapma oranını ölçer ve bunu bir drift dosyasına yazar; böylece her örneklemeyi takip etmek yerine saatin sapma eğilimini düzeltir. Ayrıca, fiziksel bir sunucunun aksine sanal makinelerin yaşadığı iki durumdan hızla kurtulabilir: ana makine tarafından duraklatılabilir ve çalışırken farklı bir ana makineye taşınabilir. Bir ana makine PTP aygıtı sunulduğunda, bunu okuyan yazılım chrony'dir.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Kurulum sırasında apt çıktısını takip edin. Debian ve Ubuntu üzerinde chrony ve systemd-timesyncd paketlerinin her ikisi de time-daemon sağlar, bu nedenle apt, chrony'yi kurarken timesyncd'yi kaldırır. Bu beklenen ve doğru bir davranıştır. Asla ikisini birden çalıştırmayın; aynı saati ayarlamaya çalışan iki daemon birbiriyle çakışacaktır ve bu süreçte ikisinin de raporladığı sapma değerlerine güvenilemez. Rocky ve AlmaLinux üzerinde sudo dnf install -y chrony ile kurulum yapın; burada birim adı chrony yerine chronyd olarak geçer.

Yapılandırma dosyası Debian ve Ubuntu üzerinde /etc/chrony/chrony.conf, Rocky ve Alma üzerinde ise /etc/chrony.conf konumundadır. Dağıtımın varsayılan ayarları bir VPS için zaten makuldür, bu yüzden sadece geçerli bir nedeniniz varsa değişiklik yapın. İki yönergeyi anlamakta fayda vardır:

• pool ve server satırları zaman kaynaklarını belirtir. iburst eklemek, chrony'ye başlangıçta hızlı bir veri paketi göndermesini söyler; böylece ilk eşitleme dakikalar yerine saniyeler içinde gerçekleşir.

• makestep, chrony'nin saati ne zaman atlatarak (jump) ne zaman yavaşça düzelteceğine (slew) karar verir. Kendi ayarınızı grep -n makestep /etc/chrony/chrony.conf ile kontrol edin. Debian ve Ubuntu varsayılanı olan makestep 1 3 şu anlama gelir: chronyd başladıktan sonraki ilk üç güncelleme sırasında, eğer sapma bir saniyeden fazlaysa saati doğrudan atlat, sonrasında ise sadece yavaşlatarak düzelt.

Zaman trafiğinin yol üzerindeki müdahalelere karşı doğrulanmasını istiyorsanız, chrony 4 ve sonraki sürümleri NTS (ağ zaman güvenliği) desteği sunar. Öncelikle chronyd -v ile sürümünüzü doğrulayın ve NTS'nin UDP 123'ün yanı sıra giden TCP 4460 portunun da açık olmasını gerektirdiğini unutmayın:

server time.cloudflare.com iburst nts

Güvenmeden önce yeniden başlatın ve doğrulayın. Ayrıştırılamayan bir yapılandırma, sizi zaman daemon'ı olmadan bırakır ve saat size bunun bilgisini vermez.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Dakikalarca hatalı olan bir saatin neden hatalı kalmaya devam ettiği

Bir zaman servisi (time daemon), sapmayı düzeltmek için iki yöntem kullanır. "Slewing" (yavaşlatma/hızlandırma) yöntemi, hata giderilene kadar saati hızlandırır veya yavaşlatır; bu yöntem zamanın ileri doğru akmasını sağlar, zaman damgalarının tekrarlanmasına veya atlanmasına neden olmaz. "Stepping" (adım atma) yöntemi ise saati doğrudan doğru değere atlatır; bu yöntem hızlıdır ancak saati geriye alabilir. Saat geriye alındığında, duvar saatine göre geçen süreyi ölçen tüm süreçler için tehlikeli bir durum oluşur; bu nedenle her iki servis de "slewing" yöntemini tercih eder.

Bu tercih, ciddi şekilde hatalı bir saatin uzun süre hatalı kalmasının nedenidir. chrony, yalnızca makestep ile izin verilen aralıkta adım atma (stepping) işlemini gerçekleştirir; bu aralık varsayılan olarak servis başlatıldıktan sonraki ilk birkaç güncellemedir. Bir haftadır çalışan ve kırk saniyelik bir hata tespit eden chronyd, bu hatayı "slewing" ile düzeltmeye çalışır; kırk saniyelik bir sapmanın "slewing" ile düzeltilmesi ise beklemek isteyeceğinizden çok daha uzun sürer. Bu işlemi sakin bir anda manuel olarak zorlayın:

sudo chronyc makestep
chronyc tracking

chronyc tracking artık sıfıra yakın bir System time sapması bildirmeli ve Last offset az önce düzeltilen hatanın boyutunu göstermelidir. Bu komutu yoğun bir veritabanı sunucusunda çalıştırmadan önce düşünün; çünkü geriye doğru atlayan bir saat, zamanın yalnızca ileri aktığını varsayan yazılımların hatalı çalışmasına neden olabilir. Servisi yeniden başlatmak, aynı düzeltmenin daha güvenli bir yoludur; çünkü makestep penceresi başlangıçta tekrar açılır.

Kapsayıcılar ana makinenin saatini paylaşır

Bir kapsayıcının kendine ait bir duvar saati yoktur, bu nedenle içinde senkronize edilecek bir şey bulunmaz. Linux zaman isim alanları (time namespaces) yalnızca monotonik ve önyükleme zamanlı saatleri sanallaştırır. CLOCK_REALTIME sanallaştırılmamıştır; bu da bir kapsayıcının üzerinde çalıştığı ana makine ile aynı sistem saatini okuduğu anlamına gelir. Ana makinedeki saati düzelttiğinizde, o makinedeki tüm kapsayıcıların saati aynı anda düzelmiş olur.

Bunun birkaç sonucu vardır. Bir imajın içine chrony veya ntpd kurmayın, çünkü en iyi ihtimalle hiçbir işe yaramayacaktır. Yetkisiz bir kapsayıcı içinde tarih ayarı yapmak date: cannot set date: Operation not permitted hatasıyla başarısız olur, çünkü çekirdek bu çağrı için CAP_SYS_TIME yetkisi gerektirir. CAP_SYS_TIME yetkisini vermek kapsayıcıya özel bir saat sağlamaz; bunun yerine kapsayıcıya ana makinenin saatini ve dolayısıyla diğer tüm kapsayıcıların saatini değiştirme yetkisi verir.

Kapsayıcı içindeki farklı bir saat dilimi bir saat sorunu değildir. Kendi /etc/localtime dosyasını taşıyan bir imaj, aynı anı farklı bir dilime göre biçimlendirerek yazdırır; bu nedenle saat doğruyken date yanlış görünür. Kapsayıcı ortamında TZ=UTC değişkenini ayarladığınızda bu karışıklık ortadan kalkar. Seçtiğiniz çalışma zamanı burada hiçbir şeyi değiştirmez; rootless Podman ve Docker karşılaştırması nelerin değiştiğini açıklamaktadır.

Zaman dilimleri: Sunucuda UTC, kullanıcılar için yerel saat

Makineyi UTC olarak ayarlayın ve öyle bırakın.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC'de yaz saati uygulaması yoktur ve tüm mesele bundan ibarettir. Yaz saati uygulanan bir bölgede 02:30'da çalışan günlük bir iş, saatlerin geri alındığı gün iki kez çalışır, ileri alındığı gün ise hiç çalışmaz. man 8 cron, üç saatten kısa süreli değişimler için özel işleme yöntemlerini açıklar: ileri atlama nedeniyle atlanan işler değişimden hemen sonra çalıştırılır, geri atlama nedeniyle tekrarlanan bir saat dilimine denk gelen işler ise ikinci kez çalıştırılmaz. Bu davranış makuldür ancak 03:00 sularında kafa yormanız gereken bir durum olmamalıdır. UTC altında iş, yılın her günü, günde bir kez çalışır. Eğer bir işiniz tuhaf bir saatte çalışmak yerine tamamen kayıpsa, cron işinin sessizce hiç çalışmamasının nedenleri daha olası bir açıklamadır.

Aynı mantık günlük kayıtlarını okumak için de geçerlidir. journalctl zaman damgalarını sistem saat diliminde biçimlendirir, journalctl --utc ise UTC kullanımını zorunlu kılar. İki farklı zaman dilimindeki iki sunucu, her olayı bir dönüştürme egzersizine dönüştürür; baskı altındayken yapılan dönüştürmeler ise zaman çizelgesinin yanlış okunmasına neden olur. Sistemleri UTC'de tutun, zaman damgalarını UTC olarak saklayın ve yalnızca bir insan tarafından okunduğu noktada dönüştürme yapın. Tek bir komut için yerel saatle okuma yapmak isteyen herkes, makineyi değiştirmeden bunu talep edebilir:

TZ=Europe/Berlin date

timedatectl çıktısındaki bir satır daha bu bölüme aittir. RTC in local TZ değeri no olarak okunmalıdır. Bunu yes olarak ayarlamak, bir dizüstü bilgisayarda Windows ile dual-boot yaparken kullanılan bir geçici çözümdür; sunucuda ise sadece daha sonra birinin hata yapmasına neden olacak bir sapma ekler. Bu ayar yapıldığında, timedatectl sistemin RTC saatini yerel saat diliminde okuyacak şekilde yapılandırıldığına dair bir uyarı verir.

Belirti bazlı sorun giderme

İki faktörlü doğrulama kodunuz bir sunucuda reddediliyor. Başka hiçbir şeye bakmadan önce sistem saatini kontrol edin. Kod, her 30 saniyede bir ilerleyen bir sayaçtan üretilir; bu nedenle 90 saniye geride olan bir sunucu, telefonunuzun çoktan geçtiği bir adıma ait kodu hesaplar. timedatectl komutu System clock synchronized: no çıktısını verecek veya chronyc tracking büyük bir System time sapması bildirecektir. Bu durum, doğrudan reddedilen bir anahtardan farklı bir hatadır; anahtar reddi kendi hata mesajını üretir ve açık anahtar kimlik doğrulama hataları kılavuzu içerisinde ele alınmıştır.

apt update bir Release dosyasının henüz geçerli olmadığını söylüyor. Tam hata mesajı, ilgili depoyu ve ne kadar süre daha geçersiz kalacağını belirtir; örneğin is not valid yet (invalid for another 1d 2h 3min 4s). Sistem saatiniz, deponun Release dosyası içindeki tarihin gerisindedir ve belirtilen süre, saatinizin ne kadar geride olduğunun doğrudan bir ölçüsüdür. Saati düzeltin. Bu durumu aşmak için apt tarih kontrolünü devre dışı bırakmayın; çünkü bu kontrol, birinin size eski bir paket dizini sunmasını engelleyen mekanizmadır.

Her kaynak satırı ulaşılamaz durumunu gösteriyor ve Reach değeri 0. Hiçbir yanıt alınamıyor; bu durumda yapılandırmanızdan ziyade çıkış trafiğine (egress) odaklanın. NTP, UDP 123 numaralı port üzerinden dışarıya doğru çalışır ve bazı ağlar bu trafiği filtreler veya yönlendirir. sudo chronyc ntpdata, Total TX ve Total RX dahil olmak üzere kaynak bazlı sayaçları yazdırır. TX (gönderilen) sayısı artarken RX (alınan) sayısının sıfırda kalması, paketlerinizin çıktığını ancak yanıt gelmediğini gösterir; bu da sizinle kaynak arasında bir güvenlik duvarı olduğuna işaret eder.

Saat doğruydu ancak aniden değişti. Sunucu olayları buna neden olur. Geri yüklenen bir snapshot, duraklatılmış bir sanal makine veya başka bir sunucuya canlı taşıma (live migration), sanal makinenin zaman algısının geride kalmasına yol açabilir. chrony bir sonraki sorgulamada bunu fark eder ve düzeltir; systemd-timesyncd ise uzun bir sorgulama aralığının dolmasını bekleyebilir. Servisin açılışta başladığını systemctl is-enabled chrony ile doğrulayın; çünkü elle başlatılan bir daemon, bir sonraki yeniden başlatmadan sonra çalışmayacaktır.

Sapma küçük ancak bir türlü sabitlenmiyor. CPU steal değerini kontrol edin. Zamanlayıcı kesmesi (timer interrupt) geldiğinde çalıştırılmayan bir sanal makinede örneklemeler gecikir; bu nedenle sapma yakınsamak yerine dalgalanır. top, bunu CPU satırında st değeri olarak gösterir. Paylaşımlı bir sunucuda CPU steal süresini okuma başlıklı yazı, bu sayının ne anlama geldiğini ve neler yapabileceğinizi açıklar.

Yeni oluşturduğunuz bir sertifika henüz geçerli olmadığı gerekçesiyle reddediliyor. curl komutu SSL certificate problem: certificate is not yet valid çıktısını verir ve tarayıcılar benzer bir uyarı gösterir. Sertifika doğrudur; ancak sertifikayı kontrol eden sistemin saati geridedir. Hatalı olan her iki makine de olabilir, bu yüzden hem istemciyi hem de sunucuyu kontrol edin. Eğer sertifikayı oluşturan sunucunun saati yanlışsa, certbot ve nginx sertifika kılavuzu aynı kurulumun yenileme tarafını ele almaktadır.

Mevcut kontrollerinize ekleyin

Zaman eşitleme, aylar sonra sessizce başarısız olabilen bir önyükleme zamanı ayarıdır; bu, rutin kontrollerin yakaladığı ancak hafızanın gözden kaçırdığı türden bir durumdur. timedatectl ve chronyc tracking komutlarını birlikte okumak iki saniye sürer. Bunları yeni bir VPS üzerindeki ilk on dakika kapsamında ve düzenli Linux sunucu bakım kontrol listesi üzerinde çalışırken tekrar uygulayın. Kontrolün kendiliğinden çalışmasını ve sapma arttığında uyarı vermesini tercih ederseniz, bir systemd servisi ve zamanlayıcısı yazmak, belirli bir program dahilinde raporlama yapan küçük bir birim için gereken yapıyı kapsar. Bu tür bir kontrol, bir daemon yerine kısa bir betik olduğundan, varsayılan yerine Type=oneshot gerektirir ve systemd servis türlerinin özeti, yanlış türün neden hiç gerçekleşmemiş bir başarıyı raporlayan bir birimle sonuçlandığını açıklar.

FAQ

VPS saatimin senkronize olup olmadığını nasıl kontrol ederim?

timedatectl komutunu çalıştırın ve System clock synchronized satırını okuyun. Bu, saati düzenleyen daemon tarafından ayarlanan çekirdeğin kendi bayrağıdır; bu nedenle chrony kullanan bir makinede yes ile birlikte NTP service: n/a görülmesi normal ve sağlıklı bir durumdur. Hata payını görmek için chronyc tracking komutunu çalıştırıp System time çıktısını okuyun veya systemd-timesyncd devredeyse timedatectl timesync-status komutunu çalıştırıp Offset çıktısını inceleyin. Makine dışındaki bir kaynağa göre kontrol yapmak isterseniz, date -u çıktısını herhangi bir HTTPS sitesinden dönen Date başlığı ile karşılaştırın.

VPS üzerinde chrony mi yoksa systemd-timesyncd mi kullanmalıyım?

Önemli olan her şeyde chrony kullanın. systemd-timesyncd, tek bir sunucuyu takip eden bir SNTP istemcisidir ve sürekli çevrimiçi kalan, başlangıçta doğru zamana yakın olan makineler için yeterlidir. chrony ise birden fazla kaynağı sorgular, tutarsız olanları reddeder, saatinizin sapma oranını öğrenir ve bir ana makine duraklaması veya canlı taşıma (live migration) sonrasında hızla toparlanır. Debian veya Ubuntu üzerinde chrony kurmak, her iki paket de time-daemon sağladığı için systemd-timesyncd paketini otomatik olarak kaldırır. Asla aynı anda iki zaman daemon'ı çalıştırmayın.

TOTP kodlarım neden bir sunucuda çalışmıyor ama diğer her yerde çalışıyor?

Çünkü TOTP kodu, mevcut zamanın bir fonksiyonudur. Kod, her 30 saniyede bir ilerleyen bir sayaçtan gelir; bu nedenle sunucu ve telefonunuzun hangi adımda olunduğu konusunda mutabık kalması gerekir. Çoğu doğrulayıcı, her iki yönde yaklaşık yarım dakikalık bir esneklik sağlayan bir adımlık sapmayı kabul eder. O sunucuda timedatectl değerini kontrol edin. Eğer System clock synchronized çıktısı no değerini gösteriyorsa, senkronizasyonu düzeltin; paylaşılan gizli anahtarda (shared secret) herhangi bir değişiklik yapmanıza gerek kalmadan kodlar tekrar eşleşecektir.

Docker container içinde zamanı ayarlayabilir miyim?

Hayır, buna ihtiyacınız da yoktur. Bir container, ana makinenin CLOCK_REALTIME değerini paylaşır; çünkü Linux zaman isim alanları (time namespaces) yalnızca monotonik ve önyükleme zamanlı saatleri sanallaştırır. Ayrıcalıksız bir container date: cannot set date: Operation not permitted alır ve CAP_SYS_TIME eklemek, container'a kendi saatini vermek yerine ana makinenin saatini değiştirmesine izin verir. Bunun yerine ana makineyi senkronize edin. Container içinde farklı bir yerel zaman kullanımı, bir saat dilimi ayarıdır; bu nedenle container ortamında TZ değişkenini ayarlayın.

Bir sunucu UTC mi yoksa yerel zaman mı kullanmalı?

UTC kullanılmalıdır; yerel zaman ise çıktıyı bir kişi okuduğu noktada uygulanmalıdır. UTC, gün ışığından yararlanma uygulaması nedeniyle asla değişmez; bu sayede günlük bir görev yıl boyunca günde bir kez çalışır ve farklı sunuculardan gelen zaman damgaları herhangi bir dönüştürme gerektirmeden hizalanır. Bunu sudo timedatectl set-timezone UTC ile ayarlayın. Yerel zamanı görmek isteyen herkes, sistem saatinde hiçbir şeyi değiştirmeyen TZ=America/New_York date gibi bir komut ön eki kullanabilir.