Linux sistem zamanı geçici olarak atlıyor

Bazı (donanım) sunucularda garip bir sistem zamanı değiştirme davranışı gördüm: içinde /var/logs/syslog, her günlük mesajından önceki tarih zamanı bazen rastgele bire dönüşür ve bir sonraki mesajda aşağıdaki gibi normale döner:

Feb 22 2018 09:09:30 ...  
Feb 22 2018 09:09:32 ...  
Jan 13 2610 15:37:42 ...  
Feb 22 2018 09:09:33 ...  
Feb 22 2018 09:09:34 ...  

Örnekte olduğu gibi, tarih saatindeki ani değişiklik yüzlerce yıl kadar uzakta olabilir.

Garip zaman damgalarına sahip günlük mesajlarının belirli bir işlemden gelmediğini onaylayabilirim - her biri için rastgele olabilir.

Ve 2 anormal zaman değişikliği arasındaki süre birkaç dakika ila birkaç saat arasında değişir (ancak, anormal zaman değişikliklerinin daha sık olabileceğinden şüphelenirim, ancak çoğu saniyede günlük yazmadığı için sistem günlüğünde açığa çıkmaz).

Ayrıca, birden fazla sunucuda gerçekleştiğinden, bunun bir donanım sorunu olmadığını varsayıyorum.

Severs hakkında daha fazla bilgi: bir denetleyici ve birkaç işlem düğümü ile bir opentack kurulumudur. Her sunucuda ntp hizmeti çalışıyor. Denetleyici kendi donanım saatinden zaman alacak şekilde yapılandırılır ve hesaplama düğümü sunucuları denetleyiciden zamanı eşitler. Her sunucunun kendi hızında anormal zaman değişiklikleri olduğuna dikkat edin - "yanlış zaman" denetleyiciden ntp aracılığıyla senkronize edilmemiş gibi görünüyor.

Bilgi işlem düğümlerindeki konuk sistemlerin (sanal makineler) ana sistem zamanını etkileyebileceğinden şüpheleniyordum. Ancak bu, herhangi bir sanal makine çalıştırmıyorken denetleyicinin neden aynı sorunu yaşadığını açıklayamaz.

Algılamak için bir yönteme ihtiyacım var: Sistem saatini kim değiştirdi ve nasıl oluyor?

İlgili yönler, çekirdek sürümleridir ve önyükleme işleminin başlarındaki şu satırlardır:

kernel: Fast TSC calibration using PIT
...
kernel: Calibrating delay loop (skipped), value calculated using timer frequency..
...
kernel: Switching to clocksource tsc

YMMV ve TSC veya PIT kullanmıyor olabilirsiniz

AFAIK, CPU'larınızdan en az birinin senkronize olmama saatinin neden olduğu bir hatadır, büyük olasılıkla çok hızlı çalışır.

Bunu çalıştırarak onaylamak kolay olmalıdır:

for cpu in {0..8} ; do taskset -c $cpu date ; done

çalışacağı dateher cpu karşı (bu 8 çekirdek / parçacığı kadar olduğu varsayıldığında). Tahminim doğruysa, CPU'larınızdan biri sürekli olarak yanlış zamana sahip olacaktır.

Bu durumda, önce çekirdeği yükseltmeyi denemelisiniz ve bu işe yaramazsa, clocksource boot parametresiyle (varsayalım) kemanlayın x86-64:

clocksource=    Override the default clocksource
                Format: <string>
                Override the default clocksource and use the clocksource
                with the name specified.
                Some clocksource names to choose from, depending on
                the platform:
                [all] jiffies (this is the base, fallback clocksource)
                [ACPI] acpi_pm
                ...
                [X86-64] hpet,tsc

Bunun çıktısına da bakınız:

cat /sys/devices/system/clocksource/clocksource*/available_clocksource

Kontrolör sunucunuzdaki donanım saati, zaman hakkında sabit bir bilgi kaynağı değil gibi görünüyor. Kontrol cihazınızı tipini daha güvenilir atom saati ile senkronize edecek şekilde yapılandırmalısınız.

Donanım saatinizi güncellemek için kullanabileceğiniz komut budur: hwclock -s

Ayrıca bakınız:

   -s, --hctosys
          Set the System Time from the Hardware Clock.

          Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them.  The obsolete tz_dsttime field of the kernel's time‐
          zone value is set to DST_NONE.  (For details on what this field used to mean, see settimeofday(2).)

          This is a good option to use in one of the system startup scripts.

   -w, --systohc
          Set the Hardware Clock to the current System Time.

kopyalandığı yer: syslog dosyasında keyfi olarak uzun süre geciktirilen CRON iletileri :

Kısacası, ben kullanıyorum rsyslog sürümünde keyfi bir süre için aldığı syslog mesajını geciktirecek bir hata var. Hata raporu burada. Ve rsyslog'u yükseltmek sorunu çözdü. CRON'un hatası değildir.

Bu tür anormallikleri önlemek için katman 1 veya 2 kaynağına senkronize edilmiş harici bir NTP sunucusu kullanmalısınız. Donanım saatleri güvenilir değildir.