Qu'est-ce qui pourrait faire en sorte que l'horloge saute de 5 minutes?

J'ai une boîte (physique) en cours d'exécution Ubuntu dépouillé; de time en time (6 fois en 3 mois), l'horloge recule d'exactement 300 secondes (+ – 0,01 secondes, toujours exactement 300 secondes). Cela arrive d'une minute à l'autre (j'ai une machine externe qui l'interroge une fois par minute).

La boîte est en cours d'exécution 2.6.26-generic (kernel compilé personnalisé), Ubuntu 9.04 (je sais, j'essaie de le mettre à jour, mais il est semi-embedded). Il n'y a rien dans les journaux qui indique ce qui est arrivé, et j'ai un grand choix de servers ntp pool.ntp.org, qui corrigent le problème après un certain time.

Est-ce que quelqu'un sait ce qui pourrait causer cela?

Supplémentaire 1:

J'ai aussi un certain nombre d'autres boites qui courent le même kernel (binary identique), et des variantes mineures du même logiciel, qui n'ont pas ce problème. J'ai aussi échangé le matériel.

2 supplémentaires (résumé de mes commentaires individuels):

Je sais que 9.04 est obsolète, je suis d'accord qu'il devrait être mis à jour, et cette décision est hors de mon contrôle. Parce que la gestion.
J'ai essayé un grand nombre de servers ntp, et un petit nombre. Cela arrive toujours dans les deux cas; si j'ai un grand nombre de servers ntp, il se corrige plus rapidement.
J'ai échangé le matériel
J'utilise le même kernel / operating system sur une autre boîte (avec du matériel identique), qui ne montre pas le problème.
Le redémarrage n'a pas aidé. (ce problème est en cours depuis environ 6 mois)
La disponibilité est d'environ 3 mois. La boîte est "toujours activée", exécutant un PBX (astérisque).
En ce moment, le hwclock correspond exactement à l'horloge du logiciel – 0.000000 secondes
Je n'ai pas pu find des tâches cron qui lit l'horloge matérielle.
Il n'y a pas de configuration liée à la charge (bien que la charge soit assez faible de toute façon).
Cela arrive pendant le jour et la nuit.
Cela n'arrive pas à intervalles réguliers. Parmi ceux des 3 derniers mois, la moitié s'est produite au cours des 9 derniers jours.
Ce n'est pas "dérive" – 99% du time, il est dans une infime fraction de seconde, puis d'une minute à l'autre, il saute EXACTEMENT 300 secondes, à l'envers. Donc, une minute, il pourrait dire que c'est 3:07:03, correspondant à mon autre ordinateur à 1 microseconde, 60 secondes plus tard, il est dit 3:04:03.
Je ne trouve rien dans les journaux.

Cela ressemble à une horloge en time réel (RTC) défaillante. S'il s'agit d'un matériel de rechange, vous pouvez confirmer le problème en exécutant un autre operating system, par exemple démarrer un CD Linux en time réel ou amorcer PXE, et voir si vous pouvez répliquer l'échec. Si le décalage horaire exact se produit sur un autre operating system, vous avez confirmé que le problème est une défaillance matérielle.

En supposant que c'est le RTC, vous pouvez essayer les solutions suivantes dans l'ordre de gravité.

Remplacez la batterie CMOS. Vous pouvez essayer de confirmer s'il s'agit d'une batterie défectueuse en testant la tension de votre ancienne pâte avec un multimètre.
Changer les RTC. Si vous êtes chanceux et avez une carte mère de fantaisie, il pourrait avoir deux RTC. Horloge de haute précision utilisée par défaut et RTC standard. Vérifiez les parameters du BIOS / EFI et voyez si vous pouvez passer au RTC alternatif pour éviter d'utiliser celui qui est défectueux.
Essayez de replace le RTC. Selon l'âge de votre carte mère, votre RTC est probablement une boîte métallique ou une puce sur le tableau. Vous pouvez essayer de replace ce composant vous-même si vous avez des compétences en électronique.
Remplacez la carte mère, car le RTC ou certains des composants élecsortingques ou des câbles qui entrent en contact avec le RTC échouent.

Vous pouvez exécuter un script sur la boîte qui garde la trace des process en cours et en même time surveille l'horloge. Si l'horloge saute soudainement, elle enregistre la list des process actifs à ce moment-là. Peut-être que cela donne un indice qui process change l'horloge.

Bien sûr, cela suppose que vous avez un problème de logiciel. Vous ne findez rien de cette façon si votre matériel échoue.

/bin/bash oldTime=$(date +%s) oldPsOutput=$(ps faux) while sleep 1 do currentTime=$(date +%s) currentPsOutput=$(ps faux) if [ "$currentTime" -lt "$oldTime" ] # clock change detected? then echo '=========' echo "$currentTime < $oldTime" echo "$oldPsOutput" echo ':::::::::' echo "$currentPsOutput" fi >> /tmp/clockChangeDetector.log oldPsOutput=$currentPsOutput oldTime=$currentTime done

La réponse de Michael Yasumoto semble couvrir toutes les bases – je suis d'accord sur le fait que vous regardez probablement du matériel ennuyeux – mais voici une idée pratique: utilisez une machine fiable avec une très bonne connectivité interne qui a une poignée de cycles pour faire fonctionner NTP, puis exécutez « ce qu'il faut » pour que le client NTP s'exécute sur le boîtier PBX embedded, et ce, le plus souvent possible (par exemple, toutes les 30 secondes) pour ce server NTP local.

Ensuite, lorsque la boîte est finalement mise à jour, mettez-la de côté et déterminez ce qui ne va pas avec At Some Point (TM). : P