[Heure] Problème d'horloge, malgré ntp,localtime,.. (Résolu)

[Bismut]

Qu'entends-tu par boot en single user ? Juste démarrer normalement et me connnecter via GDM avec un compte utilisateur, et pas admin ?

Sinon les MAC utilisent un EFI, mais je pense pas pouvoir rentrer dedans comme on rentre dans un BIOS.

Je vais booter sur OS X et regarder un peu l'heure, histoire de voir si ce ne serait pas lui qui mettrait le fouilli.

[oktoberfest]

Booter en single user, cela veut dire booter en passant l'option 'S' au noyau. De cette façon le système démarre un minimum de choses. Tu te retrouveras devant la console, en mode texte, mais au moins tu n'auras pas 36 choses de lancé.
Pour faire cela, au démarrage de grub tu peux éditer dynamiquement le menu affiché (via la touche 'e' je crois), puis tu édites la ligne 'kernel ...' et tu ajoutes un 'S' (sans les ') en fin de ligne.

[FoolEcho]

«Mauvais» plan: il démarre gdm en tant que service, donc effectivement init 1 oblige... mais il n'aura pas de réseau, donc pas de ntpd non plus. Il faudra lancer les services à la main.
Il suffirait de démarrer normalement, de se connecter dans un tty et de vérifier date: vu les infos qu'on a, j'ai plutôt l'impression que c'est gnome qui utilise un autre fuseau horaire que celui du système (on serait fixé en tous cas).

[Bismut]

Alors, après redémarrage (mauvaise heure affichée, toujours -1) et CTRL + ALT + F1 pour passer sur un tty et login :
Un date me donne la même heure que Gnome, la mauvaise, toujours 1h de retard.

EDIT : Attendez, y a un truc bizarre là... Après avoir redémarré, je m'aperçois qu'à l'ouverture de session, l'heure était mauvaise... mais le temps d'écrire ce message sur le forum, l'applet de Gnome affiche la bonne heure alors que je ne l'ai pas changée...

Est-ce possible que ntpd mette simplement beaucoup de temps à synchroniser ? Du genre 2 ou 3 minutes ? Je pensais que ça devait être instantannée et effectif avant même l'arrivée sous GDM moi, non ?

[FoolEcho]

Rajoute iburst à la fin de chaque ligne des serveurs dans le /etc/ntp.conf (je ne l'ai pas proposé plus tôt car j'avais cru que ntp ne se synchronisait pas du tout ), car effectivement si ntp n'obtient pas de réponse (parce que le réseau n'est pas encore établi par exemple) il refera l'essai... plus tard.

[mélodie]

Bonjour,
Mon grain de sel : l'heure du BIOS indique-t-elle l'heure locale ou l'heure UTC ?

[Bismut]

mélodie > Je ne crois pas avoir de BIOS, mais un EFI puisque j'ai un Mac Mini 2009 non ?


FoolEcho > Après avoir rajouté iburst au ntp.conf, j'ai du nouveau !

A l'arrivée sous GDM : Mauvaise heure !
Après connexion : PAF, l'applet se rafraichit et se met à la bonne heure.

On peut donc dire que le problème est résolu je pense.


Un grand merci à tous donc

[oktoberfest]

Salut,

je ne dirais pas que le problème est résolu. Un problème est résolu quand on a trouvé la cause du problème et appliqué un correctif que l'on comprend.
Au vu des différents posts il reste les questions suivantes :
- quelle est l'heure de ton bios (qu'on l'appelle bios, efi ou tartenpion)
- est-ce que ntp est démarré avant ou après le réseau (comment lances-tu les démons : en arrière-plan ou pas, dans quel ordre)
- ok Gnome te met l'horloge à l'heure, mais si un jour tu changes d'environnement tu auras de nouveau le souci.

[tuxce]

+1 mais juste pour un point que je poserais plutôt comme ça: pourquoi l'heure se modifie suite au redémarrage ?

Enfin bon, c'est contourné, le reste rejoindra la liste des questions sans réponse

- est-ce que ntp est démarré avant ou après le réseau (comment lances-tu les démons : en arrière-plan ou pas, dans quel ordre)

Il est démarré et met un temps pour mettre l'heure à jour, mais c'est normal quand la différence est de ~>1h

ok Gnome te met l'horloge à l'heure, mais si un jour tu changes d'environnement tu auras de nouveau le souci.

A mon avis, Gnome ne fait rien, juste que l'heure se met à jour entre le gdm et la session.

[tazzon]

Tiens c'est dommage que j'ai pas vu ce topic avant, j'ai rencontré le même problème, il se trouve qu'il y a un délai pour la mise à jour de l'heure par ntp (entre quelques secondes et une bonne minute si je dis pas de bêtise), je l'ai constaté sur 2 PC. Pour info, le démon network est lancé dans les premiers avec @network et la mise à l'heure est faite par la ligne :

Code : Tout sélectionner

ntpd -qg &

dans le /etc/rc.local.

Vu sur le wiki.org : https://wiki.archlinux.org/index.php/NT ... the_daemon

Il y a aussi sur cette même page un ce passage qui renvoie à cette page
C'est peut-être la solution au problème.

[oktoberfest]

Pour info, le démon network est lancé dans les premiers avec @network et la mise à l'heure est faite par la ligne :

Code : Tout sélectionner

ntpd -qg &

Et comme l'indique le wiki que tu cites :

Note: In order for this method to work you have to make sure that, when rc.local is executed, the network connection has already been initialized (for example you should not background essential network-related daemons in /etc/rc.conf)

[tazzon]

C'est pas faux, ceci expliquant cela.

Peut-être ajouter dans le rc.local une boucle qui teste le fait qu'on a bien un accès internet (par un ping quelconque ou je ne sais quoi d'équivalent) et dans la cas contraire, un petit sleep avant de retester.

C'est juste une idée.

En soit, ça changera pas le problème qu'il faut quelques secondes avant d'obtenir l'heure depuis le serveur.

[FoolEcho]

En utilisant le service, il suffit de spécifier le "iburst" pour justement pallier à ces problèmes de réseau disponible ou pas sur la première tentative de synchronisation (ntpd va essayer plusieurs fois de se connecter si le serveur n'est pas disponible). Mais il faudra tout de même quelques secondes pour être à l'heure (ce qui normalement devrait être assez pour arriver sur le gestionnaire de connexion).
Maintenant, à mon avis, il serait également préférable de spécifier des serveurs fr, pour justement... gagner du temps sur l'accès aux serveurs de temps.

[tazzon]

En fait j'utilise bien iburst donc c'est sans doute pour ça que j'ai toujours réussi à synchroniser.