Où se configure le serveur ntp à consulter sur une Debian Squeeze « de base » etc. ?

[Francois Lafont]

Bonjour à tous,

J'installe une Debian Squeeze « de base » sur une machine. Composants
installés (via une installation en mode expert) : "SSH server" et
"Standard system utilities" et c'est tout. Rien d'autre.

Durant l'installation, on m'a demandé de choisir un serveur NTP. J'avais
laissé le choix par défaut, à savoir 0.debian.pool.ntp.org ce qui était
très bien et je finis mon installation parfaitement. Tout va bien.

Mais finalement, après coup, je me dis « zut, ce que je voulais c'est
mettre comme serveur ntp "mon-ntp.mon-domain.priv" » parce que c'est un
ntp local du coup c'est mieux. Et là, une fois l'installation terminée
et la machine rebootée, sur ma console je cherche où changer ce
paramètre et là je ne trouve rien :


root@server:~# dpkg -l | grep -i ntp # rien
root@xen-server:~# find /etc -type f \
-exec grep -EHni '0.debian.pool.ntp.org' {} \;
root@xen-server:~# find /var -type f \
-exec grep -EHni '0.debian.pool.ntp.org' {} \;
/var/log/installer/cdebconf/templates.dat:13599:Default:
0.debian.pool.ntp.org
/var/log/installer/cdebconf/questions.dat:718:Value: 0.debian.pool.ntp.org
root@xen-server:~#

Donc, juste deux occurrences de "0.debian.pool.ntp.org" dans des logs et
c'est tout. Aucun paquet "ntp*" installé. Alors du coup, j'ai quelques
questions :

1) Lors de l'installation, le choix du serveur ntp ne serait-il pas au
bout du compte ponctuel uniquement ? Je veux dire par là que ma Debian
au moment de l'installation a bien réglé son heure sur
0.debian.pool.ntp.org mais ensuite le système (une Debian de base donc)
ne cherchera plus jamais à synchroniser son heure avec
0.debian.pool.ntp.org (ou avec qui que ce soit d'autre d'ailleurs) ? Je
me pose cette question car au niveau ntp rien ne semble installé sur le
système.

2) Ou bien je me trompe et en réalité ma Debian va bien régulièrement se
synchroniser sur 0.debian.pool.ntp.org mais alors dans ce cas où peut-on
modifier le choix du serveur ntp à consulter ?

En admettant que ça soit le cas 1) qui se produise alors je veux que ma
machine se mette à jour (au niveau de l'horloge) régulièrement. Du coup,
je veux installer un client ntp. Donc je pense au paquet "ntpdate" car
je vois dans sa description :

ntpdate: client for setting system time from NTP servers

Bien sûr, il y a le paquet "ntp" aussi mais lui fait client et serveur
ntp (si j'ai bien compris) or personnellement seul le client m'intéresse
ici. Si je jette un œil sur la page man de ntpdate, je vois que la
synchronisation avec les serveurs spécifiés dans "/etc/default/ntpdate"
se fait au boot uniquement (en fait il semble que ce soit plus
précisément au moment de l'activation des interfaces réseau). Le souci
c'est que la machine est un serveur qui est censé booter plutôt rarement
et donc je voudrais que la synchronisation se fasse régulièrement même
s'il n'y a pas de redémarrage. Du coup, je pense à faire une tâche cron
mais je peux lire dans la page man de ntpade :

« It is also possible to run ntpdate from a cron script. However, it is
important to note that ntpdate with contrived cron scripts is no
substitute for the NTP daemon, which uses sophisticated algorithms to
maximize accuracy and reliability while minimizing resource use.
Finally, since ntpdate does not discipline the host clock frequency as
does ntpd, the accuracy using ntpdate is limited. »

Bref, la page man m'incite plutôt à installer le paquet ntp. D'où ma
dernière question :

3) Est-ce vraiment nécessaire d'installer le paquet ntp dans mon cas (ie
ma machine a juste besoin d'un client ntp à faire fonctionner
régulièrement) ? Personnellement une précision du temps à la seconde
près me convient tout à fait (personnellement que le temps du serveur
soit exact à la nano seconde près m'importe peu). Est-ce qu'une tâche
cron peut faire l'affaire avec mon nptdate (voire ntpdate-debian) ou
bien je suis vraiment « en dehors des clous » et il faut vraiment que
j'installe le paquet ntp. Bref, c'est quoi les bonnes pratiques dans ce
domaine ?

Merci d'avance pour votre aide.

--
François Lafont

[Fabien LE LEZ]

>Et là, une fois l'installation terminée
>et la machine rebootée, sur ma console je cherche où changer ce
>paramètre et là je ne trouve rien :

Sur ma Debian stable, j'ai bien un fichier /etc/ntp.conf qui contient
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

>1) Lors de l'installation, le choix du serveur ntp ne serait-il pas au
>bout du compte ponctuel uniquement ?

J'ai l'impression que c'est le cas, si tu n'as pas voulu de ntp (ce
qui est probablement un cas rare en 2012.)

>ntpdate: client for setting system time from NTP servers
>
>Bien sûr, il y a le paquet "ntp" aussi mais lui fait client et serveur
>ntp

La grosse différence entre ntp et ntpdate est ailleurs.

Ntpdate est très brutal : au moment où tu le lances, il modifie la
date du système. Si ça se trouve, il va retarder l'horloge d'une
seconde (voire plus), et tu risques de te retrouver avec des
événements dans le désordre, dans les logs, les bases de données, etc.
(Par exemple, un élément daté 13:35:20 peut être antérieur à un
élément daté 13:35:19.)

Ntp est un vrai système de synchronisation. Il fait de son mieux pour
éviter les modifications brutales. Comme il tourne tout le temps, il
peut régler l'horloge petit à petit. Par ailleurs, il sait détecter la
vitesse de l'horloge du PC, et en déduire l'heure réelle.

[Francois Lafont]

Le 18/10/2012 02:11, Fabien LE LEZ a écrit :

> Sur ma Debian stable, j'ai bien un fichier /etc/ntp.conf qui contient
> server 0.debian.pool.ntp.org iburst
> server 1.debian.pool.ntp.org iburst
> server 2.debian.pool.ntp.org iburst
> server 3.debian.pool.ntp.org iburst

Ok, mais tu dois avoir le paquet ntp installé sur ton système ce qui
n'est pas mon cas.

>> 1) Lors de l'installation, le choix du serveur ntp ne serait-il pas au
>> bout du compte ponctuel uniquement ?
>
> J'ai l'impression que c'est le cas, si tu n'as pas voulu de ntp (ce
> qui est probablement un cas rare en 2012.)

Ok, je vois. :-)

>> ntpdate: client for setting system time from NTP servers
>>
>> Bien sûr, il y a le paquet "ntp" aussi mais lui fait client et serveur
>> ntp
>
> La grosse différence entre ntp et ntpdate est ailleurs.
>
> Ntpdate est très brutal : au moment où tu le lances, il modifie la
> date du système. Si ça se trouve, il va retarder l'horloge d'une
> seconde (voire plus), et tu risques de te retrouver avec des
> événements dans le désordre, dans les logs, les bases de données, etc.
> (Par exemple, un élément daté 13:35:20 peut être antérieur à un
> élément daté 13:35:19.)
>
> Ntp est un vrai système de synchronisation. Il fait de son mieux pour
> éviter les modifications brutales. Comme il tourne tout le temps, il
> peut régler l'horloge petit à petit.

Ok, je vois. Bon, ntpdate a l'air brutal en effet mais seulement si
l'écart constaté est plus grand que 0.5 seconde, sinon il est doux :

« Time adjustments are made by ntpdate in one of two ways. If ntpdate
determines the clock is in error more than 0.5 second it will simply
step the time by calling the system settimeofday() routine. If the error
is less than 0.5 seconds, it will slew the time by calling the system
adjtime() routine. The latter technique is less disruptive and more
accurate when the error is small, and works quite well when ntpdate is
run by cron every hour or two. »

Bon, ceci étant, je ne vais pas faire mon marginal et j'installerai le
paquet ntp. Simplement je regarderai la conf pour désactiver la partie
serveur et ne garder que la partie client.

> Par ailleurs, il sait détecter la
> vitesse de l'horloge du PC, et en déduire l'heure réelle.

Je n'ai pas compris ça. C'est possible d'avoir des petites explications.
Pour moi, le daemon ntpd déduit l'heure « réelle » à partir des serveurs
ntp qu'on lui a indiqués comme référence dans /etc/ntp.conf. Je ne vois
pas trop ce que « l'horloge du PC » vient faire là dedans (d'ailleurs je
ne vois pas trop ce que c'est « l'horloge du PC ») ?

En tout cas, merci pour ton message Fabien car manifestement je n'allais
pas vraiment dans la bonne direction.

--
François Lafont

[Fabien LE LEZ]

On Thu, 18 Oct 2012 02:39:47 +0200, Francois Lafont
<francoi...@nospam.invalid>:

>> Par ailleurs, il sait détecter la
>> vitesse de l'horloge du PC, et en déduire l'heure réelle.

Le système utilise une horloge locale, relativement peu précise.
Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.

Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure
juste. Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur
= 606 secondes au lieu de 600).

Supposons maintenant qu'au lieu de ntpdate, tu utilises ntp, et qu'à
la même heure, il a interrogé le serveur. Puisque ntp sait que
l'horloge local va 1 % trop vite, il a corrigé le tir au fur et à
mesure ; à 13:10, ton PC indiquera bien 13:10, même si aucune autre
requête vers le serveur n'a été effectuée entre-temps.

[Francois Lafont]

Merci beaucoup, c'est limpide.

J'espère que l'exemple du « 1% trop vite » est purement didactique parce
que 6 secondes d'avance toutes les 10 minutes sur un ordinateur, ça fait
peur. :-)

Merci encore.
À+

--
François Lafont

[Sergio]

Le Thu, 18 Oct 2012 03:08:00 +0200, Fabien LE LEZ a écrit :

>>> Par ailleurs, il sait détecter la vitesse de l'horloge du PC, et en
>>> déduire l'heure réelle.

> Le système utilise une horloge locale, relativement peu précise.
> Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.

Ça existe encore des horloges "peu précises" sur les PC ?

> Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure juste.
> Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur = 606
> secondes au lieu de 600).

Supposons, cas plus probable, que la pile CMOS est en HS, le PC démarre à
une heure fantaisiste. Il vaut mieux un changement "brutal".

Une Ubuntu (pas testé avec d'autres distributions) réagit bien à ce genre
de problème : Elle met la date à jour dès qu'il y a réseau, de plus, s'il
n'y a pas de réseau, elle se débrouille pour mettre à l'heure "du dernier
arrêt" (je suppose qu'elle se base sur un fichier log).

Un W** est loin de réagir comme ça...

[moi-meme]

Le Thu, 18 Oct 2012 01:35:39 +0200, Francois Lafont a écrit :

> Mais finalement, après coup, je me dis « zut, ce que je voulais c'est
> mettre comme serveur ntp "mon-ntp.mon-domain.priv" » parce que c'est un
> ntp local du coup c'est mieux. Et là, une fois l'installation terminée
> et la machine rebootée, sur ma console je cherche où changer ce
> paramètre et là je ne trouve rien :

chez moi j'ai un /etc/ntp.conf avec :
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server
will
# pick a different set every time it starts up. Please consider joining
the
# pool: <http://www.pool.ntp.org/join.html>


et un S02ntp dans /et/rc2.d donc ntg est appelé au démarrage.

[Fabien LE LEZ]

On 18 Oct 2012 05:09:45 GMT, Sergio
<serge....@delbono.net.invalid>:

> Un W** est loin de réagir comme ça...

Oui, on sait, Windows c'est de la merde, Linux est parfait.

[Fabien LE LEZ]

On 18 Oct 2012 05:09:45 GMT, Sergio
<serge....@delbono.net.invalid>:

>Ça existe encore des horloges "peu précises" sur les PC ?

J'ai grossi le trait pour mon exemple mais, oui, l'horloge d'un PC est
très très loin d'une horloge atomique.

>Supposons, cas plus probable, que la pile CMOS est en HS, le PC démarre à
>une heure fantaisiste. Il vaut mieux un changement "brutal".

Au démarrage d'un système, sans doute.

J'ai tendance à penser "serveur" : importance d'une horloge monotone
et précise, et un redémarrage ou deux par an. J'imagine que pour une
station de travail, la situation est différente.

[Philippe]

bonjour Mr Serge

le jeudi 18 octobre 2012 07:09, Sergio a écrit:

> Une Ubuntu (pas testé avec d'autres distributions) réagit bien à ce
> genre de problème : Elle met la date à jour dès qu'il y a réseau, de
> plus, s'il n'y a pas de réseau, elle se débrouille pour mettre à
> l'heure "du dernier arrêt" (je suppose qu'elle se base sur un fichier
> log).
>
> Un W** est loin de réagir comme ça...

il faut brusquer W* pour qu'il se synchronise un peu plus souvent que
une fois par semaine. Je choisis 10mn sur les machines que je touche et
je conserve une heure UTC.

quand à Ubuntu, c'est complètement transparent et ça marche très bien.


A+
--
http://www.youtube.com/watch?v=ugCuhqw0ftU
Philippe Vessaire Ò¿Ó¬

[gerbier]

Le 18/10/2012 07:09, Sergio a écrit :
> Le Thu, 18 Oct 2012 03:08:00 +0200, Fabien LE LEZ a écrit :
>
>>>> Par ailleurs, il sait détecter la vitesse de l'horloge du PC, et en
>>>> déduire l'heure réelle.
>
>> Le système utilise une horloge locale, relativement peu précise.
>> Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.
>
> Ça existe encore des horloges "peu précises" sur les PC ?

sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...

[Francois Lafont]

Le 18/10/2012 08:37, Fabien LE LEZ a écrit :

>> Un W** est loin de réagir comme ça...
>
> Oui, on sait, Windows c'est de la merde, Linux est parfait.

Je ne suis pas d'accord : Linux n'est pas parfait. :-)

--
François Lafont

[Francois Lafont]

Le 18/10/2012 09:11, gerbier a écrit :

> sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...

Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450
jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer
ntp mais là...

--
François Lafont

[Francois Lafont]

Je me permets de revenir sur ce point.

Le 18/10/2012 03:08, Fabien LE LEZ a écrit :

> Le système utilise une horloge locale, relativement peu précise.
> Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.
>
> Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure
> juste. Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur
> = 606 secondes au lieu de 600).
>
> Supposons maintenant qu'au lieu de ntpdate, tu utilises ntp, et qu'à
> la même heure, il a interrogé le serveur. Puisque ntp sait que
> l'horloge local va 1 % trop vite, il a corrigé le tir au fur et à
> mesure ; à 13:10, ton PC indiquera bien 13:10, même si aucune autre
> requête vers le serveur n'a été effectuée entre-temps.

Juste une question (simple curiosité).

Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28
octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes
afin d'indiquer 2 heures du matin (la question se pose aussi pour le
passage à l'heure d'été où là on ajoute 60 minutes d'un coup).

ntp s'arrange pour faire la transition en douceur aussi ? Mais auquel
cas il se passe un certain temps avant que le serveur indique la « vraie
» heure, non ?

--
François Lafont

[Damien Wyart]

* Francois Lafont <francoi...@nospam.invalid>
in fr.comp.os.linux.configuration:

> Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
> quand il y a un changement d'heure d'hiver ? Par exemple un dimanche
> 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60
> minutes afin d'indiquer 2 heures du matin (la question se pose aussi
> pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).

NTP se base sur UTC ; c'est donc de la responsabilité du système
d'exploitation de gérer le fuseau horaire et les décalages. Sous Debian,
le paquet tzdata contient les données qui permettent de le faire.

--
DW

[Francois Lafont]

Le 18/10/2012 11:48, Damien Wyart a écrit :

>> Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
>> quand il y a un changement d'heure d'hiver ? Par exemple un dimanche
>> 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60
>> minutes afin d'indiquer 2 heures du matin (la question se pose aussi
>> pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
>
> NTP se base sur UTC ; c'est donc de la responsabilité du système
> d'exploitation de gérer le fuseau horaire et les décalages. Sous Debian,
> le paquet tzdata contient les données qui permettent de le faire.

Ok, si je te suis, en interne pour NTP qui se base sur UTC le changement
d'heure lui est complètement indifférent mais après au niveau de «
l'affichage de l'heure pour un être humain » l'OS va devoir faire un
changement brutal (3h00 devient 2h00). Mais alors comment ça se passe
par exemple exemple pour /var/log/syslog ?

Je vais avoir un truc comme ça ?

Oct 28 2:59:58 flpc anacron [blabla...]
Oct 28 2:59:59 flpc anacron [blabla...]
Oct 28 2:00:01 flpc anacron [blabla...]
Oct 28 2:00:02 flpc anacron [blabla...]
...



--
François Lafont

[Nicolas George]

Francois Lafont , dans le message
<507f59bd$0$6150$426a...@news.free.fr>, a �crit�:
> J'esp�re que l'exemple du � 1% trop vite � est purement didactique parce
> que 6 secondes d'avance toutes les 10 minutes sur un ordinateur, �a fait
> peur. :-)

J'ai regard� sur quelques unes des machines auxquelles j'ai acc�s�: l'ordre
de grandeur est de quelques dizaines de parties par million, ce qui fait
quand m�me quelques secondes par jour.

[Nicolas George]

Damien Wyart , dans le message <507fd07e$0$6118$426a...@news.free.fr>,
a écrit :

>> Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
>> quand il y a un changement d'heure d'hiver ? Par exemple un dimanche
>> 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60
>> minutes afin d'indiquer 2 heures du matin (la question se pose aussi
>> pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).

Shameless plug :

https://groups.google.com/forum/?fromgroups=#!topic/fr.comp.os.linux.configuration/WQLOlyqjRT4

> NTP se base sur UTC

Ce qui déplace la question : comment ça se passe quand il y a une seconde
intercalaire ?

La réponse : mal.

[Francois Lafont]

Le 18/10/2012 13:07, Nicolas George a écrit :

> https://groups.google.com/forum/?fromgroups=#!topic/fr.comp.os.linux.configuration/WQLOlyqjRT4

Merci, c'est très intéressant.


--
François Lafont

[gerbier]

tout dépends de l'utilisation de la machine : sur un cluster de calcul c'est trop
(et je ne parle pas d'une banque)

[Lucas Levrel]

Le 18 octobre 2012, Nicolas George a écrit :

> Shameless plug :
>
> https://groups.google.com/forum/?fromgroups=#!topic/fr.comp.os.linux.configuration/WQLOlyqjRT4

Très intéressant, zou un copier-coller (on ne sait jamais ce qu'en fera
Google).

§1.3 tu dis :

À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 :
le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.

Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas
de seconde intercalaire, on a quelque chose du type :
- TAI : 23h59'59" - 0h0'0" - 0h0'1"
- UTC : 23h59'59" - 23h59'60" - 0h0'0"
Je m'attends donc globalement à TAI>UTC.

Ce que semble confirmer cette page :
http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=fr
qui indique de plus que l'offset était 33 lorsque tu as écrit ton texte.

--
LL

[Nicolas George]

Lucas Levrel , dans le message
<alpine.LNX.2.00.1...@coulomb.univ-paris12.fr>, a écrit :

> À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 :
> le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
>
> Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas
> de seconde intercalaire, on a quelque chose du type :

Oui, tu dois avoir raison : on ajoute des secondes intercalaires pour éviter
qu'UTC prenne de l'avance sur l'heure solaire. Au temps pour moi.

Enfin, de toutes façons, il me semble qu'on n'est pas censé décomposer TAI
en date-heures-minutes-secondes.

[Francois Lafont]

Bonjour,

J'ai été pleinement satisfait par toutes les réponses de ce fil,
toutefois j'aimerais bien connaître la réponse à la question ci-dessous.

[Lucas Levrel]

Le 21 octobre 2012, Francois Lafont a ï¿œcrit :

> J'ai ￜtￜ pleinement satisfait par toutes les rￜponses de ce fil,
> toutefois j'aimerais bien connaￜtre la rￜponse ￜ la question ci-dessous.

Je l'ignore, mais encore un peu de patience, dans 6 jours tu auras la
rï¿œponse !

> Le 18/10/2012 12:20, Francois Lafont a ï¿œcrit :

>
>> Ok, si je te suis, en interne pour NTP qui se base sur UTC le changement

>> d'heure lui est complￜtement indiffￜrent mais aprￜs au niveau de ￜ
>> l'affichage de l'heure pour un ￜtre humain ￜ l'OS va devoir faire un
>> changement brutal (3h00 devient 2h00). Mais alors comment ï¿œa se passe

>> par exemple exemple pour /var/log/syslog ?
>>

>> Je vais avoir un truc comme ï¿œa ?

>>
>> Oct 28 2:59:58 flpc anacron [blabla...]
>> Oct 28 2:59:59 flpc anacron [blabla...]
>> Oct 28 2:00:01 flpc anacron [blabla...]
>> Oct 28 2:00:02 flpc anacron [blabla...]
>> ...



--

LL

[Francois Lafont]

Le 22/10/2012 10:21, Lucas Levrel a écrit :

>> J'ai été pleinement satisfait par toutes les réponses de ce fil,
>> toutefois j'aimerais bien connaître la réponse à la question ci-dessous.

>
> Je l'ignore, mais encore un peu de patience, dans 6 jours tu auras la

> réponse !

Exact. :-)

Mais comment faire entre sorte que ma machine soit bavarde et écrive au
niveau du syslog assez régulièrement au moment fatidique ?

--
François Lafont

[Lucas Levrel]

Dans le crontab, tu mets un "logger toto" qui s'exécute tous les quarts
d'heure (seulement le dimanche éventuellement).

--
LL

[Francois Lafont]

Le 22/10/2012 14:57, Lucas Levrel a écrit :

> Dans le crontab, tu mets un "logger toto" qui s'exécute tous les quarts
> d'heure (seulement le dimanche éventuellement).

Ah, ok merci bien. Du coup, je pense que j'utiliserai la commande at
plutôt que crontab. Sauf erreur de ma part, la commande ci-dessous
devrait réaliser le test :

$ at 02:50 10/28/12
warning: commands will be executed using /bin/sh
at> c="1"
at> while [ "$c" -le 20 ]; do
at> logger "$c. Test du changement d'heure..."
at> c=$((c+1))
at> sleep 60
at> done
at> <EOT>
job 10 at Sun Oct 28 02:40:00 2012

On verra bien ce que ça donne. :-)

--
François Lafont

[Lucas Levrel]

Le 22 octobre 2012, Francois Lafont a ï¿œcrit :

> $ at 02:50 10/28/12

> job 10 at Sun Oct 28 02:40:00 2012

02:40 ?

--
LL

[er...@rail.eu.org]

Lucas Levrel <lucas....@u-pec.fr> �crivait�:

> Le 22 octobre 2012, Francois Lafont a �crit :

>
>> $ at 02:50 10/28/12
>
>> job 10 at Sun Oct 28 02:40:00 2012
>
> 02:40 ?

ben il risque de passer 2 fois...



--
Le travail n'est pas une bonne chose. Si �a l'�tait,
les riches l'auraient accapar�

[Francois Lafont]

Le 23/10/2012 12:03, er...@rail.eu.org a écrit :
> Lucas Levrel <lucas....@u-pec.fr> écrivait :

>
>> Le 22 octobre 2012, Francois Lafont a écrit :
>>
>>> $ at 02:50 10/28/12
>>
>>> job 10 at Sun Oct 28 02:40:00 2012
>>
>> 02:40 ?
>
> ben il risque de passer 2 fois...

Oups, désolé. C'est parce que j'ai fait un copié-collé de mon terminal
mais une fois la commande écrite sur la fenêtre contenant mon message,
avant de poster j'ai modifié l'heure de départ (ça m'a pris comme ça, je
trouvais que 2h50 c'était plus joli que 2h40 ;-)) ce qui explique cette
incohérence qui n'a pas échappé à l'œil espiègle de Lucas. ;-)


--
François Lafont

[Lucas Levrel]

Le 23 octobre 2012, Francois Lafont a écrit :

>> Lucas Levrel <lucas....@u-pec.fr> écrivait :
>>
>>> Le 22 octobre 2012, Francois Lafont a écrit :
>>>
>>>> $ at 02:50 10/28/12
>>>
>>>> job 10 at Sun Oct 28 02:40:00 2012
>>>
>>> 02:40 ?
>

> Oups, désolé. C'est parce que j'ai fait un copié-collé de mon terminal
> mais une fois la commande écrite sur la fenêtre contenant mon message,
> avant de poster j'ai modifié l'heure de départ (ça m'a pris comme ça, je
> trouvais que 2h50 c'était plus joli que 2h40 ;-))

Surtout que, si je ne m'abuse, ton script tourne moins de 20 minutes. En
démarrant à 2 h 40 tu vas rater le moment fatidique. (Attendre 5 mois pour
ça, c'est ballot.)


--
LL

[Erwan David]

Francois Lafont <francoi...@nospam.invalid> écrivait :

Note que là aussi il risque de passer 2 fois : ne rien mettre entre 2 et
3h un jour de changement d'heure.


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

[Francois Lafont]

Bonjour,

Le 22/10/2012 10:21, Lucas Levrel a écrit :

>> J'ai été pleinement satisfait par toutes les réponses de ce fil,
>> toutefois j'aimerais bien connaître la réponse à la question ci-dessous.

>
> Je l'ignore, mais encore un peu de patience, dans 6 jours tu auras la

> réponse !

>
>> Le 18/10/2012 12:20, Francois Lafont a écrit :
>>
>>> Ok, si je te suis, en interne pour NTP qui se base sur UTC le changement

>>> d'heure lui est complètement indifférent mais après au niveau de «

>>> l'affichage de l'heure pour un être humain » l'OS va devoir faire un
>>> changement brutal (3h00 devient 2h00). Mais alors comment ça se passe

>>> par exemple exemple pour /var/log/syslog ?
>>>

>>> Je vais avoir un truc comme ça ?

>>>
>>> Oct 28 2:59:58 flpc anacron [blabla...]
>>> Oct 28 2:59:59 flpc anacron [blabla...]
>>> Oct 28 2:00:01 flpc anacron [blabla...]
>>> Oct 28 2:00:02 flpc anacron [blabla...]

Et bien je suis un peu déçu. Voici le résultat de mon test. Voici la fin
de mon fichier /var/log/syslog.2.gz (après un zcat) :

----------------------------------------------------------------------
Oct 28 00:17:02 grosquick CRON[20541]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 01:17:01 grosquick CRON[20553]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 02:17:01 grosquick CRON[20564]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 02:17:01 grosquick CRON[20896]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 02:55:00 grosquick logger: 1. Test du changement d'heure...
Oct 28 02:56:00 grosquick logger: 2. Test du changement d'heure...
Oct 28 02:57:00 grosquick logger: 3. Test du changement d'heure...
Oct 28 02:58:00 grosquick logger: 4. Test du changement d'heure...
Oct 28 02:59:00 grosquick logger: 5. Test du changement d'heure...
Oct 28 03:00:00 grosquick logger: 6. Test du changement d'heure...
Oct 28 03:01:00 grosquick logger: 7. Test du changement d'heure...
Oct 28 03:02:00 grosquick logger: 8. Test du changement d'heure...
Oct 28 03:03:00 grosquick logger: 9. Test du changement d'heure...
Oct 28 03:04:00 grosquick logger: 10. Test du changement d'heure...
Oct 28 03:05:00 grosquick logger: 11. Test du changement d'heure...
Oct 28 03:06:00 grosquick logger: 12. Test du changement d'heure...
Oct 28 03:07:00 grosquick logger: 13. Test du changement d'heure...
Oct 28 03:08:00 grosquick logger: 14. Test du changement d'heure...
Oct 28 03:09:00 grosquick logger: 15. Test du changement d'heure...
Oct 28 03:10:00 grosquick logger: 16. Test du changement d'heure...
Oct 28 03:11:00 grosquick logger: 17. Test du changement d'heure...
Oct 28 03:12:00 grosquick logger: 18. Test du changement d'heure...
Oct 28 03:13:00 grosquick logger: 19. Test du changement d'heure...
Oct 28 03:14:00 grosquick logger: 20. Test du changement d'heure...
Oct 28 03:17:01 grosquick CRON[20949]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 04:17:01 grosquick CRON[20961]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 05:17:01 grosquick CRON[20972]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 06:17:01 grosquick CRON[21194]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 06:25:01 grosquick CRON[21350]: (root) CMD (test -x
/usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Oct 28 06:47:01 grosquick CRON[21353]: (root) CMD (test -x
/usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))
Oct 28 07:17:01 grosquick CRON[21359]: (root) CMD ( cd / && run-parts
--report /etc/cron.hourly)
Oct 28 07:30:01 grosquick CRON[21364]: (root) CMD (start -q anacron || :)
Oct 28 07:30:02 grosquick anacron[21367]: Anacron 2.3 started on 2012-10-28
Oct 28 07:30:02 grosquick anacron[21367]: Will run job `cron.daily' in 5
min.
Oct 28 07:30:02 grosquick anacron[21367]: Jobs will be executed sequentially
Oct 28 07:35:02 grosquick anacron[21367]: Job `cron.daily' started
Oct 28 07:35:02 grosquick anacron[21372]: Updated timestamp for job
`cron.daily' to 2012-10-28
----------------------------------------------------------------------

On dirait que tout se passe comme s'il n'y avait pas eu de changement
d'heure lors de l'écriture de ce fichier. Du coup, dans le syslog, je ne
sais pas au niveau de quelle ligne le changement d'heure a-t-il été
effectué. L'extrait ci-dessus est la fin du fichier /var/log/syslog.2.gz
et ensuite le contenu se trouve dans /var/log/syslog.1 puis dans
/var/log/syslog.

Je soupçonne le système d'avoir changé de fichier syslog au moment où il
décidé de changer l'affichage de l'heure dans syslog, mais c'est juste
une intuition...

--
François Lafont

[Lucas Levrel]

Le 30 octobre 2012, Francois Lafont a écrit :

> Et bien je suis un peu déçu. Voici le résultat de mon test. Voici la fin
> de mon fichier /var/log/syslog.2.gz (après un zcat) :
> ----------------------------------------------------------------------
>

> On dirait que tout se passe comme s'il n'y avait pas eu de changement
> d'heure lors de l'écriture de ce fichier. Du coup, dans le syslog, je ne
> sais pas au niveau de quelle ligne le changement d'heure a-t-il été
> effectué. L'extrait ci-dessus est la fin du fichier /var/log/syslog.2.gz
> et ensuite le contenu se trouve dans /var/log/syslog.1 puis dans
> /var/log/syslog.
>
> Je soupçonne le système d'avoir changé de fichier syslog au moment où il
> décidé de changer l'affichage de l'heure dans syslog, mais c'est juste
> une intuition...

Tu as une ligne à chaque « heure 17 minutes ». Tu devrais en avoir une en
double au moment du changement d'heure, non ?

--
LL

[Francois Lafont]

Le 30/10/2012 10:35, Lucas Levrel a écrit :

> Tu as une ligne à chaque « heure 17 minutes ». Tu devrais en avoir une
> en double au moment du changement d'heure, non ?

Ah peut-être. C'est bizarre, la seule ligne « :17: » en double que j'ai
se situe le 28 octobre à 2h17, ie en principe avant le changement
d'heure qui s'opère à 3h00 du matin il me semble. On peut la voir
justement dans l'extrait de mon message précédent.

--
François Lafont

[Frederic Dupas]

Dans <508f2bf5$0$6138$426a...@news.free.fr>,
Francois Lafont a écrit :

>
> Et bien je suis un peu déçu. Voici le résultat de mon test. Voici la fin
> de mon fichier /var/log/syslog.2.gz (après un zcat) :
>
> ----------------------------------------------------------------------
> Oct 28 00:17:02 grosquick CRON[20541]: (root) CMD ( cd / && run-parts
> --report /etc/cron.hourly)
> Oct 28 01:17:01 grosquick CRON[20553]: (root) CMD ( cd / && run-parts
> --report /etc/cron.hourly)
> Oct 28 02:17:01 grosquick CRON[20564]: (root) CMD ( cd / && run-parts
> --report /etc/cron.hourly)

Le changement d'heure s'est fait ici entre les 2 "02:17:01".
Petit rappel : le changement d'heure s'effectue à 3h00 qui redevient 2h00
quand il s'agit d'ajouter une heure dans la nuit.

> Oct 28 02:17:01 grosquick CRON[20896]: (root) CMD ( cd / && run-parts
> --report /etc/cron.hourly)
> Oct 28 02:55:00 grosquick logger: 1. Test du changement d'heure...
> Oct 28 02:56:00 grosquick logger: 2. Test du changement d'heure...

Ce logger a été lancé trop tard pour voir le changement d'heure.
Lors du second "02:55:00" après le changement d'heure.

> On dirait que tout se passe comme s'il n'y avait pas eu de changement
> d'heure lors de l'écriture de ce fichier. Du coup, dans le syslog, je ne
> sais pas au niveau de quelle ligne le changement d'heure a-t-il été
> effectué.

Voir plus haut.

> L'extrait ci-dessus est la fin du fichier /var/log/syslog.2.gz
> et ensuite le contenu se trouve dans /var/log/syslog.1 puis dans
> /var/log/syslog.
>
> Je soupçonne le système d'avoir changé de fichier syslog au moment où il
> décidé de changer l'affichage de l'heure dans syslog, mais c'est juste
> une intuition...

Le changement de fichier syslog n'a rien perdu comme information.

--
Frédéric
Bleu,e adj. et n. m. Qui est d'une couleur voisine du rouge, mais pas très : un
ciel bleu, des yeux bleus, les flots bleus [..]. Fig. Bouch. : un steak bleu ;
s'emploie pour désigner un steak rouge. (Pierre Desproges : D.S.U.é (et des BN))

[Frederic Dupas]

Dans <508fa4bf$0$1984$426a...@news.free.fr>,
Francois Lafont a écrit :

Voir ma réponse à l'autre message.

À 3h00, il est de nouveau 2h00. Plus précisement, on passe de 2h59m,59s
à 2h00mn00s

Il est donc logique d'avoir 2 fois 02:17 dans le log.
Et ensuite, on a 03:17 plus bas dans le log.

[Francois Lafont]

Merci Frédéric pour tes explications.

Le 30/10/2012 10:59, Frederic Dupas a écrit :
> Dans <508f2bf5$0$6138$426a...@news.free.fr>,
> Francois Lafont a écrit :
>>
>> Et bien je suis un peu déçu. Voici le résultat de mon test. Voici la fin
>> de mon fichier /var/log/syslog.2.gz (après un zcat) :
>>
>> ----------------------------------------------------------------------
>> Oct 28 00:17:02 grosquick CRON[20541]: (root) CMD ( cd / && run-parts
>> --report /etc/cron.hourly)
>> Oct 28 01:17:01 grosquick CRON[20553]: (root) CMD ( cd / && run-parts
>> --report /etc/cron.hourly)
>> Oct 28 02:17:01 grosquick CRON[20564]: (root) CMD ( cd / && run-parts
>> --report /etc/cron.hourly)
>
> Le changement d'heure s'est fait ici entre les 2 "02:17:01".
> Petit rappel : le changement d'heure s'effectue à 3h00 qui redevient 2h00
> quand il s'agit d'ajouter une heure dans la nuit.

Ok.

>> Oct 28 02:17:01 grosquick CRON[20896]: (root) CMD ( cd / && run-parts
>> --report /etc/cron.hourly)
>> Oct 28 02:55:00 grosquick logger: 1. Test du changement d'heure...
>> Oct 28 02:56:00 grosquick logger: 2. Test du changement d'heure...
>
> Ce logger a été lancé trop tard pour voir le changement d'heure.
> Lors du second "02:55:00" après le changement d'heure.

Et zut. :-)

Pourtant, j'ai fait, *avant* le moment du changement d'heure (plus
précisément *avant* qu'il soit 2h55 en ancienne heure) :

$ at 02:55 10/28/12
...

Et du coup, l'ordinateur m'a exécuté mon mini programme à 2h55 de la
nouvelle heure alors que je voulais qu'il l'exécute à 2h55 de l'ancienne
heure.

Du coup, qu'aurait-il fallu indiquer pour qu'il exécute mon « at » à
2h55 de l'ancienne heure ?

--
François Lafont

[er...@rail.eu.org]

Francois Lafont <francoi...@nospam.invalid> écrivait :

Non, tu as celle de 2h17 heure d'été, puis une heure plus tard celle de
2h17 heure d'hiver.

Le changement d'heure a eu lieu entre les deux.

[Frederic Dupas]

Dans <508fa97c$0$6453$426a...@news.free.fr>,
Francois Lafont a écrit :
>

> Et zut. :-)
>
> Pourtant, j'ai fait, *avant* le moment du changement d'heure (plus
> précisément *avant* qu'il soit 2h55 en ancienne heure) :
>
> $ at 02:55 10/28/12
> ...
>
> Et du coup, l'ordinateur m'a exécuté mon mini programme à 2h55 de la
> nouvelle heure alors que je voulais qu'il l'exécute à 2h55 de l'ancienne
> heure.
>
> Du coup, qu'aurait-il fallu indiquer pour qu'il exécute mon « at » à
> 2h55 de l'ancienne heure ?
>

un moyen de contourner est d'utiliser :
at now + <temps en minutes> minutes
en calculant ce temps sans se tromper.

Je n'ai pas trouvé d'infos indiquant comment at calcule l'heure
d'exécution lors d'un changement d'heure.
J'ai essayé d'exprimer la date en UTC pour la commande at, mais le UTC
semble être ignoré !

[Francois Lafont]

Le 30/10/2012 12:30, Frederic Dupas a écrit :

>> Pourtant, j'ai fait, *avant* le moment du changement d'heure (plus
>> précisément *avant* qu'il soit 2h55 en ancienne heure) :
>>
>> $ at 02:55 10/28/12
>> ...
>>
>> Et du coup, l'ordinateur m'a exécuté mon mini programme à 2h55 de la
>> nouvelle heure alors que je voulais qu'il l'exécute à 2h55 de l'ancienne
>> heure.
>>
>> Du coup, qu'aurait-il fallu indiquer pour qu'il exécute mon « at » à
>> 2h55 de l'ancienne heure ?
>>
>
> un moyen de contourner est d'utiliser :
> at now + <temps en minutes> minutes
> en calculant ce temps sans se tromper.

Mais oui, j'aurais dû y penser.

> Je n'ai pas trouvé d'infos indiquant comment at calcule l'heure
> d'exécution lors d'un changement d'heure.
> J'ai essayé d'exprimer la date en UTC pour la commande at, mais le UTC
> semble être ignoré !

Ok.

Merci pour ces précisions. Bon, je me suis fait avoir par « at » sur ce
coup là. On verra au prochain changement d'heure, si j'y pense. :-)

Merci pour ton aide.
À+

--
François Lafont