Provided by: manpages-fr-extra_20151231_all 
NOM
hwclock - Lire ou ajuster l’horloge matérielle (RTC)
SYNOPSIS
hwclock [fonction] [option ... ]
DESCRIPTION
hwclock permet d'accéder à l’horloge matérielle. Elle permet : d’afficher l’heure actuelle
de l’horloge matérielle ; de modifier l’heure de l’horloge matérielle ; de mettre
l’horloge matérielle à l’heure système ; de mettre l’horloge système à l’heure de
l’horloge matérielle ; de compenser la dérive de l’horloge matérielle ; de corriger le
fuseau horaire de l’horloge matérielle ; de définir le fuseau horaire du noyau, le fuseau
horaire de NTP, et l’époque (seulement sur Alpha) ; de comparer les horloges système et
matérielle ; de prédire les prochaines valeurs de l’horloge matérielle à partir de son
taux de dérive.
Depuis la version 2.26, des modifications importantes ont été faites à la fonction
--hctosys, à l’option --directisa et une nouvelle option --update-drift a été ajoutée.
Consultez leurs sections respectives ci-dessous.
FONCTIONS
Les fonctions suivantes s’excluent mutuellement, une seule peut être indiquée à la fois.
Si aucune n’est indiquée, --show est utilisée par défaut.
--adjust
Ajouter ou retirer du temps à l’horloge matérielle pour tenir compte de la dérive
systématique depuis la dernière fois où l’horloge a été ajustée. Consultez la
discussion ci-dessous, sous La fonction d'ajustement.
-c, --compare
Comparer périodiquement l’heure matérielle à l’heure système et afficher la
différence toutes les 10 secondes. Cela affichera aussi le décalage de fréquence et
le tic.
--getepoch
--setepoch
Ces fonctions sont seulement pour les machines Alpha.
Lire et définir la valeur d’époque de l’horloge matérielle. C’est l’année
grégorienne qui correspond à la valeur zéro du champ année de l’horloge matérielle.
Par exemple, si vous utilisez la convention du champ année de l’horloge matérielle
qui contient le nombre d'années depuis 1952, la valeur d’époque de l’horloge
matérielle pour le noyau doit être 1952.
La fonction --setepoch nécessite l’utilisation de l’option --epoch.
La valeur de l'époque est utilisée à chaque fois que hwclock lit ou ajuste
l’horloge matérielle.
--predict
Prédire ce que l’horloge matérielle lira dans le futur à partir de l’heure donnée
par l’option --date et des renseignements de /etc/adjtime. C’est utile, par
exemple, pour prendre en compte la dérive lors de la définition d’un réveil
(alarme) par l’horloge matérielle. Consultez rtcwake(8).
N’utilisez pas cette fonction si l’horloge matérielle est modifiée par autre chose
que la commande hwclock du système d’exploitation actuel, comme le « mode
11 minutes » ou un autre système d’exploitation en multiboot.
-r, --show
--get
Lire l’heure matérielle et l’afficher sur la sortie standard. L’heure affichée est
toujours en heure locale, même si l’horloge matérielle est en temps universel.
Consultez l'option --localtime.
Montrer l’horloge matérielle est l'action par défaut si aucune fonction n'est
indiquée.
La fonction --get applique aussi la correction de dérive à l’heure lue, à partir
des renseignements de /etc/adjtime. N’utilisez pas cette fonction si l’horloge
matérielle est modifiée par autre chose que la commande hwclock du système
d’exploitation actuel, comme le « mode 11 minutes » ou un autre système
d’exploitation en multiboot.
-s, --hctosys
Mettre l’heure système à l’heure de l’horloge matérielle. L’heure lue de l’horloge
matérielle est compensée pour prendre en compte la dérive systématique avant de
l’utiliser pour définir l’heure système. Consultez la discussion ci-dessous, sous
La fonction d'ajustement.
L’horloge système doit être gardée en UTC pour que les applications de date et
heure fonctionnent correctement avec le fuseau horaire configuré sur le système. Si
l’horloge matérielle est conservée en heure locale, alors l’heure qui y est lue
doit être convertie en UTC avant de l’utiliser pour définir l’horloge système. La
fonction --hctosys le fait à partir des renseignements du fichier /etc/adjtime ou
des arguments --localtime et --utc en ligne de commande. Remarque : aucun
ajustement d’heure d’été n’est réalisé. Consultez la discussion ci-dessous sous
LOCALE ou UTC.
Le noyau garde aussi une valeur de fuseau horaire, la fonction --hctosys la définit
au fuseau configuré pour le système. Le fuseau horaire système est configuré par la
variable d'environnement TZ ou le fichier /etc/localtime, tels que tzset(3) les
interpréterait. Le champ obsolète tz_dsttime du noyau est mis à zéro (pour plus de
précisions sur ce que ce champ signifiait, consultez settimeofday(2)).
Lors d’une utilisation dans un script de démarrage, si la fonction --hctosys est la
première à appeler settimeofday(2) depuis le démarrage, cela définira le « mode
11 minutes » de NTP par l’intermédiaire de la variable persistent_clock_is_local du
noyau. Si la configuration du fuseau horaire de l’horloge matérielle est modifiée,
alors un redémarrage est nécessaire pour informer le noyau. Consultez la discussion
ci-dessous, sous Synchronisation automatique de l’horloge matérielle par le noyau.
C’est une fonction particulièrement utile dans un des scripts de démarrage avant
que les systèmes de fichiers ne soient montés en lecture et écriture.
Cette fonction ne devrait jamais être utilisée sur un système en fonctionnement.
Les sauts d’horloge système provoqueront des problèmes comme par exemple des
horodatages corrompus sur le système de fichiers. Ainsi, si quelque chose a modifié
l’horloge matérielle, comme le « mode 11 minutes » de NTP, --hctosys définira
l’heure de façon incorrecte en incluant la compensation de dérive.
La compensation de dérive peut être inhibée en définissant le facteur de dérive à
zéro dans /etc/adjtime. Ce réglage sera persistant tant que l’option --update-drift
n’est pas utilisée avec --systohc à l’arrêt (ou n’importe quand). Une autre façon
d’inhiber cela est d’utiliser l’option --noadjfile en appelant la fonction
--hctosys. Une troisième méthode est d’effacer le fichier /etc/adjtime. hwclock
utilisera alors UTC par défaut pour l’horloge matérielle. Si l’horloge matérielle
est à l’heure locale, elle devra être définie dans le fichier. Cela peut être fait
en appelant hwclock --localtime --adjust ; quand le fichier n’est pas présent,
cette commande n’ajustera pas vraiment l’horloge, mais créera le fichier avec
l’heure locale configurée et un facteur de dérive à zéro.
Une condition sous laquelle l’inhibition de correction de dérive de hwclock peut
être utile est lorsque plusieurs systèmes sont utilisés en multiboot. Pendant que
cette instance de Linux est arrêtée, si un autre système d’exploitation modifie la
valeur de l’horloge matérielle, la correction de dérive appliquée sera incorrecte
quand cette instance redémarrera.
Pour que la correction de dérive de hwclock fonctionne correctement, rien ne doit
modifier l’horloge matérielle pendant que cette instance de Linux n’est pas en
fonctionnement.
--set Mettre l’horloge matérielle à l’heure donnée par l'option --date, et mettre à jour
les horodatages dans /etc/adjtime. Avec l’option --update-drift, recalculer le
facteur de dérive.
--systz
C'est une alternative à la fonction --hctosys qui ne lit pas l’horloge matérielle
et n’ajuste pas l’horloge système ; par conséquent, aucune correction de dérive
n’est effectuée. Elle est conçue pour être utilisée dans un script de démarrage sur
les systèmes avec des noyaux de version supérieure à 2.6 où l’horloge système a été
ajustée depuis l’horloge matérielle par le noyau lors du démarrage.
Elle procède aux actions suivantes qui sont détaillées ci-dessus dans la fonction
--hctosys :
• correction du fuseau horaire de l’horloge matérielle en UTC si nécessaire.
Seulement, au lieu d’accomplir cela en réglant l’horloge système, hwclock informe
simplement le noyau qui se charge de la modification ;
• activation du « mode 11 minutes » de NTP du noyau ;
• définition du fuseau horaire du noyau.
Les deux premières actions ne sont disponibles que lors du premier appel de
settimeofday(2) après le démarrage. Par conséquent, cette option n’a de sens que
dans un script de démarrage. Si la configuration du fuseau horaire de l’horloge
matérielle est modifiée, un redémarrage serait nécessaire pour informer le noyau.
-w, --systohc
Mettre l’horloge matérielle à l’heure système, et mettre à jour les horodatages
dans /etc/adjtime. Avec l’option --update-drift, recalculer le facteur de dérive.
-V, --version
Afficher les informations sur la version et quitter.
-h, --help
Afficher un texte d'aide puis quitter.
OPTIONS
--adjfile=fichier
Remplacer le chemin de fichier par défaut /etc/adjtime.
--badyear
Indiquer que l’horloge matérielle est incapable de stocker les années qui ne sont
pas comprises entre 1994 et 1999. C'est un problème lié à certains BIOS (quasiment
tous les « Award BIOS » fabriqués entre le 26/04/94 et le 31/05/95) qui sont
incapables de gérer les années supérieures à 1999. Si on essaie d'affecter une
année inférieure à 94 (ou 95 dans certains cas), la valeur réellement affectée est
94 (ou 95). Donc, si vous possédez une de ces machines, hwclock ne peut pas
affecter une année supérieure à 1999 et ne peut donc pas utiliser la valeur de
l’horloge comme une valeur normale.
Afin de compenser cela (sans mettre à jour le BIOS, ce qui est pourtant
préférable), vous devez toujours utiliser --badyear si vous possédez une de ces
machines. Quand hwclock sait que l’horloge est endommagée, il ignore la valeur de
l'année de l’horloge matérielle, et essaie de deviner l'année grâce à la date du
dernier étalonnage sauvegardé dans le fichier d'ajustement, en supposant que cette
date fait partie de l'année en cours. Pour que cela fonctionne, vous feriez mieux
d'exécuter hwclock --set ou hwclock --systohc au moins une fois par an !
Bien que hwclock ignore l’année en lisant l’horloge matérielle, elle modifie
l’année lors du réglage de l’horloge. Elle met alors l'année à 1995, 1996, 1997, ou
1998, suivant celle qui a la même position dans le cycle des années bissextiles que
la véritable année. De cette façon, l’horloge matérielle insère les jours des
années bissextiles où il faut. À nouveau, si vous n’ajustez pas l’horloge
matérielle pendant plus d'une année, cela ne fonctionnera pas et un jour risque
d'être perdu.
hwclock avertit que --badyear est probablement nécessaire quand l'année de
l’horloge matérielle est 1994 ou 1995.
--date=chaîne_date
Cette option n'est nécessaire qu'avec les fonctions --set ou --predict, sinon, elle
est ignorée. Elle indique l’heure à laquelle l’horloge matérielle sera initialisée,
ou l’heure à laquelle prédire l’horloge matérielle. La valeur de cette option est
utilisée comme argument de l’option --date de date(1). Par exemple,
hwclock --set --date='2011-08-14 16:45:05'
L’argument doit être en heure locale, même si l’horloge matérielle est en UTC.
Consultez l’option --localtime. L’argument ne doit pas être en temps relatif, comme
par exemple « +5 minutes » car la précision de hwclock dépend de la corrélation
entre la valeur de l’argument et le moment où la touche Entrée est pressée.
--debug
Afficher beaucoup d'informations sur les actions internes d'hwclock. Certaines de
ses fonctions sont complexes et cette sortie permet de comprendre ce que le
programme fait.
--directisa
Cette option est utile pour les machines compatibles ISA, y compris x86 et x86_64,
ou Alpha (qui a une interface d’horloge matérielle similaire). Pour les autres
machines, cela n'a pas d'impact. Cette option indique à hwclock d'utiliser des
instructions d’entrée et sortie explicites pour accéder à l’horloge matérielle.
Sans cette option, hwclock essaiera d'utiliser le périphérique rtc, supposé piloté
par le pilote de périphérique RTC. Depuis la version 2.26, --directisa n’est plus
automatiquement utilisé quand le pilote rtc n’est pas disponible ; cela provoquait
une condition non sécurisée qui pouvait permettre à deux processus d’accéder à
l’horloge matérielle en même temps. L’accès direct au matériel depuis l’espace
utilisateur ne devrait être utilisé que pour des essais, du dépannage ou en dernier
recours après échec de toutes les autres méthodes. Consultez l’option --rtc.
-f, --rtc=fichier
Remplacer le nom de fichier du périphérique rtc par défaut de hwclock. Sinon, le
premier trouvé sera utilisé, dans cet ordre :
/dev/rtc
/dev/rtc0
/dev/misc/rtc
Pour IA-64 :
/dev/efirtc
/dev/misc/efirtc
--localtime
-u, --utc
Indiquer le fuseau horaire utilisé par l’horloge matérielle.
L’horloge matérielle peut être configurée pour utiliser soit UTC, soit le fuseau
horaire local, mais rien n’indique dans l’horloge elle-même l’alternative utilisée.
Les options --localtime et --utc indiquent cela à la commande hwclock. Si vous
indiquez la mauvaise information (ou n’en indiquez aucune et que la valeur par
défaut est incorrecte), à la fois le réglage et la lecture de l’horloge matérielle
seront incorrectes.
Si vous n'indiquez ni --utc ni --localtime, la valeur utilisée la dernière fois
avec une fonction de définition (--set, --systohc ou --adjust), comme sauvegardée
dans /etc/adjtime, sera utilisée. Si le fichier d'ajustement n'existe pas, UTC est
choisie.
Remarque : les modifications d’heure d’été peuvent être incohérentes quand
l’horloge matérielle est gardée en heure locale. Consultez la discussion ci-dessous
sous LOCALE ou UTC.
--noadjfile
Ne pas tenir compte de /etc/adjtime. hwclock ne lira ni n'écrira dans ce fichier.
L'option --utc ou --localtime doit obligatoirement être indiquée avec cette option.
--test Ne pas vraiment faire de modification sur le système, c’est-à-dire ni sur les
horloges, ni sur le fichier d’ajustement. C’est utile avec l’option --debug pour
comprendre le fonctionnement des opérations internes de hwclock.
--update-drift
Mettre à jour le coefficient de dérive de l’horloge matérielle dans /etc/adjtime.
C’est utilisé avec --set ou --systohc, sinon c’est ignoré.
Une période minimale de quatre heures entre les réglages est nécessaire. Cela
permet d’éviter des calculs incorrects. Plus la période est longue, plus le facteur
de dérive résultant est précis.
Cette option a été ajoutée à la version 2.26, parce que les systèmes appellent
souvent hwclock --systohc lors de l’arrêt ; avec l’ancien comportement, cela
forçait le (re)calcul du facteur de dérive, avec pour conséquence les problèmes
suivants :
• lors de l’utilisation de ntpd avec un noyau en « mode 11 minutes », le facteur de
dérive était écrasé par une valeur quasiment nulle ;
• cela ne permettait pas d’utiliser la correction de dérive « à froid ». Avec la
plupart des configurations, l’utilisation de la dérive « à froid » donnera des
résultats favorables. À froid signifie quand la machine est éteinte, ce qui peut
avoir un impact significatif sur le facteur de dérive ;
• le (re)calcul du facteur de dérive à chaque arrêt entraîne des résultats
suboptimaux. Par exemple, si des conditions éphémères rendant la machine
anormalement chaude, le calcul du facteur de dérive serait hors limites.
Laisser hwclock calculer le facteur de dérive est un bon point de départ, mais pour
des résultats optimaux, il faudra probablement l’ajuster directement en éditant le
fichier /etc/adjtime. Pour la plupart des configurations, une fois qu’un facteur de
dérive optimal est mis en place, ce n’est plus la peine de le modifier. Ainsi, le
comportement précédent de (re)calculer la dérive a été modifié, et cette option est
nécessaire pour la rétablir. Consultez la discussion ci-dessous dans La fonction
d’ajustement.
OPTIONS SPÉCIFIQUES AUX MACHINES ALPHA
--arc Cette option est équivalente à --epoch=1980 et est utilisée pour indiquer l'époque
standard sur les machines Alpha disposant d'une console ARC (l'époque des machines
Ruffian est 1900).
--epoch=année
Indique l'année qui sera le début de l'époque de l’horloge matérielle.
C'est-à-dire, l'année grégorienne qui correspond à la valeur zéro du champ année de
l’horloge matérielle. C'est utilisé avec l'option --setepoch pour permettre au
noyau de connaître l'époque de l’horloge matérielle.
Par exemple, sur une machine Digital UNIX :
hwclock --setepoch --epoch=1952
--funky-toy
--jensen
Ces deux options indiquent le type de machine Alpha. Elles ne sont pas valables
ailleurs que sur une machine Alpha et sont généralement inutiles : hwclock devrait
être capable de déterminer le type utilisé lorsque /proc est monté.
L'option --jensen est utilisée pour les modèles Jensen ; --funky-toy signifie que
la machine a besoin du bit UF à la place du bit UIP pour détecter les transitions
de l’horloge matérielle. « Toy » dans le nom de l'option fait référence à la
structure temps de l'année (« Time Of Year ») de la machine.
--srm Cette option est équivalente à --epoch=1900 et est utilisée pour indiquer l'époque
standard sur les machines Alpha avec une console SRM.
NOTES
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 des secondes 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’heure
temps réel (« real time clock »), 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).
Accès utilisateur et Set-UID
Parfois, hwclock doit être installée avec Set-UID root, par exemple pour permettre aux
utilisateurs ordinaires d’afficher la valeur de l’horloge en utilisant la méthode
d’E/S ISA directe. Si l’interface de périphérique rtc existe sur le système ou qu’il ne
s’agit pas d’un système compatible ISA, les utilisateurs n’ont sans doute pas besoin
d’utiliser la méthode d’E/S ISA directe, donc pas la peine de s’embêter. Consultez
l’option --rtc.
De toutes façons, hwclock ne permettra pas de configurer quoi que ce soit à moins d’avoir
le réel UID de superutilisateur (cette restriction n’est pas nécessaire si hwclock n’est
pas installée avec Set-UID root, mais c’est le cas pour le moment).
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ée et sortie avec le fichier
spécial de périphérique rtc, qui est supposé 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ée 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 ça pourrait être la seule
méthode disponible sur les systèmes compatibles ISA et Alpha ne disposant pas d’un pilote
fonctionnel de périphérique rtc.
Pour un Jensen Alpha, aucun moyen ne permet à hwclock d’exécuter ces instructions d’entrée
et sortie, et à la place le fichier spécial de périphérique /dev/port est utilisé, et
fournit une interface presque d’aussi bas niveau au sous-système d’E/S.
Sur un système m68k, hwclock peut accéder à l’horloge soit par la console, soit par le
fichier spécial de périphérique /dev/tty1.
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, et 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 qu'entier décimal.
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. C’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).
Ce mode (on l'appellera le « mode 11 minutes ») est inactif jusqu'à ce que quelque chose
l'active. Le démon NTP ntpd est une chose qui l'active. 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.
Quand le « mode 11 minutes » est actif, les 64 bits de la variable time_status du noyau
sont mis à zéro. L’état de la variable peut être contrôlé avec les commandes
adjtimex --print ou ntptime.
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 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.
CONFIGURATION DE DATE ET HEURE
Garder l’heure sans synchronisation externe
Cette discussion est basée sur les conditions suivantes.
• Rien de ce qui fonctionne n’altère les date et heure de l’horloge, par exemple ntpd(1),
des tâches régulières (cron), etc.
• L’horloge système est configurée sur le fuseau horaire local. Consultez POSIX ou
« RIGHT » ci dessous.
• Tôt pendant le démarrage, les commandes suivantes sont appelées dans cet ordre :
adjtimex --tick valeur --frequency valeur
hwclock --hctosys
• Pendant l’arrêt, la commande suivante est appelée :
hwclock --systohc
* Les systèmes sans adjtimex peuvent utiliser ntptime.
Que la précision de l’heure soit maintenue avec ntpd(1) 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.
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. Sans vision d’ensemble, la
confusion s’installe…
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 du taux 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 la commande --tick et l’option
--frequency d’adjtimex(8). Les deux fonctionnent ensemble, le tic est l’ajustement global
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. Ça peut fonctionner au bout d’un moment, mais pas sans
beaucoup d’efforts et de frustration. Cette 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 ntpdate -q, 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
affiner les ajustements jusqu’à ce que l’horloge système garde l’heure correctement.
Consultez adjtimex(8) pour plus de renseignements et l’exemple montrant un calcul 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 Confirmer que ntpd(1) ne sera pas lancé au démarrage.
2 L’heure de l’horloge système doit être exacte à l’arrêt.
3 Arrêter le système.
4 Laisser passer suffisamment de temps sans modifier l’horloge matérielle.
5 Démarrer le système.
6 Utiliser hwclock immédiatement pour régler l’heure exacte avec l’option --update-drift.
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 ntpdate -q, ou
date -Ins et une horloge de précision, immédiatement après le démarrage.
Les deux horloges utilisent typiquement un oscillateur à quartz. Les cristaux sont
utilisés comme oscillateurs de référence en électronique parce qu’ils produisent une onde
sinusoïdale très propre et stable à presque tous les égards. Leur plus grand défaut est
d’avoir un coefficient de température positif, c’est-à-dire que leur fréquence augmente
avec la température et vice versa. Par conséquent, le taux de dérive des horloges
matérielle et système change avec la température propre et externe de la machine. Ces
caractéristiques varieront en fonction des machines suivant leur conception.
Les stratégies de correction de dérive sont multiples, mais en général, le but est de
trouver une moyenne à long terme. Une moyenne sur un an permet de prendre en compte les
changements de température ambiante en fonction des saisons. Dans ce cas, l’heure pourrait
avancer un peu en été et retarder un peu en hiver, mais au bout d’un an, cela s’équilibre.
Si cela commence à sembler futile, il n’en est rien. Laissée sans attention, une machine
peut perdre trois secondes par jour ou plus. La dérive accumulée sur un an peut facilement
dépasser une demi-heure. Les corrections de dérive soigneusement mises en place permettent
une amélioration significative sur la capacité d’une machine à rester raisonnablement à
l’heure.
LOCALE ou UTC
Garder l’horloge matérielle en heure locale provoque des résultats incohérents de
changement d’heure d’été.
• Si Linux est en cours de fonctionnement au moment du changement d’heure, l’heure écrite
dans l’horloge matérielle sera ajustée pour le changement.
• Si Linux n’est pas en cours de fonctionnement au moment du changement d’heure, l’heure
lue de l’horloge matérielle ne sera pas ajustée pour le changement.
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 en particulier, 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/America/Martinique'. 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
adjacents :
/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.
VARIABLES D'ENVIRONNEMENT
TZ
FICHIERS
/etc/adjtime
/etc/localtime
/dev/rtc
/dev/rtc0
/dev/misc/rtc
/dev/efirtc
/dev/misc/efirtc
/dev/port
/dev/tty1
/proc/cpuinfo
VOIR AUSSI
crontab(1), date(1), gettimeofday(2), settimeofday(2), tzset(3), adjtimex(8)
AUTEURS
Écrit par Bryan Henderson, septembre 1996 <bryanh@giraffe-data.com>, basé sur le travail
effectué sur le programme clock par Charles Hedrick, Rob Hooft et Harald Koenig. Veuillez
vous référer au code source pour une histoire complète et les crédits.
DISPONIBILITÉ
La commande hwclock fait partie du paquet util-linux, elle est disponible sur
<ftp://ftp.kernel.org/pub/linux/utils/util-linux/>.
TRADUCTION
Cette page de manuel a été traduite et est maintenue par Sylvain Archenault <sylvain DOT
archenault AT laposte DOT net> et les membres de la liste <debian-l10n-french AT lists DOT
debian DOT org>. Veuillez signaler toute erreur de traduction par un rapport de bogue sur
le paquet manpages-fr-extra.