Contrôlez l'heure et la date de votre ordinateur avec systemd

La plupart des gens sont préoccupés par le temps. Nous nous levons à temps pour effectuer nos rituels du matin et nous rendre au travail (un court trajet pour beaucoup d'entre nous ces jours-ci), faire une pause pour le déjeuner, respecter une date limite de projet, célébrer les anniversaires et les vacances, prendre un avion, et bien plus encore .

Certains d'entre nous sont même obsédés avec le temps. Ma montre est alimentée par l'énergie solaire et obtient l'heure exacte du National Institute of Standards and Technology (NIST) à Fort Collins, Colorado, via la station de radio signal horaire WWVB qui s'y trouve. Les signaux horaires sont synchronisés avec l'horloge atomique, également située à Fort Collins. Mon Fitbit se synchronise avec mon téléphone, qui est synchronisé avec un serveur NTP (Network Time Protocol), qui est finalement synchronisé avec l'horloge atomique.

Pourquoi le temps est important pour les ordinateurs

Il existe de nombreuses raisons pour lesquelles nos appareils et ordinateurs ont besoin de l'heure exacte. Par exemple, dans les banques, les marchés boursiers et d'autres activités financières, les transactions doivent être maintenues dans le bon ordre, et des séquences temporelles exactes sont essentielles pour cela.

Nos téléphones, tablettes, voitures, systèmes GPS et ordinateurs nécessitent tous des réglages précis de l'heure et de la date. Je veux que l'horloge sur le bureau de mon ordinateur soit correcte, afin que je puisse compter sur mon application de calendrier local pour afficher des rappels au bon moment. L'heure correcte garantit également que les tâches cron SystemV et les temporisateurs systemd se déclenchent au bon moment.

L'heure correcte est également importante pour la journalisation, il est donc un peu plus facile de localiser des entrées de journal spécifiques en fonction de l'heure. Par exemple, j'ai déjà travaillé dans DevOps (on ne l'appelait pas ainsi à l'époque) pour le système de messagerie de l'État de Caroline du Nord. Nous traitions plus de 20 millions d'e-mails par jour. Suivre la trace des e-mails via une série de serveurs ou déterminer la séquence exacte des événements en utilisant des fichiers journaux sur des hôtes géographiquement dispersés peut être beaucoup plus facile lorsque les ordinateurs en question conservent des heures exactes.

Plusieurs fois

Les hôtes Linux doivent prendre en compte deux temps :l'heure système et l'heure RTC. RTC signifie horloge en temps réel, qui est un nom fantaisiste et pas particulièrement précis pour l'horloge matérielle du système.

L'horloge matérielle fonctionne en continu, même lorsque l'ordinateur est éteint, en utilisant une batterie sur la carte mère du système. La fonction principale du RTC est de garder l'heure lorsqu'une connexion à un serveur de temps n'est pas disponible. À l'âge sombre des ordinateurs personnels, il n'y avait pas d'Internet pour se connecter à un serveur de temps, de sorte que la seule heure dont un ordinateur disposait était l'horloge interne. Les systèmes d'exploitation devaient s'appuyer sur le RTC au démarrage, et l'utilisateur devait régler manuellement l'heure du système à l'aide de l'interface de configuration matérielle du BIOS pour s'assurer qu'elle était correcte.

L'horloge matérielle ne comprend pas le concept de fuseaux horaires; seule l'heure est stockée dans le RTC, pas le fuseau horaire ni un décalage par rapport à l'UTC (Universal Coordinated Time, également appelé GMT ou Greenwich Mean Time). Vous pouvez définir le RTC avec un outil que j'explorerai plus tard dans cet article.

L'heure système est l'heure connue du système d'exploitation. C'est l'heure que vous voyez sur l'horloge de l'interface graphique sur votre bureau, dans la sortie de la date commande, dans les horodatages des journaux et dans les heures d'accès, de modification et de modification des fichiers.

Le rtc La page de manuel contient une discussion plus complète sur les horloges RTC et système et les fonctionnalités de RTC.

Qu'en est-il de NTP ?

Les ordinateurs du monde entier utilisent le NTP (Network Time Protocol) pour synchroniser leur heure avec les horloges de référence standard Internet via une hiérarchie de serveurs NTP. Les principaux serveurs de temps se trouvent au niveau de la strate 1 et sont directement connectés à divers services horaires nationaux au niveau de la strate 0 via satellite, radio ou même des modems sur des lignes téléphoniques. Les services horaires de la strate 0 peuvent être une horloge atomique, un récepteur radio réglé sur les signaux diffusés par une horloge atomique ou un récepteur GPS utilisant les signaux d'horloge très précis diffusés par les satellites GPS.

Plus de ressources Linux

• Aide-mémoire des commandes Linux
• Aide-mémoire des commandes Linux avancées
• Cours en ligne gratuit :Présentation technique de RHEL
• Aide-mémoire sur le réseau Linux
• Aide-mémoire SELinux
• Aide-mémoire sur les commandes courantes de Linux
• Que sont les conteneurs Linux ?
• Nos derniers articles Linux

Pour éviter que les demandes de temps des serveurs de temps ou des clients situés plus bas dans la hiérarchie (c'est-à-dire avec un numéro de strate plus élevé) ne submergent les serveurs de référence principaux, plusieurs milliers de serveurs publics NTP stratum 2 sont ouverts et disponibles pour tous. De nombreuses organisations et utilisateurs (y compris moi) avec un grand nombre d'hôtes qui ont besoin d'un serveur NTP choisissent de configurer leurs propres serveurs de temps, de sorte qu'un seul hôte local accède aux serveurs de temps de la strate 2 ou 3. Ensuite, ils configurent les hôtes restants du réseau pour utiliser le serveur de temps local. Dans le cas de mon réseau domestique, il s'agit d'un serveur stratum 3.

Options d'implémentation NTP

L'implémentation NTP d'origine est ntpd , et il a été rejoint par deux plus récents, chronyd et systemd-timesyncd . Tous trois gardent l'heure de l'hôte local synchronisée avec un serveur de temps NTP. Le service systemd-timesyncd n'est pas aussi robuste que chronyd, mais il est suffisant dans la plupart des cas. Il peut effectuer de grands sauts de temps si le RTC est loin de la synchronisation, et il peut ajuster progressivement l'heure du système pour rester synchronisé avec le serveur NTP si l'heure du système local dérive un peu. Le service systemd-timesync ne peut pas être utilisé comme serveur de temps.

Chrony est une implémentation NTP contenant deux programmes :le démon chronyd et une interface de ligne de commande appelée chronyc. Comme je l'ai expliqué dans un article précédent, Chrony possède certaines fonctionnalités qui en font le meilleur choix pour de nombreux environnements, principalement :

• Chrony peut se synchroniser avec le serveur de temps beaucoup plus rapidement que l'ancien service ntpd. C'est bon pour les ordinateurs portables ou de bureau qui ne fonctionnent pas en permanence.
• Il peut compenser les fluctuations des fréquences d'horloge, comme lorsqu'un hôte hiberne ou passe en mode veille, ou lorsque la vitesse d'horloge varie en raison d'un pas de fréquence qui ralentit les vitesses d'horloge lorsque les charges sont faibles.
• Il gère les connexions réseau intermittentes et la saturation de la bande passante.
• Il s'ajuste aux retards et à la latence du réseau.
• Après la synchronisation initiale de l'heure, Chrony n'arrête jamais l'horloge. Cela garantit des intervalles de temps stables et cohérents pour de nombreux services et applications système.
• Chrony peut fonctionner même sans connexion réseau. Dans ce cas, l'hôte ou le serveur local peut être mis à jour manuellement.
• Chrony peut agir comme un serveur NTP.

Juste pour être clair, NTP est un protocole qui est implémenté sur un hôte Linux en utilisant Chrony ou le systemd-timesyncd.service.

Les packages RPM NTP, Chrony et systemd-timesyncd sont disponibles dans les référentiels Fedora standard. Le RPM systemd-udev est un nœud de périphérique basé sur des règles et un gestionnaire d'événements du noyau qui est installé par défaut avec Fedora mais pas activé.

Vous pouvez installer les trois et basculer entre eux, mais c'est pénible et cela n'en vaut pas la peine. Les versions modernes de Fedora, CentOS et RHEL sont passées de NTP à Chrony comme implémentation de chronométrage par défaut, et elles installent également systemd-timesyncd. Je trouve que Chrony fonctionne bien, fournit une meilleure interface que le service NTP, présente beaucoup plus d'informations et augmente le contrôle, ce qui sont autant d'avantages pour l'administrateur système.

Désactiver les autres services NTP

Il est possible qu'un service NTP soit déjà en cours d'exécution sur votre hôte. Si c'est le cas, vous devez le désactiver avant de passer à autre chose. J'utilise chronyd, j'ai donc utilisé les commandes suivantes pour l'arrêter et le désactiver. Exécutez les commandes appropriées pour le démon NTP que vous utilisez sur votre hôte :

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Suppression de /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Vérifiez qu'il est à la fois arrêté et désactivé :

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - client/serveur NTP
     Chargé :chargé (/usr/lib/systemd/system/chronyd.service ; désactivé ; fournisseur prédéfini :activé)
     Actif :inactif (mort)
       Docs :man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]# 
Vérifiez l'état avant de commencer
 

 Le statut de systemd timesync indique si systemd a lancé un service NTP. Parce que vous n'avez pas encore démarré systemd NTP, le timesync-status la commande ne renvoie aucune donnée :
 
[root@testvm1 ~]# timedatectl timesync-status 
Échec de l'interrogation du serveur :impossible d'activer le pair distant.
 

 Mais un status direct demande fournit des informations importantes. Par exemple, le timedatectl la commande sans argument ni options implique le status sous-commande par défaut :
 
[root@testvm1 ~]# timedatectl status
           Heure locale :ven 2020-05-15 08:43:10 EDT  
           Heure universelle :ven 2020-05-15 12:43:10 UTC inactif                   
          RTC dans TZ local :oui                    

Avertissement :le système est configuré pour lire l'heure RTC dans le fuseau horaire local.
         Ce mode ne peut pas être entièrement pris en charge. Cela créera divers problèmes
         avec les changements de fuseau horaire et les ajustements à l'heure d'été. L'heure RTC
         n'est jamais mise à jour, elle dépend d'installations externes pour la maintenir.
         Si possible, utilisez RTC en UTC en appelant
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#
 

 Cela renvoie l'heure locale de votre hôte, l'heure UTC et l'heure RTC. Cela montre que l'heure du système est réglée sur America/New_York fuseau horaire (TZ ), le RTC est réglé sur l'heure du fuseau horaire local et le service NTP n'est pas actif. L'heure RTC a commencé à dériver un peu de l'heure système. Ceci est normal avec les systèmes dont les horloges n'ont pas été synchronisées. La quantité de dérive sur un hôte dépend du temps écoulé depuis la dernière synchronisation du système et de la vitesse de la dérive par unité de temps.
 

 Il y a aussi un message d'avertissement sur l'utilisation de l'heure locale pour le RTC—cela concerne les changements de fuseau horaire et les ajustements de l'heure d'été. Si l'ordinateur est éteint lorsque des modifications doivent être apportées, l'heure RTC ne changera pas. Ce n'est pas un problème dans les serveurs ou autres hôtes qui sont alimentés 24h/24 et 7j/7. De plus, tout service qui fournit la synchronisation de l'heure NTP s'assurera que l'hôte est réglé sur l'heure appropriée au début du processus de démarrage, de sorte qu'il sera correct avant qu'il ne soit complètement opérationnel.
 
Définir le fuseau horaire
 

 En règle générale, vous définissez le fuseau horaire d'un ordinateur au cours de la procédure d'installation et vous n'avez jamais besoin de le modifier. Cependant, il est parfois nécessaire de changer de fuseau horaire, et il existe quelques outils pour vous aider. Linux utilise des fichiers de fuseau horaire pour définir le fuseau horaire local utilisé par l'hôte. Ces fichiers binaires sont situés dans le répertoire /usr/share/zoneinfo annuaire. La valeur par défaut pour mon fuseau horaire est définie par le lien /etc/localtime -> ../usr/share/zoneinfo/America/New_York . Mais vous n'avez pas besoin de le savoir pour changer le fuseau horaire.
 

 Mais vous devez connaître le nom officiel du fuseau horaire de votre emplacement. Supposons que vous souhaitiez changer le fuseau horaire pour Los Angeles :
 
[root@testvm2 ~]# timedatectl list-timezones | colonne 

Amérique/La_Paz                  Europe/Budapest
Amérique/Lima                    Europe/Chisinau
Amérique/Los_Angeles             Europe/Copenhague
Amérique/Maceio        />Amérique/Managua                 Europe/Gibraltar
Amérique/Manaus                  Europe/Helsinki
 

 Vous pouvez maintenant définir le fuseau horaire. J'ai utilisé la date commande pour vérifier le changement, mais vous pouvez également utiliser timedatectl :
 
[root@testvm2 ~]# date
Mar 19 mai 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root @testvm2 ~]# date
Mar 19 mai 2020 13:48:23 PDT
[root@testvm2 ~]#
 

 Vous pouvez maintenant redéfinir le fuseau horaire de votre hôte sur votre fuseau horaire local.
 
systemd-timesyncd
 

 Le démon systemd timesync fournit une implémentation NTP facile à gérer dans un contexte systemd. Il est installé par défaut dans Fedora et Ubuntu et démarré par défaut dans Ubuntu mais pas dans Fedora. Je ne suis pas sûr des autres distributions ; vous pouvez vérifier le vôtre avec :
 
[root@testvm1 ~]# systemctl status systemd-timesyncd 
 
Configurer systemd-timesyncd
 

 Le fichier de configuration pour systemd-timesyncd est /etc/systemd/timesyncd.conf . Il s'agit d'un fichier simple avec moins d'options incluses que l'ancien service NTP et chronyd. Voici le contenu complet de la version par défaut de ce fichier sur ma VM Fedora :
 
#  Ce fichier fait partie de systemd.
#
#  systemd est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier
#  selon les termes de la licence publique générale limitée GNU telle que publiée par
#  la Free Software Foundation ; soit la version 2.1 de la licence, soit
#  (à votre choix) toute version ultérieure.
#
# Les entrées de ce fichier indiquent les valeurs par défaut de la date de compilation.
# Vous pouvez modifier paramètres en éditant ce fichier.
# Les valeurs par défaut peuvent être restaurées en supprimant simplement ce fichier.
#
# Voir timesyncd.conf(5) pour plus de détails.

[ Heure]
#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 seule section qu'il contient en plus des commentaires est [Time] , et toutes les lignes sont commentées. Ce sont les valeurs par défaut et n'ont pas besoin d'être modifiées ou décommentées (sauf si vous avez une raison de le faire). Si vous n'avez pas de serveur de temps NTP spécifique défini dans le NTP= ligne, la valeur par défaut de Fedora est de se rabattre sur le pool de serveurs de temps Fedora. J'aime ajouter le serveur de temps sur mon réseau à cette ligne :
 
NTP=myntpserver 
 
Démarrer la synchronisation de l'heure
 

 Le démarrage et l'activation de systemd-timesyncd sont comme n'importe quel autre service :
 
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Création du lien symbolique /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd -timesyncd.service.
Création d'un lien symbolique /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 ~]#
 
Régler l'horloge matérielle
 

 Voici à quoi ressemblait l'un de mes systèmes après le démarrage de timesyncd :
 
[root@testvm2 systemd]# timedatectl 
               Heure locale :Sam 2020-05-16 14:34:54 EDT  
           Heure universelle :Sam 2020-05-16 18:34:54 UTC  < 
          RTC dans TZ local :non    
 

 L'heure RTC est d'environ une seconde par rapport à l'heure locale (EDT), et l'écart augmente de quelques secondes supplémentaires au cours des prochains jours. Parce que RTC n'a pas le concept de fuseaux horaires, le timedatectl La commande doit effectuer une comparaison pour déterminer quel fuseau horaire correspond. Si l'heure RTC ne correspond pas exactement à l'heure locale, elle n'est pas considérée comme étant dans le fuseau horaire local.
 

 À la recherche d'un peu plus d'informations, j'ai vérifié l'état de systemd-timesync.service et j'ai trouvé :
 
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service 
● systemd-timesyncd.service - Synchronisation de l'heure du réseau
     Chargé :chargé (/usr/lib/systemd/system/systemd- timesyncd.service ; activé ; préréglage du fournisseur :désactivé)
     Actif :actif (en cours d'exécution) depuis le sam 2020-05-16 13:56:53 EDT ; Il y a 18 h
       Docs :man:systemd-timesyncd.service(8)
   PID principal :822 (systemd-timesyn)
     Statut :"Synchronisation initiale avec le serveur de temps 163.237.218.19:123 (2 .fedora.pool.ntp.org)."
      Tâches :2 (limite :10 365)
     Mémoire :2,8 M
        Processeur :476 ms
     CGroup :/system.slice/systemd -timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

16 mai 09:57:24 testvm2.both.org systemd[1] :Démarrage de la synchronisation de l'heure du réseau ...
16 mai 09:57:24 testvm2.both.org systemd-timesyncd[822] :L'heure de l'horloge système n'est pas réglée ou saute en arrière, restauration à partir de l'horodatage enregistré :Sam 2020-05-16 13:56:53 EDT
16 mai 13:56:53 testvm2.both.org systemd[1] :synchronisation de l'heure réseau démarrée.
16 mai 13:57:56 testvm2.both.org systemd-timesyncd[822] :Synchronisation initiale avec le serveur de temps 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#
 

 Notez le message de journal qui indique que l'heure de l'horloge système n'a pas été définie ou a sauté en arrière. Le service timesync définit l'heure système à partir d'un horodatage. Les horodatages sont conservés par le démon timesync et sont créés à chaque synchronisation temporelle réussie.
 

 Le timedatectl la commande n'a pas la possibilité de définir la valeur de l'horloge matérielle à partir de l'horloge système ; il ne peut définir l'heure et la date qu'à partir d'une valeur saisie sur la ligne de commande. Cependant, vous pouvez régler le RTC sur la même valeur que l'heure système en utilisant le hwclock commande :
 
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime 
[root@testvm2 ~]# timedatectl 
               Heure locale :lun 2020-05-18 13:56:46 EDT  
           Heure universelle :lun 2020-05-18 17:56:46 UTC  
                 Heure RTC :lun 2020-05-18 13:56:46      
                Fuseau horaire :ED America/New_York , -0400)
Horloge système synchronisée :oui                          
              Service NTP :actif                       
          RTC dans TZ local :oui
 

 Le --localtime garantit que l'horloge matérielle est réglée sur l'heure locale, et non sur UTC.
 
Avez-vous vraiment besoin de RTC ?
 

 Toute implémentation NTP règlera l'horloge système pendant la séquence de démarrage, RTC est-il donc nécessaire ? Pas vraiment, tant que vous disposez d'une connexion réseau à un serveur de temps. Cependant, de nombreux systèmes n'ont pas accès à plein temps à une connexion réseau, l'horloge matérielle est donc utile pour que Linux puisse la lire et régler l'heure du système. C'est une meilleure solution que d'avoir à régler l'heure à la main, même si elle peut s'éloigner de l'heure réelle.
 
Résumé
 

 Cet article a exploré l'utilisation de certains outils systemd pour gérer la date, l'heure et les fuseaux horaires. L'outil systemd-timesyncd fournit un client NTP décent qui peut garder l'heure sur un hôte local synchronisé avec un serveur NTP. Cependant, systemd-timesyncd ne fournit pas de service de serveur, donc si vous avez besoin d'un serveur NTP sur votre réseau, vous devez utiliser autre chose, comme Chrony, pour agir en tant que serveur.
 

 Je préfère avoir une seule implémentation pour n'importe quel service de mon réseau, j'utilise donc Chrony. Si vous n'avez pas besoin d'un serveur NTP local, ou si cela ne vous dérange pas de traiter avec Chrony pour le serveur et systemd-timesyncd pour le client et que vous n'avez pas besoin des capacités supplémentaires de Chrony, alors systemd-timesyncd est un choix utile pour un client NTP .
 

 Il y a un autre point que je veux souligner :vous n'avez pas besoin d'utiliser les outils systemd pour l'implémentation NTP. Vous pouvez utiliser l'ancien ntpd ou Chrony ou une autre implémentation NTP. systemd est composé d'un grand nombre de services; beaucoup d'entre eux sont facultatifs, ils peuvent donc être désactivés et quelque chose d'autre peut être utilisé à sa place. Ce n'est pas l'énorme monstre monolithique que certains prétendent être. C'est bien de ne pas aimer systemd ou des parties de celui-ci, mais vous devez prendre une décision éclairée.
 

 Je n'aime pas l'implémentation de NTP par systemd, mais je préfère de loin Chrony car il répond mieux à mes besoins. Et c'est de cela qu'il s'agit.
 
Ressources
 

 De nombreuses informations sur systemd sont disponibles sur Internet, mais la plupart sont concises, obtuses ou même trompeuses. En plus des ressources mentionnées dans cet article, les pages Web suivantes offrent des informations plus détaillées et fiables sur le démarrage de systemd.
 
 
Le projet Fedora propose un bon guide pratique de systemd. Il contient à peu près tout ce que vous devez savoir pour configurer, gérer et entretenir un ordinateur Fedora à l'aide de systemd.
 
Le projet Fedora a également une bonne feuille de triche qui renvoie les anciennes commandes SystemV à des commandes systemd comparables.
 
Pour des informations techniques détaillées sur systemd et les raisons de sa création, consultez la description de systemd par Freedesktop.org.
 
Linux.com's "More systemd fun" propose des informations et des conseils plus avancés sur systemd.
 
 

 Il existe également une série d'articles profondément techniques pour les administrateurs système Linux par Lennart Poettering, le concepteur et développeur principal de systemd. Ces articles ont été écrits entre avril 2010 et septembre 2011, mais ils sont tout aussi pertinents aujourd'hui qu'ils l'étaient alors. Une grande partie de tout ce qui a été écrit sur systemd et son écosystème est basé sur ces articles.
 
 
Repenser le PID 1
 
systemd pour les administrateurs, partie I
 
systemd pour les administrateurs, partie II
 
systemd pour les administrateurs, partie III
 
systemd pour les administrateurs, partie IV
 
systemd pour les administrateurs, partie V
 
systemd pour les administrateurs, partie VI
 
systemd pour les administrateurs, partie VII
 
systemd pour les administrateurs, partie VIII
 
systemd pour les administrateurs, partie IX
 
systemd pour les administrateurs, partie X
 
systemd pour les administrateurs, partie XI