Waktu sistem Linux untuk sementara melonjak

Saya melihat perilaku waktu sistem berubah aneh di beberapa server (perangkat keras): di /var/logs/syslog, waktu tanggal sebelum setiap pesan log kadang-kadang berubah menjadi acak dan kembali normal di pesan berikutnya, seperti berikut:

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 ...  

Seperti dalam contoh, perubahan waktu tanggal yang tiba-tiba bisa sejauh ratusan tahun lagi.

Saya dapat mengkonfirmasi bahwa pesan log yang memiliki prangko waktu yang aneh tidak berasal dari proses tertentu - itu hanya dapat terjadi secara acak untuk setiap orang.

Dan durasi antara 2 perubahan waktu abnormal bervariasi antara beberapa menit hingga beberapa jam (namun, saya menduga perubahan waktu abnormal dapat terjadi lebih sering tetapi banyak dari mereka tidak terungkap dalam syslog, karena tidak menulis log setiap detik).

Juga, karena itu terjadi pada lebih dari satu server, saya menganggap itu bukan masalah perangkat keras.

Info lebih lanjut tentang severs: mereka adalah instalasi openstack dengan satu controller dan beberapa node komputasi. Setiap server memiliki layanan ntp berjalan. Pengontrol dikonfigurasikan untuk mengambil waktu dari jam perangkat kerasnya sendiri, dan server simpul menghitung waktu sinkronisasi dari pengontrol. Perhatikan bahwa setiap server memiliki perubahan waktu abnormal dengan kecepatannya sendiri - sepertinya "waktu yang salah" tidak disinkronkan dari controller melalui ntp.

Saya mencurigai sistem tamu (mesin virtual) pada node komputasi dapat mempengaruhi waktu sistem host mereka. Tapi ini tidak bisa menjelaskan mengapa controller memiliki masalah yang sama saat tidak menjalankan mesin virtual.

Saya perlu metode untuk mendeteksi: siapa yang mengubah waktu sistem dan bagaimana itu terjadi?

Aspek yang relevan adalah versi kernel dan baris-baris ini dari awal proses boot:

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

YMMV dan Anda mungkin tidak menggunakan TSC atau PIT

AFAIK ini adalah bug yang disebabkan oleh jam setidaknya salah satu CPU Anda tidak sinkron, dalam kasus Anda mungkin berjalan terlalu cepat.

Seharusnya mudah untuk mengonfirmasi dengan menjalankan ini:

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

yang akan berjalan datemelawan masing-masing cpu (dengan asumsi Anda memiliki hingga 8 core / utas). Jika tebakan saya benar maka salah satu CPU Anda akan secara konsisten memiliki waktu yang salah.

Jika itu masalahnya maka Anda harus terlebih dahulu mencoba memutakhirkan kernel dan jika itu tidak berhasil, bermain-main dengan parameter boot clocksource (dengan asumsi itu 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

Lihat juga output dari ini:

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

Sepertinya jam perangkat keras pada server pengontrol Anda bukan sumber informasi yang stabil tentang waktu. Anda harus mengonfigurasi pengontrol Anda untuk menyinkronkan tipenya dengan jam atom yang lebih andal.

Ini adalah perintah yang dapat Anda gunakan untuk memperbarui jam perangkat keras Anda: hwclock -s

Lihat juga:

   -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.

disalin dari: pesan CRON ditunda untuk waktu lama di syslog :

Singkatnya, ada bug dalam versi rsyslog yang saya gunakan, yang akan menunda pesan syslog yang diterima untuk jangka waktu yang sewenang-wenang. Laporan bug ada di sini. Dan meningkatkan rsyslog memecahkan masalah. Itu bukan kesalahan CRON.

Anda harus menggunakan server NTP eksternal yang disinkronkan ke sumber strata 1 atau 2 untuk menghindari anomali semacam itu. Jam perangkat keras tidak dapat diandalkan.