La mayoría de la gente está preocupada por el tiempo. Nos levantamos a tiempo para realizar nuestros rituales matutinos y viajar al trabajo (un viaje corto para muchos de nosotros en estos días), tomar un descanso para almorzar, cumplir con la fecha límite de un proyecto, celebrar cumpleaños y días festivos, tomar un avión y mucho más. .
Algunos de nosotros estamos incluso obsesionados con tiempo. Mi reloj funciona con energía solar y obtiene la hora exacta del Instituto Nacional de Estándares y Tecnología (NIST) en Fort Collins, Colorado, a través de la estación de radio de señal horaria WWVB ubicada allí. Las señales de tiempo se sincronizan con el reloj atómico, también ubicado en Fort Collins. Mi Fitbit se sincroniza con mi teléfono, que está sincronizado con un servidor de protocolo de tiempo de red (NTP), que finalmente se sincroniza con el reloj atómico.
Por que el tiempo es importante para las computadoras
Hay muchas razones por las que nuestros dispositivos y computadoras necesitan la hora exacta. Por ejemplo, en la banca, los mercados bursátiles y otros negocios financieros, las transacciones deben mantenerse en el orden correcto y las secuencias de tiempo exactas son críticas para eso.
Nuestros teléfonos, tabletas, automóviles, sistemas de GPS y computadoras requieren configuraciones precisas de fecha y hora. Quiero que el reloj en el escritorio de mi computadora sea correcto, para poder contar con mi aplicación de calendario local para que aparezcan recordatorios en el momento correcto. La hora correcta también garantiza que los trabajos cron de SystemV y los temporizadores de systemd se activen en el momento correcto.
La hora correcta también es importante para el registro, por lo que es un poco más fácil ubicar entradas de registro específicas en función de la hora. Por ejemplo, una vez trabajé en DevOps (no se llamaba así en ese momento) para el sistema de correo electrónico del Estado de Carolina del Norte. Solíamos procesar más de 20 millones de correos electrónicos por día. Seguir el rastro del correo electrónico a través de una serie de servidores o determinar la secuencia exacta de eventos mediante el uso de archivos de registro en hosts dispersos geográficamente puede ser mucho más fácil cuando las computadoras en cuestión mantienen la hora exacta.
Varias veces
Los hosts de Linux tienen dos tiempos a considerar:el tiempo del sistema y el tiempo RTC. RTC significa reloj en tiempo real, que es un nombre elegante y no particularmente preciso para el reloj del hardware del sistema.
El reloj de hardware funciona continuamente, incluso cuando la computadora está apagada, usando una batería en la placa base del sistema. La función principal del RTC es mantener la hora cuando no hay disponible una conexión a un servidor horario. En la era oscura de las computadoras personales, no había Internet para conectarse a un servidor de tiempo, por lo que la única hora que una computadora tenía disponible era el reloj interno. Los sistemas operativos tenían que depender del RTC en el momento del arranque, y el usuario tenía que configurar manualmente la hora del sistema mediante la interfaz de configuración del BIOS del hardware para asegurarse de que fuera correcta.
El reloj de hardware no entiende el concepto de zonas horarias; solo la hora se almacena en el RTC, no la zona horaria ni un desplazamiento de UTC (Tiempo Universal Coordinado, que también se conoce como GMT u Hora del Meridiano de Greenwich). Puede configurar el RTC con una herramienta que exploraré más adelante en este artículo.
La hora del sistema es la hora conocida por el sistema operativo. Es la hora que ve en el reloj GUI de su escritorio, en la salida de date comando, en marcas de tiempo para registros y en acceso a archivos, modificar y cambiar tiempos.
El rtc La página del manual contiene una discusión más completa sobre el RTC y los relojes del sistema y la funcionalidad del RTC.
¿Qué pasa con NTP?
Las computadoras de todo el mundo utilizan NTP (Network Time Protocol) para sincronizar su hora con los relojes de referencia estándar de Internet a través de una jerarquía de servidores NTP. Los servidores de tiempo principales están en el estrato 1 y están conectados directamente a varios servicios de tiempo nacionales en el estrato 0 a través de satélite, radio o incluso módems a través de líneas telefónicas. Los servicios de tiempo en el estrato 0 pueden ser un reloj atómico, un receptor de radio sintonizado con las señales transmitidas por un reloj atómico o un receptor GPS que utiliza señales de reloj de alta precisión transmitidas por satélites GPS.
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
Para evitar que las solicitudes de hora de los servidores de hora o de los clientes de menor jerarquía (es decir, con un número de estrato más alto) abrumen a los servidores de referencia primarios, varios miles de servidores NTP públicos de estrato 2 están abiertos y disponibles para que todos los usen. Muchas organizaciones y usuarios (incluyéndome a mí) con una gran cantidad de hosts que necesitan un servidor NTP eligen configurar sus propios servidores de tiempo, por lo que solo un host local accede a los servidores de tiempo del estrato 2 o 3. Luego configuran los hosts restantes en la red para usar el servidor de hora local. En el caso de mi red doméstica, es un servidor de estrato 3.
Opciones de implementación de NTP
La implementación original de NTP es ntpd , y se le han sumado dos más nuevos, chronyd y systemd-timesyncd . Los tres mantienen la hora del host local sincronizada con un servidor de hora NTP. El servicio systemd-timesyncd no es tan robusto como chronyd, pero es suficiente para la mayoría de los propósitos. Puede realizar grandes saltos de tiempo si el RTC está muy desincronizado, y puede ajustar la hora del sistema gradualmente para permanecer sincronizado con el servidor NTP si la hora del sistema local se desvía un poco. El servicio systemd-timesync no se puede utilizar como servidor horario.
Chrony es una implementación de NTP que contiene dos programas:el demonio chronyd y una interfaz de línea de comandos llamada chronyc. Como expliqué en un artículo anterior, Chrony tiene algunas características que lo convierten en la mejor opción para muchos entornos, principalmente:
- Chrony puede sincronizarse con el servidor horario mucho más rápido que el antiguo servicio ntpd. Esto es bueno para computadoras portátiles o de escritorio que no se ejecutan constantemente.
- Puede compensar las fluctuaciones de las frecuencias del reloj, como cuando un host hiberna o entra en modo de suspensión, o cuando la velocidad del reloj varía debido a los pasos de frecuencia que reducen la velocidad del reloj cuando las cargas son bajas.
- Maneja conexiones de red intermitentes y saturación de ancho de banda.
- Se ajusta a los retrasos y la latencia de la red.
- Después de la sincronización de tiempo inicial, Chrony nunca detiene el reloj. Esto asegura intervalos de tiempo estables y consistentes para muchos servicios y aplicaciones del sistema.
- Chrony puede funcionar incluso sin una conexión de red. En este caso, el host o servidor local se puede actualizar manualmente.
- Chrony puede actuar como un servidor NTP.
Para que quede claro, NTP es un protocolo que se implementa en un host Linux utilizando Chrony o systemd-timesyncd.service.
Los paquetes RPM NTP, Chrony y systemd-timesyncd están disponibles en los repositorios estándar de Fedora. El RPM systemd-udev es un nodo de dispositivo basado en reglas y un administrador de eventos del kernel que se instala de forma predeterminada con Fedora pero no está habilitado.
Puede instalar los tres y cambiar entre ellos, pero eso es una molestia y no vale la pena. Las versiones modernas de Fedora, CentOS y RHEL han pasado de NTP a Chrony como su implementación de cronometraje predeterminada y también instalan systemd-timesyncd. Encuentro que Chrony funciona bien, proporciona una mejor interfaz que el servicio NTP, presenta mucha más información y aumenta el control, que son ventajas para el administrador del sistema.
Deshabilitar otros servicios NTP
Es posible que ya se esté ejecutando un servicio NTP en su host. Si es así, debe desactivarlo antes de cambiar a otra cosa. He estado usando chronyd, así que usé los siguientes comandos para detenerlo y deshabilitarlo. Ejecute los comandos apropiados para cualquier demonio NTP que esté utilizando en su host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#
Verifique que esté detenido y deshabilitado:
[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 ~]#
Verifique el estado antes de comenzar
El estado de systemd timesync indica si systemd ha iniciado un servicio NTP. Debido a que aún no ha iniciado systemd NTP, el timesync-status el comando no devuelve datos:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.
Pero un status directo solicitud proporciona información importante. Por ejemplo, el timedatectl comando sin un argumento u opciones implica el status subcomando por defecto:
[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 ~]#
Esto devuelve la hora local de su host, la hora UTC y la hora RTC. Muestra que la hora del sistema está configurada en America/New_York zona horaria (TZ ), el RTC se establece en la hora de la zona horaria local y el servicio NTP no está activo. La hora RTC ha comenzado a desviarse un poco de la hora del sistema. Esto es normal con sistemas cuyos relojes no han sido sincronizados. La cantidad de deriva en un host depende de la cantidad de tiempo desde la última sincronización del sistema y la velocidad de la deriva por unidad de tiempo.
También hay un mensaje de advertencia sobre el uso de la hora local para el RTC; esto se relaciona con los cambios de zona horaria y los ajustes del horario de verano. Si la computadora está apagada cuando es necesario realizar cambios, la hora RTC no cambiará. Esto no es un problema en servidores u otros hosts que funcionan las 24 horas del día, los 7 días de la semana. Además, cualquier servicio que proporcione sincronización de hora NTP garantizará que el host esté configurado en la hora adecuada al principio del proceso de inicio, por lo que será correcto antes de que esté completamente en funcionamiento.
Establecer la zona horaria
Por lo general, configura la zona horaria de una computadora durante el procedimiento de instalación y nunca necesita cambiarla. Sin embargo, hay ocasiones en las que es necesario cambiar la zona horaria y hay un par de herramientas para ayudar. Linux usa archivos de zona horaria para definir la zona horaria local que usa el host. Estos archivos binarios se encuentran en el /usr/share/zoneinfo directorio. El valor predeterminado para mi zona horaria está definido por el enlace /etc/localtime -> ../usr/share/zoneinfo/America/New_York . Pero no necesita saber eso para cambiar la zona horaria.
Pero sí necesita saber el nombre oficial de la zona horaria de su ubicación. Digamos que desea cambiar la zona horaria a Los Ángeles:
[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>
Ahora puede configurar la zona horaria. Usé la date comando para verificar el cambio, pero también podría usar 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 ~]#
Ahora puede volver a cambiar la zona horaria de su host a la local.
systemd-timesyncd
El demonio systemd timesync proporciona una implementación NTP que es fácil de administrar dentro de un contexto systemd. Se instala por defecto en Fedora y Ubuntu y se inicia por defecto en Ubuntu pero no en Fedora. No estoy seguro acerca de otras distribuciones; puedes consultar el tuyo con:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfigurar systemd-timesyncd
El archivo de configuración para systemd-timesyncd es /etc/systemd/timesyncd.conf . Es un archivo simple con menos opciones incluidas que el antiguo servicio NTP y chronyd. Aquí está el contenido completo de la versión predeterminada de este archivo en mi máquina virtual 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
La única sección que contiene además de los comentarios es [Time] , y todas las líneas están comentadas. Estos son los valores predeterminados y no es necesario cambiarlos ni descomentarlos (a menos que tenga alguna razón para hacerlo). Si no tiene un servidor horario NTP específico definido en el NTP= línea, el valor predeterminado de Fedora es recurrir al grupo de servidores de tiempo de Fedora. Me gusta agregar el servidor de tiempo en mi red a esta línea:
NTP=myntpserverIniciar sincronización
Iniciar y habilitar systemd-timesyncd es como cualquier otro servicio:
[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 ~]#
Configurar el reloj del hardware
Así es como se veía uno de mis sistemas después de iniciar 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
La hora RTC está aproximadamente a un segundo de la hora local (EDT), y la discrepancia crece un par de segundos más en los próximos días. Debido a que RTC no tiene el concepto de zonas horarias, el timedatectl El comando debe hacer una comparación para determinar qué zona horaria coincide. Si la hora RTC no coincide exactamente con la hora local, no se considera que está en la zona horaria local.
En busca de un poco más de información, verifiqué el estado de systemd-timesync.service y encontré:
[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]#
Observe el mensaje de registro que dice que la hora del reloj del sistema no se configuró o saltó hacia atrás. El servicio de sincronización de tiempo establece la hora del sistema a partir de una marca de tiempo. Las marcas de tiempo son mantenidas por el daemon de sincronización de tiempo y se crean en cada sincronización de tiempo exitosa.
El timedatectl el comando no tiene la capacidad de establecer el valor del reloj del hardware desde el reloj del sistema; solo puede establecer la hora y la fecha a partir de un valor ingresado en la línea de comando. Sin embargo, puede establecer el RTC en el mismo valor que la hora del sistema utilizando el hwclock comando:
[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
El --localtime La opción garantiza que el reloj del hardware esté configurado en hora local, no UTC.
¿Realmente necesita RTC?
Cualquier implementación de NTP configurará el reloj del sistema durante la secuencia de inicio, entonces, ¿es necesario RTC? En realidad, no, siempre que tenga una conexión de red a un servidor de tiempo. Sin embargo, muchos sistemas no tienen acceso de tiempo completo a una conexión de red, por lo que el reloj del hardware es útil para que Linux pueda leerlo y establecer la hora del sistema. Esta es una mejor solución que tener que ajustar la hora a mano, incluso si se desvía de la hora real.
Resumen
Este artículo exploró el uso de algunas herramientas systemd para administrar la fecha, la hora y las zonas horarias. La herramienta systemd-timesyncd proporciona un cliente NTP decente que puede mantener la hora en un host local sincronizado con un servidor NTP. Sin embargo, systemd-timesyncd no proporciona un servicio de servidor, por lo que si necesita un servidor NTP en su red, debe usar otra cosa, como Chrony, para que actúe como servidor.
Prefiero tener una implementación única para cualquier servicio en mi red, por lo que uso Chrony. Si no necesita un servidor NTP local, o si no le importa tratar con Chrony para el servidor y systemd-timesyncd para el cliente y no necesita las capacidades adicionales de Chrony, entonces systemd-timesyncd es una opción útil para un cliente NTP .
Hay otro punto que quiero señalar:no tiene que usar las herramientas systemd para la implementación de NTP. Puede usar el antiguo ntpd o Chrony o alguna otra implementación de NTP. systemd está compuesto por una gran cantidad de servicios; muchos de ellos son opcionales, por lo que se pueden deshabilitar y usar algo más en su lugar. No es el monstruo enorme y monolítico que algunos hacen parecer. Está bien que no te guste systemd o partes de él, pero debes tomar una decisión informada.
No me disgusta la implementación de NTP de systemd, pero prefiero Chrony porque satisface mejor mis necesidades. Y de eso se trata Linux.
Recursos
Hay una gran cantidad de información sobre systemd disponible en Internet, pero mucha es concisa, obtusa o incluso engañosa. Además de los recursos mencionados en este artículo, las siguientes páginas web ofrecen información más detallada y confiable sobre el inicio de systemd.
- El Proyecto Fedora tiene una buena guía práctica para systemd. Tiene prácticamente todo lo que necesita saber para configurar, administrar y mantener una computadora Fedora usando systemd.
- El Proyecto Fedora también tiene una buena hoja de trucos que hace una referencia cruzada de los comandos antiguos de SystemV con los de systemd comparables.
- Para obtener información técnica detallada sobre systemd y las razones para crearlo, consulte la descripción de systemd de Freedesktop.org.
- "More systemd fun" de Linux.com ofrece información y consejos más avanzados sobre systemd.
También hay una serie de artículos profundamente técnicos para administradores de sistemas Linux escritos por Lennart Poettering, el diseñador y desarrollador principal de systemd. Estos artículos fueron escritos entre abril de 2010 y septiembre de 2011, pero son tan relevantes ahora como lo fueron entonces. Gran parte de todo lo bueno que se ha escrito sobre systemd y su ecosistema se basa en estos documentos.
- Repensar el PID 1
- systemd para administradores, Parte I
- systemd para administradores, Parte II
- systemd para administradores, Parte III
- systemd para administradores, Parte IV
- systemd para administradores, Parte V
- systemd para administradores, Parte VI
- systemd para administradores, Parte VII
- systemd para administradores, Parte VIII
- systemd para administradores, Parte IX
- systemd para administradores, Parte X
- systemd para administradores, Parte XI