Re: Bug étrange NTP (la suite)
Le samedi 5 septembre 2015, 17:11:48 François Boisson a écrit : >[… CONFIG_RTC_SYSTOHC …] > > Sauf que cette option a été ajoutée au noyau 3.10 et > > n’existe pas dans le 2.6… > > Mince je pensais que cela existait déjà sur le 2.6. C'était > mon explication... Vérifie quand même sur ton noyau (/boot/config-*), ça a peut- être été rétroporté. (Mais l’option n’apparaît pas dans le 2.6.32.67 de kernel.org, donc c’est mal barré.) -- Sylvain Sauvage
Re: Bug étrange NTP (la suite)
Le Sat, 05 Sep 2015 11:31:29 +0200 "Sylvain L. Sauvage" a écrit: > Et aussi : Pourquoi le serveur NTP voit le décalage quand il > apparaît mais pas quand il disparaît ? dans le deuxième cas le décalage est trop grand et ans ce cas, NTP ne rattrape pas l'heure. Ce qui est bizarre c'est que ntpd ne fait jamais de sauts brusques... Les logs de NTP montre un décalage brutale avant 22:57 et après 22:40. > > > Ça n'est pas logique, l'heure fiable c'est l'heure système. > > Effectivement, il n’y a pas de raison logique pour que NTP se > cale sur la RTC. Mais il y a des raisons de caler la RTC sur le > temps NTP. > > Et ça aiderait à répondre à la question que tu n’as pas > posée : Comment la RTC reprend la bonne heure ? > > J’avais une piste : le noyau. En effet, c’est ce que fait > l’option CONFIG_RTC_SYSTOHC de Linux : toutes les 11 minutes, il > cale la RTC avec l’heure système si « l’espace utilisateur » dit > qu’il est synchronisé avec NTP. > Sauf que cette option a été ajoutée au noyau 3.10 et n’existe > pas dans le 2.6… > Mince je pensais que cela existait déjà sur le 2.6. C'était mon explication... > > Prochain BUG le 23 Octobre à 9:58 GMT (donc à 11:58 heure > > Française). Si vous avez des tests à proposer... > > Je dirais bien que pouvoir intercepter les appels à la RTC > pourrait être intéressant mais ça me semble une grosse tâche… > Driver=rtc_cmos... > > En clair: Je n'y comprends pas grand chose. > > Et grâce à moi, tu y comprends encore moins ;o) Bon, à suivre...
Serveur dédié injoignable - erreur de boot
Bonjour à tous, Je commence par un petit historique de mes manip jusqu'aux problèmes actuels : J'ai un serveur dédié chez OVH sur lequel est installé Proxmox 3.0, avec en gros une VM par service (toutes sous Debian dans des CT OpenVZ). La semaine dernière, j'ai fait une mise à jour de la VM DNS. En fin de semaine, j'ai voulu ajouter un NDD sur cette VM. Impossible de m'y connecter en SSH (de mémoire, le message était : pas de pty disponible). Je me suis dit que les mises à jour ne devaient pas être terminée, et qu'elles devaient attendre un retour de ma part. J'ai redémarré la VM via l'interface Proxmox : VM up, mais impossible de m'y connecter en SSH (network error : Connection timed out). N'étant pas en état de chercher une solution intelligente, j'ai redémarré tout le serveur (sic...). Et depuis, impossible de me reconnecter sur l'hôte. Là, intervention d'OVH : "Cette opération a été achevée le 2015-09-04 03:10:46 Voici les détails de cette opération : Boot sur interface diagnostique (rescue) Date 2015-09-04 03:07:47, yoann P a fait Boot sur interface diagnostique (rescue): Voici le detail de l'intervention realisee: Le serveur lance un memtest lors du boot sur disque. Actions entreprises: Redemarrage du serveur sur mode 'rescue' (Linux) Resultat: Boot OK. Systeme 'rescue' accessible. Recommandations: Configuration/erreur a corriger par le client" J'ai effectué les tests via le manager en mode rescue : tous OK. Je l'ai démarré en mode rescue, accès SSH OK. J'ai déplacé le répertoire /etc/grub.d/20_memtest86+ pour éviter qu'il lance un memtest au boot, mais toujours aucun accès SSH après reboot sur HD. Donc retour en mode rescue, et histoire de cumuler, j'ai eu la merveilleuse idée de me dire : "Une mise à jour du système va tout résoudre..." Donc apt-get update && apt-get upgrade en chroot sur ma partition principale /dev/md1. Et là, c'est le drame : "Errors were encountered while processing: bind9 pve-cluster qemu-server pve-manager E: Sub-process /usr/bin/dpkg returned an error code (1)" Donc bien évidemment, ça n'a rien résolu du tout !! Je me suis enfin dit qu'il valait mieux aller se coucher que de continuer à tout casser... Donc au final, j'ai un serveur partiellement mis à jour en mode rescue, qui à priori démarre en HD, mais impossible de s'y connecter. Déjà, je voudrais commencer par résoudre ce problème de boot. Mais à distance, je ne sais pas où s'arrête la séquence de boot, dans quel état est le serveur... Et je vous avoue ne pas trop savoir quoi chercher et par où commencer... Si quelqu'un aurait une piste/idée, je suis preneur. De même, je n'ai pas envie de faire un pavé encore plus gros qu'actuellement avec des infos inutiles, mais n'hésitez pas si vous voulez plus d'infos techniques... Je vais même aller plus loin : si quelqu'un se sent l'âme de me faire un devis pour une prestation de sauvetage de serveur, je suis également intéressé. Je ne veux absolument pas perdre les données sur le serveur... Bon w-e à tous.
Re: Bug étrange NTP (la suite)
Le samedi 5 septembre 2015, 09:30:47 Francois Boisson a écrit : >[…] > Questions: > * Pourquoi l'heure RTC se décale comme ça? > * Pourquoi ce décalage s'impose au serveur NTP? Et aussi : Pourquoi le serveur NTP voit le décalage quand il apparaît mais pas quand il disparaît ? > Ça n'est pas logique, l'heure fiable c'est l'heure système. Effectivement, il n’y a pas de raison logique pour que NTP se cale sur la RTC. Mais il y a des raisons de caler la RTC sur le temps NTP. Et ça aiderait à répondre à la question que tu n’as pas posée : Comment la RTC reprend la bonne heure ? J’avais une piste : le noyau. En effet, c’est ce que fait l’option CONFIG_RTC_SYSTOHC de Linux : toutes les 11 minutes, il cale la RTC avec l’heure système si « l’espace utilisateur » dit qu’il est synchronisé avec NTP. Sauf que cette option a été ajoutée au noyau 3.10 et n’existe pas dans le 2.6… > Prochain BUG le 23 Octobre à 9:58 GMT (donc à 11:58 heure > Française). Si vous avez des tests à proposer... Je dirais bien que pouvoir intercepter les appels à la RTC pourrait être intéressant mais ça me semble une grosse tâche… > En clair: Je n'y comprends pas grand chose. Et grâce à moi, tu y comprends encore moins ;o) -- Sylvain Sauvage
Re: Bug étrange NTP (la suite)
Bien le bug est passé comme prévu, voilà ce que ça donne: [code] 22:52:26 < HEURE SUR UN AUTRE SERVEUR NTP: heure exacte donc vendredi 4 septembre 2015, 22:52:26 (UTC+0200) < DATE MACHINE (date) 0 <--- HEURE système moins HEURE RTC en secondes (via un pgm C maison) 22:52:34 vendredi 4 septembre 2015, 22:52:34 (UTC+0200) 0 22:52:43 vendredi 4 septembre 2015, 22:52:43 (UTC+0200) 0 22:52:54 vendredi 4 septembre 2015, 22:52:54 (UTC+0200) -89 22:53:02 vendredi 4 septembre 2015, 22:53:02 (UTC+0200) -89 22:53:10 vendredi 4 septembre 2015, 22:53:10 (UTC+0200) -89 [..] 22:59:46 vendredi 4 septembre 2015, 22:59:46 (UTC+0200) -89 22:59:54 vendredi 4 septembre 2015, 22:59:54 (UTC+0200) -89 23:00:02 vendredi 4 septembre 2015, 23:00:02 (UTC+0200) 0 <--- RECALAGE heure RTC sans intervention 23:00:11 vendredi 4 septembre 2015, 23:00:11 (UTC+0200) 0 23:00:19 vendredi 4 septembre 2015, 23:00:19 (UTC+0200) 0 [/code] Le serveur NTP a été relancé à [code]16354 ntpdFri Sep 4 23:46:17 2015 [/code] parce que il avait toujours un décalage de 89s avec le reste du monde. Log de poolntp (heure GMT): [code] 1441409460,"2015-09-04 23:31:00",-0.973939895629883,1,-13.7 1441408361,"2015-09-04 23:12:41",-0.00238072872161865,1,-15.5 1441407236,"2015-09-04 22:53:56",0.000102996826171875,1,-17.3 1441406139,"2015-09-04 22:35:39",-0.0020374059677124,1,-19.3 1441405024,"2015-09-04 22:17:04",-0.807046890258789,1,-21.4 1441403883,"2015-09-04 21:58:03",-0.00218832492828369,1,-23.6 <--- RELANCE SERVEUR 1441402698,"2015-09-04 21:38:18",-89.0613644123077,-4,-25.8 1441401493,"2015-09-04 21:18:13",-89.0638047456741,-4,-23 1441400294,"2015-09-04 20:58:14",-89.0625076293945,-4,-20 < DECALAGE SERVEUR 1441399167,"2015-09-04 20:39:27",0.00154829025268555,1,20 1441398054,"2015-09-04 20:20:54",-0.000956535339355469,1,20 1441396948,"2015-09-04 20:02:28",0.00281929969787598,1,20 1441395821,"2015-09-04 19:43:41",-0.00122296810150146,1,20 [/code] Bilan: * J'avais redémarré le serveur. Si le bug est lié au serveur NTP, le prochain aurait eu lieu le Dimanche 6/09 au matin et non le 4/09. C'est donc indépendant du serveur NTP. * L'heure prévu du bug (le 4 septembre vers 22h53.) était parfaite. * Le fait que l'heure système ne décroche jamais de l'heure d'un autre serveur NTP montre que l'horloge système fonctionne correctement * C'est un décalage brusque et immédiat de l'heure RTC de 89s dans l'avenir * À 23:00 visiblement l'heure RTC s'est recalé sur l'heure système mais le serveur NTP a continué sur la mauvaise heure. * Mon hypothèse de gel de la machine est fausse, on a bien le serveur NTP interrogé toutes les 8s Questions: * Pourquoi l'heure RTC se décale comme ça? * Pourquoi ce décalage s'impose au serveur NTP? Ça n'est pas logique, l'heure fiable c'est l'heure système. Prochain BUG le 23 Octobre à 9:58 GMT (donc à 11:58 heure Française). Si vous avez des tests à proposer... En clair: Je n'y comprends pas grand chose. François Boisson
