Horloges dans un système Linux¶

Deux types d’horloge existent.

L’horloge matérielle : cette horloge est un périphérique matériel indépendant, avec son propre système électrique (pile, condensateur, etc.) qui fonctionne quand la machine est éteinte, ou même débranchée.

Sur un système compatible ISA, l’horloge est définie dans la norme ISA. Un programme de contrôle ne peut lire ou ajuster l’heure qu’à la seconde, mais il peut également détecter les pentes des tics d’une seconde de l’horloge, de ce fait, l’horloge a virtuellement une précision infinie.

Cette horloge est communément appelée l’horloge matérielle (« hardware clock »), l’horloge temps réel, le RTC, l’horloge BIOS ou l’horloge CMOS. La désignation horloge matérielle a été inventée pour être utilisée avec hwclock. Le noyau Linux y fait référence sous le nom d’horloge persistante.

Certains systèmes non ISA ont plusieurs horloges temps réel, mais une seule avec sa propre source d'énergie. Un composant externe, sur I2C ou SPI, consommant très peu, peut être utilisé avec une batterie de secours comme horloge matérielle afin d’initialiser une horloge temps réel intégrée plus fonctionnelle, utilisée pour la plupart des autres objectifs.

L’horloge système : cette horloge fait partie du noyau Linux et est contrôlée par une minuterie (sur une machine ISA, les interruptions de minuterie font partie de la norme ISA). Cela n'a de sens que si Linux fonctionne sur la machine. L’heure système est le nombre de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC (ou plus succinctement, le nombre de secondes depuis 1969 UTC). L’heure système n’est pas un entier. Elle a virtuellement une précision infinie.

L’horloge système donne l’heure importante. Le but essentiel de l’horloge matérielle est de garder l’heure lorsque Linux ne fonctionne pas afin de pourvoir initialiser l’heure système au démarrage. Remarquez qu'avec DOS, pour qui ISA a été conçu, l’horloge matérielle est la seule horloge temps réel.

L’heure système ne doit surtout pas subir de discontinuité comme lorsque le programme date(1) est utilisé pour la modifier pendant le fonctionnement du système. Vous pouvez, cependant, faire tout ce que vous voulez sur l’horloge matérielle pendant le fonctionnement, la prochaine fois que Linux démarrera, il prendra en compte la nouvelle heure de l’horloge matérielle. Remarque : ce n’est actuellement pas possible sur la plupart des systèmes car hwclock --systohc est appelée lors de l’arrêt.

Le fuseau horaire du noyau Linux est défini par hwclock. Cependant, ne vous trompez pas — pratiquement personne ne se préoccupe du fuseau horaire maintenu par le noyau. Les programmes devant utiliser le fuseau horaire (par exemple pour afficher l’heure locale) utilisent presque toujours une méthode plus traditionnelle afin de le déterminer. Ils utilisent la variable d'environnement TZ ou le fichier /etc/localtime, comme expliqué dans la page de manuel de tzset(3). Cependant, certains programmes et certaines parties du noyau Linux comme les systèmes de fichiers utilisent la valeur de fuseau horaire du noyau. Un exemple est le système de fichiers vfat. Si la valeur dans le noyau est fausse, le système de fichiers vfat lira et modifiera d'une manière erronée la date des fichiers. Un autre exemple est le « mode 11 minutes » de NTP du noyau. Si la valeur de fuseau horaire du noyau ou que la variable persistent_clock_is_local sont fausses, l’horloge matérielle ne sera pas réglée correctement par le « mode 11 minutes ». Consultez la discussion ci-dessous, sous Synchronisation automatique de l’horloge matérielle par le noyau.

hwclock ajuste le fuseau horaire du noyau à la valeur indiquée par TZ ou /etc/localtime avec les fonctions --hctosys ou --systz.

Le fuseau horaire du noyau est composé de deux parties : 1) un champ tz_minuteswest indiquant le nombre de minutes (non ajusté pour l’heure d'été) de retard par rapport au temps universel (UTC) ; 2) un champ tz_dsttime indiquant le type de convention d’heure d’été utilisé localement à l’heure actuelle. Ce second champ n'est jamais utilisé sous Linux et est toujours nul. Consultez également settimeofday(2).

Méthodes d’accès à l’horloge matérielle¶

hwclock utilise divers moyens pour interroger et régler les valeurs de l’horloge matérielle. La façon la plus normale est de réaliser des entrées et sorties avec le fichier spécial de périphérique rtc qui est supposé être piloté par le pilote de périphérique RTC. De plus, les systèmes Linux utilisant l’environnement de pilote RTC avec udev sont capables de prendre en charge plusieurs horloges matérielles. Cela pourrait nécessiter d’écraser le périphérique rtc par défaut en indiquant un autre à l’aide de l’option --rtc.

Cependant, cette méthode n’est pas toujours disponible sur les anciens systèmes ne disposant pas de pilote rtc. Sur ces systèmes, la méthode d'accès à l’horloge matérielle dépend de la machine.

Sur un système compatible ISA, hwclock peut accéder directement aux registres de la mémoire du CMOS qui constituent l’horloge, en effectuant des opérations d'E/S sur les ports 0x70 et 0x71. hwclock effectue cela avec de véritables instructions d'E/S et doit donc être exécuté avec des droits de superutilisateur. Cette méthode peut être utilisée en indiquant l’option --directisa.

C'est vraiment une mauvaise méthode pour accéder à l’horloge, notamment parce que les programmes de l'espace utilisateur ne sont généralement pas supposés effectuer directement des opérations d'E/S et désactiver les interruptions. hwclock fournit cette méthode pour permettre de faire des essais ou du dépannage et parce que cela pourrait être la seule méthode disponible sur les systèmes compatibles ISA ne disposant pas d’un pilote fonctionnel de périphérique rtc.

La fonction d’ajustement¶

L’horloge matérielle n'est généralement pas très précise. Cependant, la plupart de ces imprécisions sont prévisibles. Elle gagne ou perd la même durée chaque jour. C’est la dérive systématique. La fonction --adjust de hwclock permet d’appliquer des corrections de dérive systématique à l’horloge matérielle.

Cela fonctionne de la façon suivante : hwclock utilise un fichier, /etc/adjtime, qui conserve des informations historiques. C’est le fichier d'ajustement (adjtime).

Supposons un démarrage sans fichier d'ajustement. La commande hwclock --set règle l’horloge matérielle à l’heure actuelle. hwclock crée le fichier d’ajustement et y sauvegarde l’heure actuelle en tant que dernier moment d’étalonnage. Cinq jours plus tard, l’horloge a gagné 10 secondes, la commande hwclock --set --update-drift corrige alors l’heure. hwclock met à jour le fichier d'ajustement avec l’heure actuelle en tant que dernier moment d’étalonnage, et enregistre une dérive systématique de 2 secondes par jour. Au bout de 24 heures, avec la commande hwclock --adjust, hwclock consulte le fichier d'ajustement et remarque que l’horloge gagne deux secondes par jour lorsque rien n'est fait et que rien n'a été fait pendant un jour. Par conséquent, 2 secondes sont enlevées de l’horloge matérielle. L’heure actuelle est alors enregistrée en tant que dernier moment d’étalonnage. 24 heures après, la commande hwclock --adjust effectuera exactement la même opération.

Quand l’option --update-drift est utilisée avec --set ou --systohc, le taux de dérive systématique est (re)calculé en comparant l’heure matérielle actuelle avec correction de dérive à la nouvelle heure de réglage. En est déduit le taux de dérive sur 24 heures à partir du dernier horodatage de calibration du fichier d’ajustement. Ce facteur de dérive mis à jour est sauvé dans /etc/adjtime.

Une petite erreur est introduite quand l’horloge matérielle est définie, de telle sorte que --adjust évite de faire un ajustement de moins d'une seconde. Plus tard, lors d’une redemande d’ajustement, la dérive accumulée sera supérieure à une seconde et --adjust fera l'ajustement même de toute partie infime.

hwclock --hctosys utilise aussi les données du fichier d’ajustement pour compenser la valeur lue de l’horloge matérielle avant de l’utiliser pour régler l’horloge système. La limitation d’une seconde de --adjust ne s’applique pas et les valeurs de décalage inférieures à la seconde seront corrigées immédiatement. L’horloge matérielle et le fichier d’ajustement ne sont pas modifiés. Cela devrait éliminer la nécessité d’utiliser --adjust sauf si autre chose sur le système a besoin de voir l’horloge matérielle compensée.

Le fichier d'ajustement¶

Même s’il garde ce nom pour des raisons historiques, il contient en fait d'autres informations utilisées par hwclock d’un appel à l'autre.

Le format du fichier d'ajustement, en ASCII, est le suivant :

Ligne 1 : trois nombres, séparés par des espaces : 1) le taux de dérive systématique en seconde par jour, nombre décimal flottant ; 2) le nombre de secondes écoulées entre 1969 UTC et la date du dernier étalonnage, entier décimal ; 3) zéro (pour une compatibilité avec clock(8)) en tant que nombre décimal flottant.

Ligne 2 : un nombre : le nombre de secondes écoulées entre 1969 UTC et le dernier étalonnage. Zéro s'il n'y a pas eu d'étalonnage ou si un des derniers étalonnages est discutable (par exemple, si l’horloge matérielle, depuis cet étalonnage, est erronée). C'est un entier décimal.

Ligne 3 : « UTC » ou « LOCAL ». Indique si l’horloge matérielle est à l’heure universelle ou à l’heure locale. Vous pouvez toujours surcharger cette valeur par des options sur la ligne de commande de hwclock.

Vous pouvez utiliser un fichier d'ajustement précédemment utilisé avec le programme clock(8) avec hwclock.

Synchronisation automatique de l’horloge matérielle par le noyau¶

Vous devez être au courant d'un autre moyen utilisé pour garder l’horloge matérielle synchronisée sur certains systèmes. Le noyau Linux possède un mode qui copie l’heure système vers l’horloge matérielle toutes les 11 minutes. Ce mode est une option au moment de la compilation, aussi tous les noyaux n’ont pas cette possibilité. Il est pratique de l’utiliser quand un moyen sophistiqué comme NTP garde l’heure système à jour (NTP est un moyen de synchroniser l’heure système avec soit un serveur de temps situé quelque part sur le réseau, soit une horloge radio en duplex avec le système, consultez la RFC 1305).

Si le noyau est compilé avec l’option « mode 11 minutes », il sera actif quand la discipline de l’horloge du noyau est dans l’état synchronisé. Dans cet état, le bit 6 (le bit réglé dans le masque 0x0040) de la variable time_status du noyau n’est pas défini. Cette valeur est produite comme ligne « status » des commandes adjtimex --print ou ntptime.

Il agit de manière externe, comme le démon NTP pour mettre la discipline de l'horloge du noyau dans l’état synchronisé et, par conséquent, active le « mode 11 minutes ». Il peut être désactivé en exécutant n'importe quelle commande, y compris hwclock --hctosys qui ajuste l’horloge système de manière classique. Cependant, si le démon NTP est toujours actif, il réactivera le « mode 11 minutes » la prochaine fois qu’il synchronisera l’horloge système.

Si le « mode 11 minutes » est activé sur le système, l’utilisation de --hctosys ou --systz risque d’être nécessaire dans un script de démarrage, en particulier si l’horloge matérielle est configurée pour utiliser le fuseau horaire local. À moins que le noyau ne soit informé du fuseau horaire utilisé par l’horloge matérielle, il risque de l’écraser avec une heure incorrecte. Le noyau utilise UTC par défaut.

La première commande en espace utilisateur pour définir l’horloge système informe le noyau du fuseau horaire utilisé par l’horloge matérielle. Cela ce fait par l’intermédiaire de la variable persistent_clock_is_local du noyau. Si --hctosys ou --systz sont utilisées en premier, cette variable sera définie d’après le fichier d’ajustement ou l’argument approprié en ligne de commande. Remarquez que lorsque cette capacité est utilisée et que le fuseau horaire de l’horloge matérielle est modifié, un redémarrage est nécessaire pour informer le noyau.

hwclock --adjust ne devrait pas être utilisée avec le « mode 11 minutes » de NTP.

Valeur du siècle de l’horloge matérielle ISA¶

Une sorte de norme définit l’octet 50 de la mémoire du CMOS sur une machine ISA comme un indicateur du siècle. hwclock ne l'utilise ni ne le modifie car certaines machines ne définissent pas l'octet de cette manière, et ce n'est vraiment pas nécessaire puisque l'année du siècle constitue un bon moyen de connaître le siècle.

Si vous pensez à un usage possible de l'octet du siècle CMOS (« CMOS century byte »), contactez le responsable de hwclock, une option peut être adéquate.

Notez que cette section est pertinente uniquement si vous utilisez un accès ISA direct à l’horloge matérielle. L'ACPI fournit un moyen standard d'accéder au siècle quand le matériel le gère.

Garder l’heure sans synchronisation externe¶

Cette discussion est basée sur les conditions suivantes.

Que la précision de l’heure soit maintenue avec le démon NTP ou pas, configurer le système pour qu’il reste à l’heure par lui-même est utile.

La première étape pour réaliser cela est d’avoir une vision d’ensemble claire. Deux périphériques matériels indépendants fonctionnent à leur propre rythme et divergent de l’heure « correcte » à leur propre taux. Les méthodes et programmes pour la correction de dérive sont différents pour chaque périphérique. Cependant, la plupart des systèmes sont configurés pour échanger des valeurs entre ces deux horloges au démarrage et à l’arrêt. Désormais les heures de chaque périphérique, avec leurs propres erreurs, sont donc transférées de l’une à l’autre dans les deux sens. Si vous tentez de configurer une correction de dérive pour une seule d’entre elles, la dérive de l’autre l’écrasera.

Ce problème peut être évité en configurant la correction de dérive pour l’horloge système et en évitant simplement d’arrêter la machine. Cela, avec le fait que toute la précision de hwclock (y compris le calcul des facteurs de dérive) dépend de l’exactitude de la fréquence de l’horloge système, signifie que la configuration de l’horloge système devrait être la première étape.

La dérive de l’horloge système est corrigée avec les options --tick et --frequency d’adjtimex(8). Les deux fonctionnent ensemble, le tic est l’ajustement grossier alors que la fréquence est l’ajustement fin (sur les systèmes sans paquet adjtimex, ntptime -f ppm peut être utilisé à la place).

Certaines distributions Linux essayent de calculer automatiquement la dérive de l’horloge système avec l’opération de comparaison d’adjtimex. Essayer de corriger une horloge qui dérive en utilisant comme référence une autre horloge qui dérive est un peu comme un chien qui essaye de s’attraper la queue. Cela peut fonctionner au bout d’un moment mais pas sans beaucoup d’efforts et de frustration. Cet automatisme peut être considéré comme une amélioration face à l’absence de configuration, mais espérer un résultat optimal serait une erreur. Les options --log d’adjtimex s’avèrent être une meilleure possibilité pour une configuration manuelle.

Simplement suivre la dérive de l’horloge système avec sntp, ou date -Ins par rapport à une horloge de précision, puis calculer soi-même la correction, serait plus efficace.

Après la définition des valeurs de tic et de fréquence, il faut continuer de tester et d'affiner les ajustements jusqu’à ce que l’horloge système garde l’heure correctement. Consultez adjtimex(2) pour plus de renseignements et l’exemple montrant un calcul manuel de dérive.

Une fois que l’horloge système est fiable, l’horloge matérielle va pouvoir être réglée.

En règle générale, la dérive à froid fonctionne bien dans la plupart des cas d’utilisation. Cela devrait même être vrai pour les machines fonctionnant vingt-quatre heures sur vingt-quatre et dont les temps d’arrêt usuels servent uniquement pour les redémarrages. Dans ce cas, la valeur du facteur de dérive est peu différente, mais si la machine est arrêtée plus longtemps que d’habitude, la dérive à froid devrait donner de meilleurs résultats.

Étapes pour calculer la dérive à froid

1

2

3

4

5

6

Remarque : si l’étape six utilise --systohc, alors l’horloge système doit être réglée correctement (étape 6a) juste avant.

Laisser hwclock calculer le facteur de dérive est un bon point de départ, mais pour obtenir des résultats optimaux, modifier directement le fichier /etc/adjtime sera probablement nécessaire. Continuer de tester et affiner les ajustements jusqu’à ce que l’horloge matérielle soit corrigée correctement au démarrage. Pour vérifier cela, assurez-vous que l’heure système soit correcte avant l’arrêt puis utilisez sntp, ou date -Ins et une horloge de précision, immédiatement après le démarrage.

LOCALE ou UTC¶

Garder l’horloge matérielle en heure locale provoque des résultats incohérents de changement d’heure d’été.

L’horloge matérielle sur un système compatible ISA ne garde que l’heure et la date, elle n’a pas de connaissance du fuseau horaire ni d’heure d’été. Ainsi, quand hwclock est informée d’utiliser l’heure locale, elle considère l’horloge matérielle en heure locale « correcte » et ne fait pas d’ajustement de l’heure qui y est lue.

Linux ne gère les changements d’heure d’été de façon transparente que quand l’horloge matérielle est gardée en UTC. Ce fonctionnement facilite le travail des administrateurs système car hwclock utilise l’heure locale en sortie et comme argument de l’option --date.

Les systèmes POSIX, comme Linux, sont conçus pour avoir l’horloge système en heure UTC. Le but de l’horloge matérielle est d’initialiser l’horloge système, donc la garder aussi en UTC est sensé.

Linux, cependant, essaye de s’adapter à l’horloge matérielle en heure locale. C’est avant tout pour gérer le multiboot avec les plus anciennes versions de Microsoft Windows. Depuis Windows 7, la clef de registre RealTimeIsUniversal est supposée fonctionner correctement pour permettre de garder l’horloge matérielle en UTC.

POSIX ou « RIGHT »¶

Une discussion sur la configuration de date et d’heure serait incomplète sans parler de fuseaux horaires, c’est assez bien couvert par tzset(3). Une zone qui semble non documentée est le répertoire right de la base de données de fuseaux horaires, parfois appelé « tz » ou « zoneinfo ».

Deux bases de données distinctes existent dans le système « zoneinfo » : posix et « right ». Le répertoire « right » (maintenant appelé zoneinfo-leaps — secondes intercalaires de zoneinfo) contient les secondes intercalaires alors que posix ne les contient pas. Pour utiliser la base de données « right », l’horloge système doit être configurée en (UTC + secondes intercalaires), ce qui est équivalent à (TAI − 10). Cela permet de calculer le nombre exact de secondes entre deux dates ayant une seconde intercalaire entre elles. L’horloge système est alors convertie en heure civile correcte, y compris UTC, en utilisant les fichiers de fuseau horaire « right » qui soustraient les secondes intercalaires. Remarque : cette configuration est considérée expérimentale et est connue pour poser des problèmes.

Pour configurer un système à utiliser une base de données particulière, tous les fichiers de son répertoire doivent être copiés à la racine de /usr/share/zoneinfo. Les fichiers ne sont jamais utilisés directement des sous-répertoires posix ou « right », par exemple TZ='right/Europe/Dublin'. Cette habitude était devenue si répandue que le projet zoneinfo amont a restructuré le système d’arborescence de fichiers en déplaçant les sous-répertoires posix et « right » hors du répertoire zoneinfo et dans des répertoires frères :

/usr/share/zoneinfo, /usr/share/zoneinfo-posix, /usr/share/zoneinfo-leaps

Malheureusement, certaines distributions Linux replacent l’arborescence comme précédemment dans leurs paquets. Ainsi, le problème des administrateurs système utilisant directement le répertoire « right » persiste. À cause de cela, le fuseau horaire du système est configuré pour inclure les secondes intercalaires alors que la base de données de zoneinfo est encore configurée pour les exclure. Pourtant, quand une application comme une horloge mondiale, un agent de transport de courrier (MTA) ou hwclock a besoin du fichier de fuseau horaire South_Pole, elle le prend à la racine du /usr/share/zoneinfo, puisque c’est ce qu’elle est censée faire. Ces fichiers excluent les secondes intercalaires, mais l’horloge système les inclut maintenant, avec pour conséquence une conversion d’heure incorrecte.

Tenter de mélanger et de faire correspondre les fichiers de ces bases de données distinctes ne fonctionnera pas puisqu’elles nécessitent chacune que l’horloge système utilise un fuseau horaire différent. La base de données zoneinfo doit être configurée pour utiliser soit posix, soit « right », conformément à la description précédente ou en assignant un chemin de base de données à la variable