Вопросы Теги

Сумасшедший дрейф часов на древней ВМ

Я исправил проблему!!Я переключился с использования GDM3 на LightDM, перезагрузился, и у меня больше не было проблемы с невозможностью подключения к внешним мониторам. Я тестировал внешние мониторы DisplayPort и HDMI. Это также решило проблему, с которой я столкнулся, когда внешние мониторы не распознавались как жизнеспособные аудиоприемники, поэтому теперь я также вывожу звук со своих внешних мониторов без разрывов экрана:)

Чтобы переключиться с GDM3 (, который является диспетчером дисплея по умолчанию, начиная с Ubuntu 17.10 ), на LightDM, я просто запустил sudo apt install lightdm, потому что он еще не был установлен, и мне было предложено выбрать, какой дисплей менеджер по умолчанию.

Если он у вас уже установлен, при запуске sudo dpkg-reconfigure gdm3вы увидите такое же приглашение.

Я надеюсь, что это поможет всем, кто сталкивается с этой проблемой:)

1
14.10.2021, 14:17
1 ответ

Идея ядра о корректировке времени нуждается в исправлении. Процесс ntpdобычно дисциплинирует это, так что по мере того, как время становится ближе к реальности, скорость изменений снижается. Это могло быть результатом взаимодействия, возникшего из-за вашей попытки исправить временной шаг с помощью ntpdate.

Я бы посоветовал вам убедиться, что вы знаете, используете ли вы systemdсинхронизацию времени, ntpdили ложу, построенную вокруг чего-то вроде ntpdate.

  • Выключите их все
  • Уберите /etc/adjtimeв сторону (было бы интересно увидеть его содержание в вашем вопросе)
  • Немедленная перезагрузка

На хорошо синхронизированной машине здесь у меня есть следующие значения в /etc/adjtime, а сам файл последний раз изменялся еще в феврале. НЕ КОПИРОВАТЬ ЭТИ ЗНАЧЕНИЯ 

0.001341 1613401384 0.000000
1613401384
UTC

Глядя на man 5 adjtime, вы можете видеть, что эти значения показывают, что эта система имеет систематический дрейф 0,001341 секунды в день (два года для дрейфа в одну секунду ), и что последний раз она корректировалась в феврале. Довольно стабильно. О, и системные часы правильно работают в формате UTC.

Другие вещи, которые следует учитывать в вашей ситуации

  • Пытается ли ядро ​​получить дату/время от гипервизора виртуальной машины?
  • Если это так, любое использование инструмента синхронизации времени на виртуальной машине приведет к нарушению учета времени
  • Виртуальная машина переводится в спящий режим или замедляется в периоды бездействия? Это может привести к сбою настенных часов, если они не синхронизируются с гипервизором виртуальной машины
    • .

Есть несколько полезных ссылок, объясняющих (среди прочего ), что в CentOS 5.3 не было kvm-clockмодуля ядра,

Без этого модуля, когда гипервизор временно (и правильно )лишает ВМ ресурсов ЦП, часы ВМ могут замедлиться или даже остановиться. Модуль обеспечивает точное время ядра виртуальной машины.

Вы можете проверить свою ситуацию с помощью этой команды, которая должна сообщитьkvm-clock:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

первая из этих двух ссылок также предлагала обновить до последней версии CentOS 5.3 (, которая была актуальна в то время ), поскольку это устранило их проблемы со временем. Хотя, вероятно, это нереально для 2021 года.

Другой источник предлагает добавить divider=10 clocksource=acpi_pmв строку загрузки ядра, но это для VMware и может быть неприменимо к Proxmox с kvm.

1
14.10.2021, 14:34

Теги

Похожие вопросы