Avto-profi-evakuator.ru

Авто Профи
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Синхронизация времени при старте системы

Синхронизация времени при старте системы

01 июл 2019, 14:49

Как везде пишут, уже в Ubuntu 18.04, соответственно и в Mint 19, синхронизация времени осуществляется через systemd.

Действительно, при запросе systemctl is-active ntpd выдаётся inactive. То есть, при синхронизации времени система не смотрит на etc/ntp.conf, а должна руководствоваться настройкой timesyncd.

В своём посте systemd-timesyncd в Linux Mint Chocobo уквзывал, что настройка timesyncd осуществляется через файл /etc/systemd/timesyncd.conf Однако все строки моего файла закомментированы:

Возможно, это связано с тем, что dhcp моего роутера вместе с серверами DNS выдаёт клиентам 2 сервера NTP: 62.149.2.62 и 62.149.2.126, соответствующие ntp1.colocall.net и ntp2.colocall.net (при выборах получается, что ответ от ntp2.colocall.net приходит чуть-чуть быстрее и время синхронизируется по нему). Глубинного механизма или conf, в котором бы клиенту компьютера были явно указаны серверы NTP от dhcp мной найдено не было. При этом получаемые от dhcp DNS серверы найдены в /run/systemd/resolve/resolv.conf

Как пишут, ntpq – это инструмент запросов для ntpd. Флаг –p запрашивает данные о серверах NTP, к которым подключается ntpd. Запрос ntpq -p также выдаёт результат, в котором указан сервер NTP, с которым часы компьютера были синхронизированы:

Частные вопросы по синхронизации времени в Linux Mint 19

01 июл 2019, 16:05

Частные вопросы по синхронизации времени в Linux Mint 19

01 июл 2019, 17:19

Также NTP сервера могут быть предусмотрены в systemd-networkd конфигурации с опцией NTP= или динамически через DHCP сервер.

  • Приоритетно — с любого интерфейса NTP серверов, полученных из конфигурации systemd-networkd.service(8) или через DHCP.
  • Сервера NTP, указанные в /etc/systemd/timesyncd.conf будут добавлены в список интерфейса после получения ответа от серверов в процессе соединения с ними.
  • Если после выполнения действий выше информация о серверах NTP не будет получена, то будет использоваться имя хоста и IP адреса, указанные в FallbackNTP=.
Читайте так же:
Регулировка клапанов джили атлас

Изображение

Частные вопросы по синхронизации времени в Linux Mint 19

01 июл 2019, 18:22

Ситуация получилась любопытная.

На запрос timedatectl timesync-status получен ответ Unknown operation timesync-status

На запрос systemctl is-active ntpd получен ответ inactive

На запрос systemctl is-active systemd-timesyncd получен ответ inactive

На запрос timedatectl получен ответ:

На запрос ntpstat получен ответ:

synchronised to NTP server (62.149.2.126) at stratum 3
time correct to within 83 ms
polling server every 1024 s

При вызове System Manager (ПО управления службами через GUI, но на git этого ПО уже нету):

Судя по галочке справа ntp и аналогично крестику в отношении systemd-timesyncd, работает, всё-таки, ntpd.
systemd-timesyncd помечена как активная (галочка слева), но в данный момент не работающая.
ntpd помечена как активная и работающая.

Выходит, что предположение о переводе синхронизации времени в Linux Mint 19 на systemd неверное ?

При переключении на просмотр логов найдено, что ntpd была запущена (через какое-то время после старта системы):

В итоге имеется 2 предположения:

а) имеющийся Linux Mint 19.1 пока находится в «промежуточном» варианте и в будущем синхронизация времени разработчиками может быть переведена на systemd без «телодвижений» со стороны пользователя;

б) картина обусловлена тем, что продолжает использоваться Network Manager. Если бы были осуществлены мероприятия по перенастройке получения адреса через systemd, то это, возможно, «потянуло» бы за собой необходимость и полной перенастройки синхронизации времени через systemd.

Почему так происходит?

Как я уже сказал, проблема в разных форматах хранения и восстановления времени. В компьютере есть два вида часов. Аппаратные — идут всегда, даже когда компьютер выключен и программные часы, встроенные в ядро. Когда компьютер включается значение аппаратных часов записывается в программные, и в дальнейшем операционная система берет время оттуда. Но Windows и Linux работают по-разному с этими двумя часами. Есть два способа работы:

  • UTC — и аппаратные, и программные часы идут по Гринвичу. То есть часы дают универсальное время на нулевом часовом поясе. Например, если у вас часовой пояс GMT+3, Киев, то часы будут отставать на три часа. А уже пользователи локально прибавляют к этому времени поправку на часовой пояс, например, плюс +3. Каждый пользователь добавляет нужную ему поправку. Так делается на серверах, чтобы каждый пользователь мог получить правильное для своего часового пояса время.
  • localtime — в этом варианте программные часы тоже идут по Гринвичу, но аппаратные часы идут по времени локального часового пояса. Для пользователя разницы никакой нет, все равно нужно добавлять поправку на свой часовой пояс. Но при загрузке и синхронизации времени Windows вычитает из аппаратного времени 3 часа (или другую поправку на часовой пояс), чтобы программное время было верным.
Читайте так же:
Кран регулировки тормозов прицепа

Так почему же сбивается время Ubuntu и Windows? Вот, допустим, работает Windows, и со временем там все нормально, оно сохранено в формате localtime. Но при перезагрузке в Linux, операционная система берет время Localtime, и думает что это UTC. Таким образом, пользователь будет брать уже правильное время, и прибавлять к нему поправку на часовой пояс. Поэтому время уже будет неверным.

Дальше вы исправили время, и теперь аппаратные часы работают в UTC. Но затем грузите WIndows. Система думает, что это localtime и для установки правильного программного времени добавляет к аппаратному поправку на часовой пояс, например, в нашем случае +3. Дальше каждый пользователь еще раз применяет эту поправку и время уже сбито, опять.

Единственно верный способ решить эту проблему — заставить обе системы работать по одному формату и сделать это совсем не сложно. Причем можно пойти двумя путями: либо заставить Windows работать по UTC, либо Linux по формату localtime, что является не совсем правильным, но вполне возможно. Итак перейдем к решению проблемы сбивается время в Ubuntu.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector