VPS saati neden geri kalır 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 yavaş çalışan bir donanım sayacından hesaplar; bir zaman eşitleme istemcisi çalışmadığında, bu küçük hata her saat başı büyür. Sanal makine içinde ikinci bir neden daha vardır: konuk sistem, fiziksel işlemciyi diğer konuklarla paylaşır; dolayısıyla işlemcinin atanmadığı anlar, zamanın sayılamadığı anlardır.

Güncel bir KVM konuğunda sayacın kendisi nadiren asıl sorundur. Paravirtual kvm-clock 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 hatalı olan saatler genellikle daha basit bir nedenden dolayı hatalıdır. Hiçbir eşitleme servisi (daemon) çalışmıyordur, iki servis aynı anda çalışıp çakışıyordur veya 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 parola) iki faktörlü doğrulama kodları eşleşmeyi durdurur; bu nedenle parola ve anahtar doğru olsa bile 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 yüzden bir olay zaman çizelgesi tahminlere dayalı olarak oluşturulmak zorunda kalır.

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

[
  {
    "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 çok daha esnektir ve varsayılan sapma payı 300 saniyedir. Bir sertifika ise hiç esnek değildir: 0 saniyelik bir müsamaha süresiyle sabit anlara göre kontrol edilir; dolayısıyla bir saniye ileride olan bir saat, tamamen geçerli bir sertifikayı reddeder.

Üç saat ve hangisinin önemli olduğu

Sistem saati, önemli olan saattir. Bu, ç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 saatinin 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 sanal makine (guest) içinde ise hipervizör tarafından taklit edilir, bu nedenle büyük ölçüde ana makineye (host) ait bir yapıdır. Linux, başlangıç değeri olarak bunu açılışta bir kez okur, ardından kendi sayacını tutar. timedatectl, bunu 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 yüzden hwclock --show komutu hwclock: Cannot access the Hardware Clock via any known method. hatasıyla başarısız olur.

Clocksource, çekirdeğin bu okumalar arasında neyle sayım yapacağını belirler. Ç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 nedenle NTP istemcisi olmayan bir KVM sanal makinesi bile bir süre boyunca yaklaşık olarak doğru zamanda kalır. tsc, işlemcinin kendi sayacıdır. Xen sanal makineleri xen, Hyper-V sanal makineleri ise hyperv kaynağını rapor eder. Ölçülebilir bir nedeniniz olmadıkça bu ayarı değiştirmeyin; çünkü çekirdek, o donanım üzerinde güvendiği en iyi kaynağı zaten otomatik olarak seçer.

Bazı ana makineler, sanal makineye 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'lerde 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ırması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, "bu 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 saatine ayarlıdır.
• RTC time, yukarıda açıklanan donanım saatidir. Bir VPS üzerinde çalışıyorsanız bunu dikkate almayın.
• 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; dolayısıyla no, sistem açılışından beri saatin hiçbir şekilde düzenlenmediği anlamına gelir.
• NTP service, özellikle systemd-timesyncd hakkındaki raporu sunar. 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 bu zaman bilgisiyle uyumlu olduğunu gösterir.

Ardından, ne kadar sapma olduğunu sorgulayın. Telefonunuzla kıyaslayarak göz kararı tahmin yapmayın. Eğer chrony çalışıyorsa:

chronyc tracking
chronyc sources -v

chronyc tracking, sorunun cevabını veren sayıları yazdırır. System time, NTP zamanına göre 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 değeri Normal olmalıdır. 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. İki sütun anlamın büyük kısmını taşır. Her satırın başındaki durum karakteri, chrony'nin o kaynağı nasıl değerlendirdiğ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 yönetim systemd-timesyncd'de ise:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status, iletişim kurduğu sunucuyu, sorgu 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 sorumlu daemon timesyncd değildir; bu durum zaten sorunuzun cevabıdır.

Ek araçlar kullanmadan dış dünya ile kaba bir kontrol yapmak için saatinizi, GMT cinsinden bir saniyelik çözünürlükle sunulan halka açık 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 sorun teşkil 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 sistem saatini o sunucuya göre ayarlar. Sürekli çevrimiçi olan ve başlangıçta yaklaşık olarak doğru bir saate sahip makineler için bu yeterlidir ve neredeyse hiç kaynak tüketmez.

chrony, tam kapsamlı bir NTP uygulamasıdır ve kendi çıktısında da görülebileceği nedenlerden dolayı sanal makineler için daha iyi bir varsayılan tercihtir. Birden fazla kaynağı aynı anda sorgular ve tutarsız olanları eler. Sistem saatinizin hata oranını ölçer ve bunu bir drift dosyasına yazar; böylece saati her örneklemede düzeltmek yerine, saatin sapma eğilimini kalıcı olarak düzeltir. Ayrıca, fiziksel sunucuların aksine sanal makinelerin yaşadığı iki duruma karşı hızlıca toparlanır: ana makine tarafından duraklatılabilmesi ve çalışırken farklı bir ana makineye taşınabilmesi. 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ğladığı için, apt chrony'yi kurarken timesyncd'yi kaldırır. Bu beklenen ve doğru bir davranıştır. İkisini asla aynı anda çalıştırmayın; aynı saati ayarlamaya çalışan iki daemon çakışacaktır ve bu durumda rapor edilen sapma değerlerinin hiçbiri güvenilir olmaz. Rocky ve AlmaLinux üzerinde kurulumu sudo dnf install -y chrony ile 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 geçerli bir nedeniniz yoksa değiştirmeyin. İki yönergeyi anlamak faydalıdı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 kademeli olarak düzelteceğine (slew) veya doğrudan atlatacağına (step) karar verir. Mevcut 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, saat farkı bir saniyeden fazlaysa saati doğrudan atlat (step), sonrasında ise sadece kademeli düzeltme (slew) yap.

Zaman trafiğinin yol üzerindeki müdahalelere karşı doğrulanmasını istiyorsanız, chrony 4 ve sonraki sürümler 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, zaman daemon'ınızın hiç çalışmamasına neden olur ve sistem saati size bu konuda bir uyarı vermez.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

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

Bir zaman daemon'ı, bir sapmayı düzeltmek için iki yola sahiptir. "Slewing" (yavaşlatma/hızlandırma), hata giderilene kadar saati hızlandırır veya yavaşlatır; bu yöntem zamanın ileriye doğru akmasını sağlar ve hiçbir zaman zaman damgasını tekrarlamaz veya atlamaz. "Stepping" (atlama) ise doğrudan doğru değere sıçrar; bu yöntem hızlıdır ancak saati geriye alabilir. Zamanı duvar saatinden ölçen herhangi bir sistem için geriye doğru gitmek tehlikelidir, bu nedenle her iki daemon da slewing yöntemini tercih eder.

Bu tercih, ciddi şekilde hatalı bir saatin uzun süre hatalı kalmasının nedenidir. chrony, yalnızca makestep tarafından izin verilen aralıkta atlama yapar; bu da varsayılan olarak daemon başlatıldıktan sonraki ilk birkaç güncellemedir. Bir haftadır çalışan ve ardından kırk saniyelik bir hata tespit eden chronyd, bu hatayı slewing ile düzeltmeye çalışır ve kırk saniyelik bir sapmayı slewing ile düzeltmek, beklemek isteyeceğinizden çok daha uzun sürer. Bunu sakin bir anda, bilinçli olarak bir kez 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. Bunu yoğun bir veritabanı sunucusunda çalıştırmadan önce düşünün; çünkü geriye doğru atlayan bir saat, zamanın yalnızca ileriye doğru aktığını varsayan yazılımların kafasını karıştırabilir. Daemon'ı yeniden başlatmak, aynı düzeltmenin daha yumuşak bir versiyonudur, çünkü makestep penceresi başlangıçta tekrar açılır.

Konteynerler ana makinenin saatini paylaşır

Bir konteynerin 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 konteynerin üzerinde çalıştığı ana makine ile aynı sistem saatini okuduğu anlamına gelir. Ana makinedeki saati düzelttiğinizde, o makinedeki tüm konteynerlerin 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 yaramazlar. Ayrıcalıksız (unprivileged) bir konteynerin 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 yetkisi vermek konteynere özel bir saat sağlamaz; aksine konteynere ana makinenin saatini ve dolayısıyla diğer tüm konteynerlerin saatini değiştirme yetkisi verir.

Konteyner içindeki farklı bir saat dilimi bir saat sorunu değildir. Kendi /etc/localtime dosyasını taşıyan bir imaj, aynı anı başka bir dilime göre biçimlendirerek yazdırır; bu nedenle date yanlış görünürken saat aslında doğrudur. Konteyner ortamında TZ=UTC değişkenini ayarladığınızda bu karışıklık ortadan kalkar. Seçtiğiniz çalışma zamanı (runtime) bu konuda 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; tüm mesele bundan ibarettir. Yaz saati uygulanan bir zaman diliminde 02:30'da çalışan günlük bir görev, 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 görevler değişimden hemen sonra çalıştırılır, geri atlama nedeniyle tekrarlanan bir saat dilimine denk gelen görevler ise ikinci kez çalıştırılmaz. Bu davranış mantıklıdır ancak yine de saat 03:00'te üzerinde kafa yormanız gereken bir durum olmamalıdır. UTC altında görev, yılın her günü, günde bir kez çalışır. Eğer bir göreviniz tuhaf bir saatte çalışmak yerine tamamen kayboluyorsa, bir cron görevinin 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 zaman diliminde biçimlendirir, journalctl --utc ise UTC kullanımını zorunlu kılar. Farklı zaman dilimlerindeki 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 insanların zaman çizelgesini yanlış okumasına neden olur. Sistemleri UTC'de tutun, zaman damgalarını UTC olarak saklayın ve dönüştürmeyi yalnızca bir insan okuyacağı noktada 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, no şeklinde okunmalıdır. Bunu "yes" olarak ayarlamak, bir dizüstü bilgisayarda Windows ile dual-boot yapıyorsanız bir geçici çözümdür; sunucuda ise yalnızca daha sonra birinin hata yapmasına neden olacak bir sapma ekler. Bu ayar yapıldığında, timedatectl sistemin RTC saatini yerel zaman 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 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 değerini gösterecek veya chronyc tracking komutu 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 publickey 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ı belirtiyor. Tam hata mesajı, ilgili depoyu ve dosyanın ne kadar süre daha geçersiz kalacağını (örneğin is not valid yet (invalid for another 1d 2h 3min 4s)) belirtir. 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 güvenlik önlemidir.

Her kaynak satırı ulaşılamaz durumunu gösteriyor ve Reach değeri 0. Hiçbir yanıt alınamıyorsa, yapılandırmanızdan ziyade çıkış trafiğine (egress) odaklanın. NTP, UDP 123 numaralı portu üzerinden dışarıya doğru çalışır ve bazı ağlar bu trafiği filtreler veya yönlendirir. sudo chronyc ntpdata komutu, Total TX ve Total RX dahil olmak üzere kaynak bazlı sayaçları yazdırır. TX sayacı artarken RX sayacı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 olabilir. 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 yoklamada bunu fark eder ve düzeltir; systemd-timesyncd ise uzun bir yoklama aralığının dolmasını bekleyebilir. Servisin açılışta başladığından systemctl is-enabled chrony ile emin olun; çünkü elle başlatılan bir daemon, bir sonraki yeniden başlatma sonrasında çalışmayacaktır.

Sapma küçük ancak bir türlü sabitlenmiyor. CPU steal değerini kontrol edin. Zamanlayıcı kesmesi (timer interrupt) geldiğinde zamanlanamayan bir sanal makine, örneklemelerin gecikmesine neden olur; bu yüzden sapma yakınsamak yerine dalgalanır. top komutu 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 bu konuda neler yapılabileceğini 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 sistem saati geridedir. Hatalı saat her iki makinede de olabilir, bu yüzden hem istemciyi hem de sunucuyu kontrol edin. 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, önyükleme anında yapılan ve aylar sonra sessizce başarısız olabilen bir ayardır; bu durum, rutin kontrollerin yakaladığı ancak hafızanın gözden kaçırdığı türden bir sorundur. timedatectl ve chronyc tracking komutlarını okumak iki saniye sürer. Bu komutları yeni bir VPS üzerindeki ilk on dakika sürecinin bir parçası olarak çalıştırın 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 konusu, belirli bir program dahilinde raporlama yapan küçük bir birim oluşturma yöntemini 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 arka plan süreci tarafından ayarlanan çekirdeğin kendi bayrağıdır; bu nedenle chrony kullanılan 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 değerini okuyun veya systemd-timesyncd kullanılıyorsa timedatectl timesync-status komutunu çalıştırıp Offset değerini kontrol edin. Makine dışındaki bir kaynakla karşılaştırma yapmak için date -u çıktısını, herhangi bir HTTPS sitesinden dönen Date başlığı ile kıyaslayın.

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

Önemli olan her sistemde chrony kullanın. systemd-timesyncd, tek bir sunucuyu takip eden bir SNTP istemcisidir; sürekli çevrimiçi kalan ve başlangıçta doğru zamana yakın olan makineler için yeterlidir. chrony ise birden fazla kaynağı sorgular, uyumsuz 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 kurulumu, her iki paket de time-daemon sağladığı için systemd-timesyncd paketini otomatik olarak kaldırır. Asla aynı anda iki zaman arka plan sürecini çalıştırmayın.

TOTP kodlarım neden bir sunucuda çalışmıyor ama diğerlerinde çalışıyor?

Çünkü TOTP kodu, o anki 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 komutunu kontrol edin. Eğer System clock synchronized çıktısı no değerini gösteriyorsa, senkronizasyonu düzeltin; paylaşılan gizli anahtarda 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; CAP_SYS_TIME eklemek ise container'a kendi saatini vermek yerine ana makinenin saatini değiştirme yetkisi verir. Bunun yerine ana makineyi senkronize edin. Container içinde farklı bir yerel zaman ihtiyacı 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ı okuyan kişi tarafından uygulanmalıdır. UTC, gün ışığından yararlanma uygulaması nedeniyle 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. Zamanı sudo timedatectl set-timezone UTC ile ayarlayın. Yerel zamanı görmek isteyen herkes, sistem saatinde hiçbir değişiklik yapmadan, örneğin TZ=America/New_York date gibi bir komutun başına ilgili değişkeni ekleyerek bunu yapabilir.