waktu sistem linux sementara melompat

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

22 Februari 2018 09:09:30 ...
22 Februari 2018 09:09:32 ...
13 Jan 2610 15:37:42 ...
22 Februari 2018 09:09:33 ...
22 Februari 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?

— Zhaohui Yang
sumber

Bisakah Anda menunjukkan output dari hwclockloop? Sesuatu seperti:while true; do hwclock; sleep 5; done

— shodanshok

setiap server memiliki layanan ntp yang berjalan: sebagai klien atau sebagai server? via systemd atau di luar systemd melalui layanan ntp "lama"? bagi saya ini sepertinya menyediakan waktu masalah ntp. kami memiliki masalah ini bahwa kami memang menulis file log sebelum waktu kami disinkronkan (sebelum memiliki konektivitas jaringan, menghasilkan lompatan cap waktu) systemd memiliki target yang mungkin ingin Anda andalkan pada systemd [1]: Waktu telah diubah systemd [1]: Target yang tercapai, Waktu Sistem Disinkronkan.

— Dennis Nolte

sepertinya beberapa pengambilan tanggal berjalan sebagai cron dan tidak memiliki waktu pemeriksaan yang sangat baik. Temukan, hapus dan ganti dengan ntpd yang tidak merespons drift waktu besar.

— danblack

Kami memiliki temuan baru dan menemukan masalahnya dapat dipersempit menjadi pesan CRON tertunda di syslog. Jadi saya memposting pertanyaan lain . Silakan lihat di sana.

— Zhaohui Yang

Mungkin ini adalah kesalahan Anda: Lompatan waktu yang tidak dapat dijelaskan dalam CRON ditambal dalam rsyslog - 7.4.4-1ubuntu2.7 .

— Batu

Jawaban:

Script ini akan memberi tahu Anda ketika penyimpangan waktu terjadi dan perbedaan dalam pohon proses, dan ini akan membantu mengidentifikasi ini jika disebabkan oleh proses mengubah waktu sistem. Ini akan mencetak ke terminal serta masuk ke timedrift.log di dalam direktori kerja saat ini.

#!/bin/bash

oldTime="$(date +%s)"
oldPsOutput="$(ps faux)"
while true; do
  sleep 1;
  currentTime="$(date +%s)"
  oldTimeplusfive="$((($oldTime+5)))"
  currentPsOutput="$(ps faux)"
  if [[ "$currentTime" -lt "$oldTime" ||  "$currentTime" -gt "$oldTimeplusfive"  ]]
  then
    (
        echo -e '\n\n======================='
        echo "currentTime=$currentTime oldTime=$oldTime oldTimeplusfive=$oldTimeplusfive"
        echo '-----------------------'
        echo "$oldPsOutput"
        echo '::::::::::::::::::::::::::'
        echo "$currentPsOutput"
    ) | tee -a timedrift.log
  fi
  oldPsOutput=$currentPsOutput
  oldTime=$currentTime
done

Kredit untuk skrip asli dalam waktu Unexplainable melompat di bug CRON yang disebutkan Stone sebagai komentar.

Bisakah Anda juga berkomentar seolah-olah Anda menggunakan rsyslog dan jika demikian, versi apa? Apakah Anda melihatnya di luar ranah rsyslog (mis. Apache logs, dll). Bug ini terlihat simmlar, dan akan lebih baik untuk mengonfirmasi atau mengesampingkannya.

— Warga Negara Kepler
sumber

Sebenarnya ini adalah duplikat dari komentar @Stone. Jelaskan kepada semua orang bahwa ini memiliki jawaban.

Singkatnya, ada bug di 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. Ini bukan kesalahan kernel atau CRON.

— Zhaohui Yang
sumber