Кто-нибудь видел, как Linux time застрял, он сводил меня с ума со вчерашнего дня.
# date
Thu Apr 2 16:35:04 UTC 2020
# date
Thu Apr 2 16:35:04 UTC 2020
# date
Thu Apr 2 16:35:04 UTC 2020
# date
Thu Apr 2 16:35:04 UTC 2020
Пока я зашел в servfault, был перерыв около 3 минут.
# date
Thu Apr 2 16:35:05 UTC 2020
RTC, кажется, тикает, это примерно десять тысяч:
# timedatectl
Local time: Thu 2020-04-02 16:35:06 UTC
Universal time: Thu 2020-04-02 16:35:06 UTC
RTC time: Thu 2020-04-02 16:42:36
Time zone: America/New_York (UTC, +0000)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
# timedatectl
Local time: Thu 2020-04-02 16:35:06 UTC
Universal time: Thu 2020-04-02 16:35:06 UTC
RTC time: Thu 2020-04-02 16:42:46
Time zone: America/New_York (UTC, +0000)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
# hwclock --show
Thu 02 Apr 2020 04:43:56 PM UTC -0.001834 seconds
# hwclock --show
Thu 02 Apr 2020 04:44:04 PM UTC -0.000916 seconds
Это также примерно десять секунд друг от друга:
# hwclock --hctosys
# date
Thu Apr 2 16:44:24 UTC 2020
# date
Thu Apr 2 16:44:24 UTC 2020
Попробуйте NTPd
# systemctl start ntpd
# date
Thu Apr 2 16:44:24 UTC 2020
# date
Thu Apr 2 16:44:24 UTC 2020
# date
Thu Apr 2 16:44:24 UTC 2020
# date
Thu Apr 2 16:44:24 UTC 2020
# systemctl status ntpd
● ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2020-04-02 16:44:24 UTC; 27ms ago
Process: 18008 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 18009 (ntpd)
CGroup: /system.slice/ntpd.service
└─18009 /usr/sbin/ntpd -u ntp:ntp -g
# ntpq
ntpq> lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
time.cloudflare .INIT. 16 u - 64 0 0.000 0.000 0.977
clock.sjc.he.ne .INIT. 16 u - 64 0 0.000 0.000 0.977
ntp4.doctor.com .INIT. 16 u - 64 0 0.000 0.000 0.977
tock.usshc.com .INIT. 16 u - 64 0 0.000 0.000 0.977
Он просто остается в .INIT. хотя коллеги доступны
# ping tock.usshc.com
PING tock.usshc.com (199.102.46.72) 56(84) bytes of data.
64 bytes from tock.usshc.com (199.102.46.72): icmp_seq=1 ttl=54 time=1.00 ms
Редактировать # 1
# grep . /sys/devices/system/clocksource/clocksource*/[ac]*_clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:tsc hpet acpi_pm refined-jiffies jiffies
/sys/devices/system/clocksource/clocksource0/current_clocksource:jiffies
# dmesg | grep clocksource
[ 0.000000] Command line: vmlinuz nomodeset rw selinux=0 enforcing=0 raid=noautodetect nmi_watchdog=0 LAUNCH_INIT=/tmp/SUTup rdshell console=tty0 console=ttyS0,9600n1 HOMEBASE=192.168.1.1 biosdevname=0 clocksource=jiffies nmi_watchdog=0 consoleblank=0 vga=791 ramdisk_size=4000000 initrd=initramfs
[ 0.000000] Kernel command line: vmlinuz nomodeset rw selinux=0 enforcing=0 raid=noautodetect nmi_watchdog=0 LAUNCH_INIT=/tmp/SUTup rdshell console=tty0 console=ttyS0,9600n1 HOMEBASE=192.168.1.1 biosdevname=0 clocksource=jiffies nmi_watchdog=0 consoleblank=0 vga=791 ramdisk_size=4000000 initrd=initramfs
[ 51.409031] tsc: Refined TSC clocksource calibration: 2394.374 MHz
Этот сервер получает действительно раздражает. Работающая ОС - это живой образ CentOS, обслуживаемый через PXE. Нет FakeTime.
Проверьте это: это должно занять ~ 2 секунды, но занимает в десять раз больше (работает через SSH, поэтому я получаю внешнее `` время '')
# time ssh 192.168.100.115 'for i in {0..1}; do date; sleep 1 ; done'
Thu Apr 2 23:39:22 UTC 2020
Thu Apr 2 23:39:23 UTC 2020
real 0m20.869s
user 0m0.026s
sys 0m0.007s
Нет брандмауэра, блокирующего NTP, это небольшая сеть. Это физический сервер Intel, а не виртуальная машина.
Редактировать # 2
Пол предложил проверить мой источник часов, это было мгновенно, переключился на hpet, и все начало работать; Не знаю, почему это работало до вчерашнего дня (я впервые заметил, что время застряло), мы годами использовали этот образ на всяком оборудовании.
Источник часов: https://access.redhat.com/solutions/18627
Ваши одноранговые узлы могут быть доступны с помощью ping, но недоступны для NTP, что важно для синхронизации часов. У вас может быть локальный, сетевой или брандмауэр уровня интернет-провайдера, блокирующий доступ.
Однако это не объясняет зависания системных часов. Помимо предложения Джона Маховальда, могут быть проблемы с гипервизором или прошивкой - это виртуальная машина или какое-то экзотическое оборудование?
Что показывают следующие команды?
grep . /sys/devices/system/clocksource/clocksource*/[ac]*_clocksource
dmesg | grep clocksource