Reprise du message précédent :
ses autres videos sont impressionnantes aussi , genre la découpe à la scie sans prendre de mesure qui tombe juste

Nan mais c'est facile avec des lisses. Avec des torsadés, c'est une autre histoire
 

 
Victoire de Lee Sedol... https://www.youtube.com/watch?v=yCALyQRN3hw Hate d'avoir le résultat de la 5éme partie !

'tain ce truc de fou d'avoir une machine qui n'a pas de pile RTC
 
quelqu'un a une idée un peu élaborée pour mettre à jour le fichier /etc/timestamp ? J'ai parfois de la 3G, auquel cas y'a un ntpdate qui a pu passer, mais c'est un peu aléatoire.

Si tu as plus souvent un ntp qu'un reboot : tu stockes tes infos en parlant de timestamp depuis le dernier boot, quand tu as un ntp, tu calcules l'heure du dernier boot .
Mais sinon, avec la position  gps y'a  pas un timestamp ?

j'ai pas de GPS
 
comment tu sais si au moins un NTP a marché depuis le dernier reboot ?

avoir une date en 2016 plutôt qu'une date à l'origine du monde ?

nan, parce qu'une fois que je touche à /etc/timestamp, c'est la fête du slip sur la date de démarrage

Au reboot tu force la date en 1970 ?  
 

d'ailleurs si le truc n'est pas censé perdre son alim très longtemps une supercap c'est plus fiable qu'une pile.

au contraire, je voudrais avoir une date pas trop débile au reboot, parce que des fois il accroche jamais le réseau, et les logs sont à chier

nan, 1) j'ai de la chaleur, 2) ya pas de pile à cause d'un bug de silicium, on peut pas en mettre

marque le truc unclean en cas de reboot ?  
genre un fichier waiting_for_real_mwinmwindate

un rtc externe sinon

j'ai pas de hook pour savoir quand ntpdate a été appelé et a réussi

(je sentais bien que au niveau de "un peu élaborée" ça allait pêcher)

Là-haut tu devrais bien capter le DCF, non ?

toujours aussi agréable
c'est assez facile de voir si l'heure a été modifiée ,non ?  
 
Pour transmettre les données, il te faut de la 3G, tu forces un ntp avant de transmettre .  

 
un signal radio ou télé...mais après faut embarquer de quoi le lire, et je doute que ça lui plaise
 
 
sinon XCOM2        
première mission, je me suis fais fessé grave, alors que j'ai joué à tous les XCOM depuis leur création
 
c'est horrible la pression du temps, ça et les armes en carton

bah surtout que is je pouvais embarquer un truc, ça serait un GPS.

dites, les fichiers dans /run j'ai la garantie qu'ils vont pas survivre un reboot ?

un truc genre

ça serait un bon flag pour savoir si la machine a été mise à l'heure un jour ?

edit: trouvé, c'est bien détruit au boot http://refspecs.linuxfoundation.or [...] RIABLEDATA

https://access.redhat.com/documenta [...] f_NTP.html ?

intéressant, ntpd me fait un peu flipper sur la quantité de trafic qu'il va faire passer à la longue.

pourquoi j'ai lancé apt-get install alors que j'étais en 3G ?

380kB, ça va, il y a pas mort d'homme...

 
ils ont viré ntpctl du package ????
https://bugs.launchpad.net/ubuntu/+ [...] ug/1429620
 
'tain le cauchemar que c'est linux.

pourquoi tu installes pas "ntp" à la place de "openntpd" et tu fais un simple ntp-wait ? ou "ntpq -p"
 
je ne savais même pas que openntpd existait

intéressant, merci, je connaissais pas, je teste et je te dis ce qu'ils ont cassé qui m'empêche de l'utiliser ...

j'ai toujours dis d'utiliser debian pour des serveurs (ou redhat, ou centos , enfin un truc sérieux sérieux orienté serveur), et à chaque fois ça viens pleurer que ubuntu ouin ouin ça marche mal.  

c'est une putain de beagle bone, et c'est un debian

fallait le dire plus tôt    
https://bugs.debian.org/cgi-bin/bug [...] bug=775304

 
donc il faut faire
 

 
 
edit: mais le ntp isc est mieux que openntpd AMHA

je pense que ntp-wait c'est pas mal, j'attends qu'il débloque avant de lancer les mesures, vu que de toutes façons on utilise l'heure système pour date les samples, ça sert à rien de lancer la mesure tant qu'on est pas à l'heure (et j'ai la flemme de les re caller a posteriori).
 
maintenant reste à rendre robuste le système de clef 3G. C'est pas gagné, ils avaient mis un système pour rebooter la clef quand la connection marchait pas, ça partait en boucle de reboot, parce que le système vérifiait la connection avant qu'elle ait eu le temps de s'établir

en fait je l'ai raté parce que j'ai cherché apt-cache search ntpd au lieu de ntp.
 
(et j'ai été un peu con, parce que j'aurai pu tomber sur un outil de serveur de temps, qui est pas vraiment mon besoin)

ntp-wait bloque pas alors que j'ai booté la carte sans le moindre accès à internet
 
j'veux aller me prostrer dans un coin et mourir

ça marche pas, ça débloque pas, mais je sais pas pourquoi. (jitter sur la 3G ?)

 
et ben ntpq -c "rv 0" et tu debug

 
oui enfin faut pas aimer les packages récents quoi...quand tu dois passer en testing, ou backporter la moitié de tes packages, ou installer depuis les sources, t'as plus trop le bénéfice de ta debian rock stable
 
Faux edit : je suis surpris, Jessie a Python 3.4.2, je m'attendais encore à du 3.3
 

Je suis pas sûr qu'il disait ça pour être désagréable, c'était ptêtre juste de la déception qu'une meilleure solution existe pas.Ca m'est arrivé  souvent de passer pour un connard à cause de ça, du coup je le relève.

'tain de merde, on doit les installer vendredi, je peux pas me lancer dans un debug maintenant
 
Edit: et la doc de ntpq est pas dans le manuel

Bon je vais jouer avec le code de retour de ntpdate et un fichier dans /run, mais du coup un bon samaritain qui se pointe et installe ntp va foutre en l'air ma partie de jenga.

Ici les sysadmins préfèrent gérer qu'un seul OS (CentOS 6, on va commencer gentiment à passer à la 7).
Pour gérer la version des dépendances on a plusieurs moyens: tout embarquer dans le RPM, recette Puppet, Docker, ou une combinaison des trois.
 
Cela dit j'ai jamais eu de soucis avec Ubuntu LTS auparavant, et j'ai jamais rencontré de situation où je me suis dit que j'aurais préféré utiliser Debian.
Et aujourd'hui la direction prise par Canonical avec Snappy me semble intéressante, justement pour régler ce genre problèmes.