Иногда бывает, что системное время на серверах под управлением FreeBSD сильно "убегает" вперед, и даже запуск ntpd [1] не помогает: часы "прыгают" вперед на слишком большое значение, 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 |
После этих манипуляций проблема с "убеганием" системных часов должна исчезнуть.