Иногда бывает, что системное время на серверах под управлением FreeBSD сильно "убегает" вперед, и даже запуск ntpd не помогает: часы "прыгают" вперед на слишком большое значение, ntpd не справляется и "вылетает".
Вот пример работы ntpd c неработающим системным таймером:
# ntpq -c peers remote refid st t when poll reach delay offset jitter ============================================================================== shtucer.tntu.ed 31.28.161.68 2 u 116 256 377 10.064 -119986 785496. ntp.ethno.ua 193.190.230.65 2 u 101 256 377 1.292 -119985 785495. 194.54.80.28 (2 213.231.5.165 2 u 207 256 377 10.431 -119985 785495. ntp.time.in.ua .GPS. 1 u 107 256 377 1.335 -119985 785496. |
"Лечить" эту проблему можно запуском ntpdate вручную или через cron, но это не есть хорошее решение. Кстати, если эта проблема и появлялась, то обычно это были i386 системы.
Вот и в моем случае, после обновления с 9.1 на 9.3 вылезла данная проблема:
# uname -srm |
Все дело в некоректно работающем системном таймере. Их несколько в системе, и FreeBSD выбирает таймер с наибольшим значением качества. Проверим, какие системные таймеры присутствуют в системе:
# sysctl kern.timecounter.choice kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) i8254(0) dummy(-1000000) |
Теперь проверим, какой таймер выбран системой:
# sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast |
Это может быть неработающий таймер ACPI. В системе присутствует таймер i8254, укажем системе использовать именно этот таймер:
# sysctl kern.timecounter.hardware=i8254 |
Чтобы изменение системного таймера вступало в силу после перезагрузки, внесем необходимые правки в sysctl.conf:
# echo 'kern.timecounter.hardware=i8254' >> /etc/sysctl.conf |
После этих манипуляций проблема с "убеганием" системных часов должна исчезнуть.
Последние комментарии
11 недель 3 дня назад
35 недель 4 дня назад
2 года 36 недель назад
3 года 6 недель назад
3 года 29 недель назад
3 года 44 недели назад
3 года 45 недель назад
3 года 48 недель назад
4 года 7 недель назад
4 года 11 недель назад