clocksource: Marking clocksource unstable
Ядро следит за источником времени и при расхождении переключается на другой. Для служб это означает скачок показаний часов: таймеры могут сработать сразу или не сработать вовсе, а измерения длительности дают бессмысленные значения. Чаще всего встречается на виртуальных машинах.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Ненадёжный источник времени на виртуальной машине
Источник времени, видимый гостю, зависит от хоста. При нагрузке на хосте показания расходятся, и ядро переключается.
-
Таймеры срабатывают не по расписанию
Таймеры по календарю привязаны к показаниям часов. Скачок означает пропуск или немедленное срабатывание.
-
Синхронизация времени борется со скачками
Служба синхронизации подтягивает часы, и в журнале видны поправки. При нестабильном источнике это не заканчивается.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Действующий источник времени.
cat /sys/devices/system/clocksource/clocksource0/current_clocksourceПереключения источников времени.
journalctl -k -b --no-pager | grep -i clocksource | tailСостояние часов и синхронизации.
timedatectlРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Источник времени, видимый гостю, зависит от хоста. При нагрузке на хосте показания расходятся, и ядро переключается.
- Как проверить
-
Посмотрите текущий и доступные источники времени.
cat /sys/devices/system/clocksource/clocksource0/current_clocksource systemd-detect-virt
- Как исправить
- Выберите источник, рекомендованный для вашего гипервизора. Для виртуальных машин обычно это паравиртуальный источник.
- Почему происходит
- Таймеры по календарю привязаны к показаниям часов. Скачок означает пропуск или немедленное срабатывание.
- Как проверить
-
Посмотрите таймеры и время последнего срабатывания.
systemctl list-timers --all --no-pager | head timedatectl
- Как исправить
- Для устойчивости к скачкам времени используйте таймеры по времени работы вместо календарных там, где точный момент неважен.
- Почему происходит
- Служба синхронизации подтягивает часы, и в журнале видны поправки. При нестабильном источнике это не заканчивается.
- Как проверить
-
Посмотрите состояние синхронизации.
timedatectl show -p NTPSynchronized journalctl -u systemd-timesyncd -n 15 --no-pager 2>/dev/null | tail
- Как исправить
- Сначала стабилизируйте источник времени, потом настраивайте синхронизацию: иначе служба синхронизации бесконечно догоняет скачки.
Пример вывода
Источник времени признан ненадёжным на виртуальной машине. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
kernel: clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large:
kernel: clocksource: 'hpet' wd_nsec: 498112000 wd_now: 6a1c2f31
kernel: clocksource: Switched to clocksource hpetСвязанные ошибки
- Прыжок системного времени сбивает таймеры и сертификаты После синхронизации времени таймеры срабатывают не вовремя, а проверка сертификатов отказывает. Почему и что делать.
- Пропущенное срабатывание таймера: Persistent и выключенная машина Таймер не выполнил задачу, потому что в момент срабатывания машина была выключена или служба была недоступна. Как работает Persistent=true.
- Время не синхронизируется: chronyd или systemd-timesyncd Служба синхронизации времени работает, а время расходится: закрыт порт, конфликт двух служб, недоступны серверы.
- Служба синхронизации перевела часы скачком Время изменилось резко: расхождение было слишком велико для плавной подстройки. Последствия для таймеров и журнала.
- Таймер срабатывает позже указанного времени Задание запускается на минуту позже: по умолчанию таймеры группируются для экономии пробуждений.
- Elasticsearch: max virtual memory areas vm.max_map_count is too low Elasticsearch отказывается стартовать из-за заниженного vm.max_map_count. Как поднять значение и закрепить его.
- Failed to parse calendar expression: ошибка в OnCalendar systemd не разбирает календарное выражение таймера. Правила записи OnCalendar и проверка через systemd-analyze calendar.
- Function not implemented в контейнере Ошибка 38 при системном вызове: вызов запрещён фильтром или отсутствует в окружении. Разбор для контейнеров.
Где встречается чаще всего
Источники
- Документация ядра: источники времени
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Наблюдалось на виртуальной машине под нагрузкой хоста.