เวลาของระบบ Linux ข้ามไปชั่วขณะ

ฉันเห็นพฤติกรรมแปลก ๆ ของการเปลี่ยนเวลาของระบบในเซิร์ฟเวอร์ (ฮาร์ดแวร์) บางตัว: ใน/var/logs/syslog, วันเวลาที่นำหน้าแต่ละข้อความบันทึกบางครั้งเปลี่ยนเป็นแบบสุ่มและกลับมาเป็นปกติในข้อความถัดไปเช่น:

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

เช่นในตัวอย่างการเปลี่ยนวันที่อย่างกะทันหันสามารถทำได้ไกลหลายร้อยปี

ฉันสามารถยืนยันได้ว่าข้อความบันทึกที่มีการประทับเวลาแปลก ๆ ไม่ได้มาจากกระบวนการเฉพาะ - มันสามารถเกิดขึ้นแบบสุ่มสำหรับทุกคน

และระยะเวลาระหว่างการเปลี่ยนแปลงเวลาที่ผิดปกติ 2 ครั้งจะแตกต่างกันไประหว่างสองสามนาทีถึงสองสามชั่วโมง (แต่ฉันสงสัยว่าการเปลี่ยนแปลงเวลาผิดปกติอาจเกิดขึ้นบ่อยครั้ง แต่พวกเขาส่วนใหญ่ไม่ได้เปิดเผยใน syslog

นอกจากนี้เนื่องจากมันเกิดขึ้นบนเซิร์ฟเวอร์มากกว่าหนึ่งเครื่องฉันคิดว่ามันไม่ใช่ปัญหาฮาร์ดแวร์

ข้อมูลเพิ่มเติมเกี่ยวกับ severs: เป็นการติดตั้ง openstack ที่มีคอนโทรลเลอร์หนึ่งตัวและโหนดการคำนวณสองสามตัว แต่ละเซิร์ฟเวอร์มีบริการ ntp ที่ทำงานอยู่ คอนโทรลเลอร์ได้รับการกำหนดค่าให้ใช้เวลาจากนาฬิกาฮาร์ดแวร์ของตนเองและเซิร์ฟเวอร์การคำนวณโหนดซิงค์เวลาจากคอนโทรลเลอร์ โปรดทราบว่าเซิร์ฟเวอร์แต่ละเครื่องมีการเปลี่ยนแปลงเวลาที่ผิดปกติตามจังหวะของตัวเอง - ดูเหมือนว่า "เวลาไม่ถูกต้อง" จะไม่ถูกซิงโครไนซ์จากคอนโทรลเลอร์ผ่าน ntp

ฉันสงสัยระบบแขก (เครื่องเสมือน) ในการคำนวณโหนดอาจส่งผลกระทบต่อเวลาระบบโฮสต์ของพวกเขา แต่นี่ไม่สามารถอธิบายได้ว่าทำไมคอนโทรลเลอร์มีปัญหาเดียวกันในขณะที่ไม่ได้ใช้งานเครื่องเสมือน

ฉันต้องการวิธีการตรวจสอบ: ใครเปลี่ยนเวลาของระบบและมันเกิดขึ้นได้อย่างไร

ลักษณะที่เกี่ยวข้องคือเคอร์เนลเวอร์ชันและบรรทัดเหล่านี้มาตั้งแต่ต้นในกระบวนการบูต:

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

YMMV และคุณอาจไม่ได้ใช้ TSC หรือ PIT

AFAIK นี่เป็นข้อผิดพลาดที่เกิดจากนาฬิกาอย่างน้อยหนึ่ง CPU ของคุณไม่ซิงค์ในกรณีของคุณอาจทำงานเร็วเกินไป

การยืนยันด้วยวิธีนี้ทำได้ง่าย:

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

ซึ่งจะทำงานdateกับ cpu แต่ละตัว (สมมติว่าคุณมีได้ถึง 8 คอร์ / เธรด) ถ้าฉันเดาถูกต้องแล้วหนึ่งในซีพียูของคุณจะมีเวลาผิดปกติ

หากเป็นกรณีนี้คุณควรลองอัปเกรดเคอร์เนลก่อนและหากไม่สามารถใช้งานได้ให้ลองเล่นกับพารามิเตอร์การบูตของนาฬิกาแหล่งที่มา (สมมติว่าเป็น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

ดูผลลัพธ์ของสิ่งนี้:

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

ดูเหมือนว่านาฬิกาฮาร์ดแวร์บนเซิร์ฟเวอร์คอนโทรลเลอร์ของคุณไม่ใช่แหล่งข้อมูลที่มีเสถียรภาพเกี่ยวกับเวลา คุณควรกำหนดค่าคอนโทรลเลอร์ให้ซิงค์ประเภทมันกับนาฬิกาอะตอมที่เชื่อถือได้มากขึ้น

นี่คือคำสั่งที่คุณสามารถใช้เพื่ออัพเดตนาฬิกาฮาร์ดแวร์ของคุณ: hwclock -s

ดูสิ่งนี้ด้วย:

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

คัดลอกจาก: ข้อความ CRON จะล่าช้าเป็นเวลานานใน syslog :

กล่าวโดยย่อมีข้อผิดพลาดในเวอร์ชันของ rsyslog ที่ฉันใช้ซึ่งจะชะลอข้อความ syslog ที่ได้รับตามระยะเวลาที่กำหนด รายงานข้อผิดพลาดอยู่ที่นี่ และการอัพเกรด rsyslog แก้ปัญหาได้ มันไม่ใช่ความผิดของ CRON

คุณควรใช้เซิร์ฟเวอร์ NTP ภายนอกที่ซิงโครไนซ์กับแหล่ง stratum 1 หรือ 2 เพื่อหลีกเลี่ยงความผิดปกติดังกล่าว นาฬิกาฮาร์ดแวร์ไม่น่าเชื่อถือ