Большинство людей озабочены временем. Мы встаем вовремя, чтобы успеть выполнить утренние ритуалы, доехать до работы (в наши дни для многих из нас это короткая поездка), сделать перерыв на обед, уложиться в срок сдачи проекта, отпраздновать дни рождения и праздники, успеть на самолет и многое другое.
Некоторые из нас даже одержимы временем. Мои часы работают на солнечной энергии и получают точное время от Национального института стандартов и технологий (NIST) в Форт-Коллинзе, штат Колорадо, через расположенную там радиостанцию сигналов времени WWVB. Сигналы времени синхронизируются с атомными часами, также расположенными в Форт-Коллинзе. Мой Fitbit синхронизируется с моим телефоном, который синхронизируется с сервером сетевого протокола времени (NTP), который в конечном итоге синхронизируется с атомными часами.
Почему время важно для компьютеров
Существует множество причин, по которым наши устройства и компьютеры нуждаются в точном времени. Например, в банковской сфере, на фондовых рынках и в других финансовых компаниях операции должны проводиться в правильном порядке, и точное время очень важно для этого.
Наши телефоны, планшеты, автомобили, GPS-системы и компьютеры требуют точных настроек времени и даты. Я хочу, чтобы часы на рабочем столе моего компьютера показывали правильное время, чтобы я мог рассчитывать на то, что мое локальное приложение календаря выведет напоминания в нужное время. Правильное время также гарантирует, что задания SystemV cron и таймеры systemd сработают в нужное время.
Правильное время также важно для протоколирования, так как в зависимости от времени легче найти конкретные записи в журнале. Для примера, однажды я работал в DevOps (тогда это еще так не называлось) в системе электронной почты штата Северная Каролина. Мы обрабатывали более 20 миллионов электронных писем в день. Проследить путь электронной почты через ряд серверов или определить точную последовательность событий, используя файлы журналов на географически разнесенных узлах, может быть гораздо проще, если на соответствующих компьютерах сохраняется точное время.
Разное время
У Linux-хостов есть два времени, которые необходимо учитывать: системное время и время RTC. RTC означает часы реального времени, что является причудливым и не очень точным названием для системных аппаратных часов.
Аппаратные часы работают непрерывно, даже когда компьютер выключен, благодаря использованию батареи на системной материнской плате. Основная функция RTC — поддерживать время, когда соединение с сервером времени недоступно. В темные века персональных компьютеров не было интернета, чтобы подключиться к серверу времени, поэтому единственным доступным временем для компьютера были внутренние часы. Операционным системам приходилось полагаться на RTC во время загрузки, а пользователю приходилось вручную устанавливать системное время с помощью интерфейса конфигурации BIOS, чтобы убедиться в его правильности.
Аппаратные часы не понимают концепции часовых поясов; в RTC хранится только время, но не часовой пояс и не смещение от UTC (универсальное координированное время, которое также известно как GMT или Greenwich Mean Time). Вы можете настроить RTC с помощью инструмента, который я рассмотрю далее в этой статье.
Системное время — это время, известное операционной системе. Это время, которое вы видите на графических часах на рабочем столе, в выводе команды date, в метках времени в журналах, а также во времени доступа к файлам, их изменения и модификации.
На странице rtc man содержится более полное обсуждение RTC и системных часов, а также функциональности RTC.
Что такое NTP?
Компьютеры по всему миру используют протокол NTP (Network Time Protocol) для синхронизации своего времени со стандартными эталонными часами Интернета через иерархию серверов NTP. Основные серверы времени находятся на уровне 1, и они напрямую связаны с различными национальными службами времени на уровне 0 через спутник, радио или даже модемы по телефонным линиям. Службами времени на уровне 0 могут быть атомные часы, радиоприемник, настроенный на сигналы атомных часов, или GPS-приемник, использующий высокоточные сигналы часов, передаваемые спутниками GPS.
Чтобы предотвратить перегрузку первичных эталонных серверов запросами времени от серверов времени или клиентов, находящихся ниже в иерархии (т.е. с более высоким номером страты), несколько тысяч публичных серверов NTP страты 2 открыты и доступны для всех. Многие организации и пользователи (включая меня) с большим количеством хостов, которым нужен сервер NTP, предпочитают настраивать собственные серверы времени, так что только один локальный хост получает доступ к серверам времени стратума 2 или 3. Затем они настраивают остальные узлы в сети на использование локального сервера времени. В случае моей домашней сети это сервер стратума 3.
Варианты реализации NTP
Оригинальной реализацией NTP является ntpd, к ней присоединились две более новые — chronyd и systemd-timesyncd. Все три поддерживают синхронизацию времени локального узла с сервером времени NTP. Служба systemd-timesyncd не такая надежная, как chronyd, но ее достаточно для большинства целей. Она может выполнять большие скачки времени, если RTC сильно рассинхронизирован, и может постепенно корректировать системное время, чтобы оставаться в синхронизации с NTP-сервером, если локальное системное время немного дрейфует. Служба systemd-timesync не может быть использована в качестве сервера времени.
Chrony — это реализация NTP, содержащая две программы: демон chronyd и интерфейс командной строки chronyc. Как я объяснял в предыдущей статье, Chrony имеет некоторые особенности, которые делают его лучшим выбором для многих сред, в основном:
- Chrony может синхронизироваться с сервером времени гораздо быстрее, чем старая служба ntpd. Это хорошо для ноутбуков или настольных компьютеров, которые не работают постоянно.
- Он может компенсировать колебания тактовой частоты, например, когда хост впадает в спячку или переходит в спящий режим, или когда тактовая частота изменяется из-за шага частоты, который замедляет тактовую частоту при низкой нагрузке.
- Она справляется с прерывистыми сетевыми подключениями и насыщением полосы пропускания.
- Он корректирует сетевые задержки и латентность.
- После первоначальной синхронизации времени Chrony никогда не останавливает часы. Это обеспечивает стабильность и постоянство временных интервалов для многих системных служб и приложений.
- Chrony может работать даже без подключения к сети. В этом случае локальный хост или сервер может быть обновлен вручную.
- Chrony может выступать в качестве NTP-сервера.
Для ясности, NTP — это протокол, который реализуется на Linux-хосте с помощью Chrony или systemd-timesyncd.service.
Пакеты NTP, Chrony и systemd-timesyncd RPM доступны в стандартных репозиториях Fedora. Systemd-udev RPM — это основанный на правилах узел устройств и менеджер событий ядра, который установлен по умолчанию в Fedora, но не включен.
Вы можете установить все три и переключаться между ними, но это хлопотно и не стоит того. Современные выпуски Fedora, CentOS и RHEL перешли от NTP к Chrony в качестве реализации хронометража по умолчанию, и они также устанавливают systemd-timesyncd. Я считаю, что Chrony работает хорошо, предоставляет лучший интерфейс, чем служба NTP, предоставляет гораздо больше информации и увеличивает контроль, что является преимуществом для системного администратора.
Отключите другие службы NTP
Возможно, на вашем хосте уже запущена служба NTP. Если это так, вам нужно отключить ее, прежде чем переходить на что-то другое. Я использовал chronyd, поэтому я использовал следующие команды для его остановки и отключения. Выполните соответствующие команды для любого демона NTP, который вы используете на своем хосте:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd Removed /etc/systemd/system/multi-user.target.wants/chronyd.service. [root@testvm1 ~]#
Убедитесь, что он остановлен и отключен:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#
Проверьте статус перед запуском
Статус systemd timesync указывает, инициировала ли systemd службу NTP. Поскольку вы еще не запустили systemd NTP, команда timesync-status не возвращает никаких данных:
[root@testvm1 ~]# timedatectl timesync-status Failed to query server: Could not activate remote peer.
Но прямой запрос статуса предоставляет некоторую важную информацию. Например, команда timedatectl без аргумента или опций подразумевает по умолчанию подкоманду status:
[root@testvm1 ~]# timedatectl status
Local time: Fri 2020-05-15 08:43:10 EDT
Universal time: Fri 2020-05-15 12:43:10 UTC
RTC time: Fri 2020-05-15 08:43:08
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#
Это возвращает локальное время для вашего хоста, время UTC и время RTC. Это показывает, что системное время установлено на часовой пояс (TZ) Америка/Нью-Йорк, время RTC установлено на время в местном часовом поясе, а служба NTP не активна. Время RTC начало немного отклоняться от системного времени. Это нормально для систем, часы которых не были синхронизированы. Величина дрейфа на хосте зависит от времени, прошедшего с момента последней синхронизации системы, и скорости дрейфа в единицу времени.
Также имеется предупреждение об использовании местного времени для RTC — это относится к смене часовых поясов и переходу на летнее время. Если компьютер выключен, когда необходимо внести изменения, время RTC не изменится. Это не является проблемой для серверов или других узлов, которые включены 24 часа в сутки 7 дней в неделю. Кроме того, любая служба, обеспечивающая синхронизацию времени по протоколу NTP, гарантирует установку правильного времени на хосте в самом начале процесса запуска, так что оно будет правильным еще до того, как компьютер будет полностью готов к работе.
Установка часового пояса
Обычно часовой пояс компьютера устанавливается в процессе установки и никогда не требуется его менять. Тем не менее, иногда возникает необходимость изменить часовой пояс, и есть несколько инструментов, которые могут помочь в этом. Linux использует файлы часовых поясов для определения локального часового пояса, используемого хостом. Эти двоичные файлы находятся в каталоге /usr/share/zoneinfo. По умолчанию мой часовой пояс определяется ссылкой /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Но вам не нужно знать это, чтобы изменить часовой пояс.
Но вам нужно знать официальное название часового пояса для вашего местоположения. Допустим, вы хотите изменить часовой пояс на Лос-Анджелес:
[root@testvm2 ~]# timedatectl list-timezones | column <SNIP> America/La_Paz Europe/Budapest America/Lima Europe/Chisinau America/Los_Angeles Europe/Copenhagen America/Maceio Europe/Dublin America/Managua Europe/Gibraltar America/Manaus Europe/Helsinki <SNIP>
Теперь вы можете установить часовой пояс. Я использовал команду date для проверки изменений, но вы также можете использовать timedatectl:
[root@testvm2 ~]# date Tue 19 May 2020 04:47:49 PM EDT [root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles [root@testvm2 ~]# date Tue 19 May 2020 01:48:23 PM PDT [root@testvm2 ~]#
Теперь вы можете изменить часовой пояс хоста на свой локальный.
systemd-timesyncd
Демон systemd timesync предоставляет реализацию NTP, которой легко управлять в контексте systemd. Он установлен по умолчанию в Fedora и Ubuntu и запускается по умолчанию в Ubuntu, но не в Fedora. Я не уверен насчет других дистрибутивов; вы можете проверить свой:
[root@testvm1 ~]# systemctl status systemd-timesyncd
Настройка systemd-timesyncd
Конфигурационный файл для systemd-timesyncd находится в /etc/systemd/timesyncd.conf. Это простой файл с меньшим количеством включенных опций, чем в более старых службах NTP и chronyd. Вот полное содержимое версии этого файла по умолчанию на моей виртуальной машине Fedora:
# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See timesyncd.conf(5) for details. [Time] #NTP= #FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org #RootDistanceMaxSec=5 #PollIntervalMinSec=32 #PollIntervalMaxSec=2048
Единственный раздел, который он содержит, кроме комментариев, это [Time], и все строки закомментированы. Это значения по умолчанию, и их не нужно изменять или разкомментировать (если только у вас нет на то причин). Если у вас нет определенного сервера времени NTP, заданного в строке NTP=, Fedora по умолчанию будет использовать пул серверов времени Fedora. Мне нравится добавлять в эту строку сервер времени в моей сети:
NTP=myntpserver
Запуск timesync
Запуск и включение systemd-timesyncd происходит так же, как и любой другой службы:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service. Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service. [root@testvm2 ~]# systemctl start systemd-timesyncd.service [root@testvm2 ~]#
Установите аппаратные часы
Вот как выглядела одна из моих систем после запуска timesyncd:
[root@testvm2 systemd]# timedatectl
Local time: Sat 2020-05-16 14:34:54 EDT
Universal time: Sat 2020-05-16 18:34:54 UTC
RTC time: Sat 2020-05-16 14:34:53
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Время RTC примерно на секунду отличается от местного времени (EDT), и это расхождение увеличивается еще на пару секунд в течение следующих нескольких дней. Поскольку в RTC нет понятия часовых поясов, команда timedatectl должна провести сравнение, чтобы определить, какой часовой пояс совпадает. Если время RTC не совпадает с местным временем в точности, то считается, что он не находится в местном часовом поясе.
В поисках дополнительной информации я проверил статус systemd-timesync.service и обнаружил:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Tasks: 2 (limit: 10365)
Memory: 2.8M
CPU: 476ms
CGroup: /system.slice/systemd-timesyncd.service
└─822 /usr/lib/systemd/systemd-timesyncd
May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#
Обратите внимание на сообщение журнала, в котором говорится, что время системных часов не было установлено или перескочило назад. Служба timesync устанавливает системное время на основе временной метки. Временные метки поддерживаются демоном timesync и создаются при каждой успешной синхронизации времени.
Команда timedatectl не имеет возможности установить значение аппаратных часов из системных часов; она может установить время и дату только из значения, введенного в командной строке. Однако вы можете установить RTC на то же значение, что и системное время, с помощью команды hwclock:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Local time: Mon 2020-05-18 13:56:46 EDT
Universal time: Mon 2020-05-18 17:56:46 UTC
RTC time: Mon 2020-05-18 13:56:46
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yes
Параметр —localtime гарантирует, что аппаратные часы будут установлены на местное время, а не на UTC.
Действительно ли вам нужен RTC?
Любая реализация NTP будет устанавливать системные часы во время запуска, так нужен ли RTC? На самом деле нет, если у вас есть сетевое подключение к серверу времени. Однако многие системы не имеют постоянного доступа к сетевому соединению, поэтому аппаратные часы полезны, чтобы Linux мог считывать их и устанавливать системное время. Это лучшее решение, чем устанавливать время вручную, даже если оно может отклоняться от реального времени.
Заключение
В этой статье мы рассмотрели использование некоторых инструментов systemd для управления датой, временем и часовыми поясами. Инструмент systemd-timesyncd предоставляет достойный клиент NTP, который может синхронизировать время на локальном узле с сервером NTP. Однако systemd-timesyncd не предоставляет серверную службу, поэтому если вам нужен NTP-сервер в вашей сети, вы должны использовать что-то другое, например, Chrony, для работы в качестве сервера.
Я предпочитаю иметь единую реализацию для любой службы в моей сети, поэтому я использую Chrony. Если вам не нужен локальный NTP-сервер, или если вы не против иметь дело с Chrony для сервера и systemd-timesyncd для клиента, и вам не нужны дополнительные возможности Chrony, то systemd-timesyncd вполне подойдет для NTP-клиента.
Есть еще один момент, который я хочу отметить: Вам не обязательно использовать инструменты systemd для реализации NTP. Вы можете использовать старый ntpd или Chrony или другую реализацию NTP. systemd состоит из большого количества сервисов; многие из них необязательны, поэтому их можно отключить и использовать вместо них что-то другое. Это не огромный, монолитный монстр, каким его некоторые выставляют. Можно не любить systemd или отдельные ее части, но вы должны принять взвешенное решение.
Мне не нравится реализация NTP в systemd, но я предпочитаю Chrony, потому что он лучше отвечает моим потребностям. И в этом суть Linux.
