Управление временем и датой компьютера с помощью systemd

0
484
Управление временем и датой компьютера с помощью systemd
Управление временем и датой компьютера с помощью systemd

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

Системный администратор

Некоторые из нас даже одержимы временем. Мои часы работают на солнечной энергии и получают точное время от Национального института стандартов и технологий (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, который вы используете на своем хосте:

[[email protected] ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[[email protected] ~]#

Убедитесь, что он остановлен и отключен:

[[email protected] ~]# 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)
[[email protected] ~]#

Проверьте статус перед запуском

Статус systemd timesync указывает, инициировала ли systemd службу NTP. Поскольку вы еще не запустили systemd NTP, команда timesync-status не возвращает никаких данных:

[[email protected] ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Но прямой запрос статуса предоставляет некоторую важную информацию. Например, команда timedatectl без аргумента или опций подразумевает по умолчанию подкоманду status:

[[email protected] ~]# 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'.
[[email protected] ~]#

Это возвращает локальное время для вашего хоста, время UTC и время RTC. Это показывает, что системное время установлено на часовой пояс (TZ) Америка/Нью-Йорк, время RTC установлено на время в местном часовом поясе, а служба NTP не активна. Время RTC начало немного отклоняться от системного времени. Это нормально для систем, часы которых не были синхронизированы. Величина дрейфа на хосте зависит от времени, прошедшего с момента последней синхронизации системы, и скорости дрейфа в единицу времени.

Также имеется предупреждение об использовании местного времени для RTC — это относится к смене часовых поясов и переходу на летнее время. Если компьютер выключен, когда необходимо внести изменения, время RTC не изменится. Это не является проблемой для серверов или других узлов, которые включены 24 часа в сутки 7 дней в неделю. Кроме того, любая служба, обеспечивающая синхронизацию времени по протоколу NTP, гарантирует установку правильного времени на хосте в самом начале процесса запуска, так что оно будет правильным еще до того, как компьютер будет полностью готов к работе.

Установка часового пояса

Обычно часовой пояс компьютера устанавливается в процессе установки и никогда не требуется его менять. Тем не менее, иногда возникает необходимость изменить часовой пояс, и есть несколько инструментов, которые могут помочь в этом. Linux использует файлы часовых поясов для определения локального часового пояса, используемого хостом. Эти двоичные файлы находятся в каталоге /usr/share/zoneinfo. По умолчанию мой часовой пояс определяется ссылкой /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Но вам не нужно знать это, чтобы изменить часовой пояс.

Но вам нужно знать официальное название часового пояса для вашего местоположения. Допустим, вы хотите изменить часовой пояс на Лос-Анджелес:

[[email protected] ~]# 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:

[[email protected] ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[[email protected] ~]# timedatectl set-timezone America/Los_Angeles
[[email protected] ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[[email protected] ~]#

Теперь вы можете изменить часовой пояс хоста на свой локальный.

systemd-timesyncd

Демон systemd timesync предоставляет реализацию NTP, которой легко управлять в контексте systemd. Он установлен по умолчанию в Fedora и Ubuntu и запускается по умолчанию в Ubuntu, но не в Fedora. Я не уверен насчет других дистрибутивов; вы можете проверить свой:

[[email protected] ~]# 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 происходит так же, как и любой другой службы:

[[email protected] ~]# 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.
[[email protected] ~]# systemctl start systemd-timesyncd.service
[[email protected] ~]#

Установите аппаратные часы

Вот как выглядела одна из моих систем после запуска timesyncd:

[[email protected] 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 и обнаружил:

[[email protected] 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).
[[email protected] systemd]#

Обратите внимание на сообщение журнала, в котором говорится, что время системных часов не было установлено или перескочило назад. Служба timesync устанавливает системное время на основе временной метки. Временные метки поддерживаются демоном timesync и создаются при каждой успешной синхронизации времени.

Команда timedatectl не имеет возможности установить значение аппаратных часов из системных часов; она может установить время и дату только из значения, введенного в командной строке. Однако вы можете установить RTC на то же значение, что и системное время, с помощью команды hwclock:

[[email protected] ~]# /sbin/hwclock --systohc --localtime
[[email protected] ~]# 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.