[Boot]Lancer NTP après NUT

Support Debian
#1

Bonjour,
J’ai installé Debian Squeeze sur mon Dockstar (architecture ARM), tout fonctionne parfaitement. J’ai supprimé ntpdate qui est installé par défaut pour le remplacer par ntp, car je n’ai pas de RTC.
La synchronisation sur les serveurs français au boot se réalise bien. J’ai aussi installé NUT pour monitorer mon onduleur EATON. Là-aussi c’est parfait. J’utilise busybox-sysglod comme système de log.

Cependant, au boot lorsque NUT démarre pendant que NTP se synchronise, cela crée des alertes dans les logs car l’heure change brutalement. Effectivement ce n’est pas grave mais je voudrais éviter ça en démarrant ntp APRÈS nut, afin d’avoir un système propre.
Lorsque je commente les serveurs ntp, je n’ai plus aucune erreurs, car il n’arrive pas à synchroniser l’heure.

Voici les logs sans erreurs:

...
Jan  1 01:00:20 dockbox user.err kernel: [   17.685622] /build/buildd-linux-2.6_2.6.32-41-armel-VtoESm/linux-2.6-2.6.32/debian/build/source_armel_none/drivers/hid/usbhid/hid-core.c: usb_submit_urb(ctrl) failed
Jan  1 01:00:20 dockbox user.warn kernel: [   17.700504] generic-usb 0003:0463:FFFF.0001: timeout initializing reports
Jan  1 01:00:20 dockbox user.info kernel: [   17.708879] generic-usb 0003:0463:FFFF.0001: hiddev0,hidraw0: USB HID v1.10 Device [EATON Ellipse MAX] on usb-orion-ehci.0-1.2/input0
Jan  1 01:00:20 dockbox user.info kernel: [   17.721276] usbcore: registered new interface driver usbhid
Jan  1 01:00:20 dockbox user.info kernel: [   17.727561] usbhid: v2.6:USB HID core driver
Jan  1 01:00:20 dockbox user.info kernel: [   18.456756] udev[160]: starting version 164
Jan  1 01:00:20 dockbox user.info kernel: [   19.184942] Adding 524280k swap on /dev/sda2.  Priority:-1 extents:1 across:524280k 
Jan  1 01:00:20 dockbox daemon.notice ntpd[466]: ntpd 4.2.6p2@1.2194-o Sun Oct 17 13:24:55 UTC 2010 (1)
Jan  1 01:00:20 dockbox user.info kernel: [   20.690317] NET: Registered protocol family 10
Jan  1 01:00:20 dockbox user.info kernel: [   20.704152] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan  1 01:00:20 dockbox daemon.notice ntpd[482]: proto: precision = 1.485 usec
Jan  1 01:00:20 dockbox daemon.info ntpd[482]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jan  1 01:00:20 dockbox daemon.info ntpd[482]: Listen and drop on 1 v6wildcard :: UDP 123
Jan  1 01:00:20 dockbox daemon.info ntpd[482]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jan  1 01:00:20 dockbox daemon.info ntpd[482]: Listen normally on 3 eth0 192.168.2.10 UDP 123
Jan  1 01:00:20 dockbox daemon.info ntpd[482]: Listen normally on 4 lo ::1 UDP 123
Jan  1 01:00:21 dockbox auth.info sshd[521]: Server listening on 0.0.0.0 port 22.
Jan  1 01:00:21 dockbox auth.info sshd[521]: Server listening on :: port 22.
Jan  1 01:00:23 dockbox user.info kernel: [   23.107503] eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Jan  1 01:00:23 dockbox user.info kernel: [   23.114325] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan  1 01:00:25 dockbox daemon.info usbhid-ups[534]: Startup successful
Jan  1 01:00:25 dockbox daemon.info upsd[535]: listening on 127.0.0.1 port 3493
Jan  1 01:00:25 dockbox daemon.info upsd[535]: Connected to UPS [MGE]: usbhid-ups-MGE
Jan  1 01:00:25 dockbox daemon.info upsd[536]: Startup successful
Jan  1 01:00:26 dockbox daemon.info upsmon[538]: Startup successful
Jan  1 01:00:26 dockbox daemon.info upsd[536]: User madou@127.0.0.1 logged into UPS [MGE]

Voici les logs avec erreurs:

an  1 01:00:22 dockbox user.info kernel: [   22.524113] eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Jan  1 01:00:22 dockbox user.info kernel: [   22.530933] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan  1 01:00:25 dockbox daemon.info usbhid-ups[534]: Startup successful
Jan  1 01:00:25 dockbox daemon.info upsd[535]: listening on 127.0.0.1 port 3493
Jan  1 01:00:25 dockbox daemon.info upsd[535]: Connected to UPS [MGE]: usbhid-ups-MGE
Jan  1 01:00:25 dockbox daemon.info upsd[536]: Startup successful
Jan  1 01:00:25 dockbox daemon.info upsmon[538]: Startup successful
Jan  1 01:00:25 dockbox daemon.info upsd[536]: User madou@127.0.0.1 logged into UPS [MGE]
Jan  1 01:00:28 dockbox daemon.info ntpd[488]: Listen normally on 5 eth0 fe80::210:75ff:fe1a:d7a4 UDP 123
Jan  1 01:00:32 dockbox user.debug kernel: [   32.615338] eth0: no IPv6 routers present
Mar 15 14:16:47 dockbox daemon.notice upsd[536]: Data for UPS [MGE] is stale - check driver
Mar 15 14:16:48 dockbox daemon.notice upsd[536]: UPS [MGE] data is no longer stale
Mar 15 14:16:48 dockbox daemon.err upsmon[541]: Poll UPS [MGE@localhost] failed - Write error: Broken pipe
Mar 15 14:16:48 dockbox daemon.notice upsmon[541]: Communications with UPS MGE@localhost lost
Mar 15 14:16:51 dockbox daemon.info upsd[536]: User madou@127.0.0.1 logged into UPS [MGE]

Voici ma question: comment démarrer (quelle commande) ntp après que nut soit correctement démarré?

#2

Up

#3

Pas utile de remonter ton sujet après aussi peu de temps, il n’était même pas sorti de la première page… :wink:

'Fin bref. Déjà perso je ferais plutôt démarrer NTP avant NUT : si ce dernier se plaint des changements brutaux de date/heure ça va pas changer grand chose de faire démarrer NTP après, car le changement brutal aura toujours lieu et NUT s’en plaindra sûrement à un moment où à un autre. Alors que si NTP démarre en premier, NUT n’aura plus à subir ce changement brutal.

Concernant la manière de procéder… Hmm… Je pense pas qu’on puisse introduire des dépendances supplémentaires dans les scripts de démarrage sans toucher aux scripts eux-mêmes. Il va donc falloir mettre les mains dans le cambouis.

Pour commencer, documente toi sur la manière dont fonctionnent les en-têtes LSB des scripts de démarrage : wiki.debian.org/LSBInitScripts
Ensuite, tu n’as plus qu’à ajuster la ligne « Required-Start » du script /etc/init.d/ correspondant au service que tu veux modifier, et à y rajouter le nom de l’autre (fourni ligne « Provides » dans son script à lui).

Exemple (je n’ai ni ntpd ni nut d’installés donc les noms de scripts / services seront peut-être faux…) :

  • ouvrir /etc/init.d/ntp, regarder la ligne « Provides » qui nous indique le nom ntp
  • ouvrir /etc/init.d/nut, rajouter ntp à la ligne « Required-Start »
  • update-rc.d nut remove && update-rc.d nut defaults
  • à partir de maintenant, NTP démarrera avant NUT
  • l’opération sera à recommencer à chaque mise à jour de NUT
#4

Désolé de sembler impatient, mais je dois mettre ça en place avant de partir de chez moi.

Sinon, mettre les mains dans le cambouis ne me dérange pas. Je tourne sur du Archlinux et du Funtoo, mais j’aimerais savoir où je vais. Donc je vais devoir modifier le script pour nut, qui se trouve dans “/etc/init.d” si j’ai bien compris.

Autre question, il n’est pas possible de lancer dans un ordre précis les programmes au boot? À la manière d’une Arch, j’entends.

#5

Ben justement je crois bien que non (ou alors je n’ai pas encore trouvé comment). Debian depuis la version Squeeze utilise insserv (les en-têtes LSB dont je parlais) pour gérer les dépendances lors du démarrage et permettre un démarrage parallèle des services, du coup ça complique les choses. Par contre l’avantage c’est qu’à moins d’avoir des besoins très spécifiques comme le tien, tout marche comme sur des roulettes sans prise de tête.

#6

Quid de /etc/insserv/overrides/ dont il est question dans la page de manuel d’insserv (pas creusé) ?

#7

Raah j’suis con des fois… En plus je le sais que c’est insserv qui gère ça, je l’ai même écrit juste au dessus, et pourtant j’ai cherché du côté de update-rc.d… :108
En tout cas vu le nom du truc y’a de fortes chances que ça soit ça ! Ypnose t’as plus qu’à creuser de ce côté là, à moins que quelqu’un d’autre ne connaisse la question. :mrgreen:

#8

Je vais regarder par là, mais le moins qu’on puisse dire c’est que ça manque de doc…

#9

Si tu t’en sors sans toucher aux scripts init eux-même (probablement avec /etc/insserv/overrides/ donc) ça m’intéresserait de savoir comment t’as fait. :wink:

#10

Une question que je me pose (pardon ça peux paraître lourd), je me demande même si en démarrant ntp AVANT nut, comme tu me l’as suggeré, ntp aura-t-il le temps de se synchroniser et de changer la date/l’heure avant nut?
Tout ça va se jouer à quelques millisecondes, et je me dit que finalement ça ne suffira peut-être pas à éviter les erreurs.

#11

Effectivement, vu comme ça… J’étais parti sur le principe que ntpd, tout comme ntpdate, ne rendait pas la main avant d’avoir synchronisé l’horloge (même s’il reste ensuite résident et continue de se synchroniser régulièrement), et que du coup le chaînage des dépendances fonctionnerait correctement. Il me semble d’ailleurs avoir déjà lu (ici même) que certaines personnes ont eu des délais lors du démarrage liés à un NTP mal configuré, ce qui tendrait à confirmer ma supposition.
Cela dit j’ai pas forcément raison (ni forcément tort d’ailleurs), je pense que le meilleur moyen de savoir… bah… c’est de tester. :mrgreen:

#12

Voilà ce que j’ai créé et qui je pense devrait le faire, via l’option $time (cf doc):

[code]### BEGIN INIT INFO

Provides: nut

Required-Start: $local_fs $syslog $network $remote_fs $time

Required-Stop: $local_fs $syslog $network $remote_fs

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: NUT initscript

Description: Enable service after ntp

END INIT INFO

[/code]

Par contre, j’ai lancé en root la commande “insserv -o /etc/insserv/overrides/nut” ainsi qu’un “chmod +x nut” auparavant mais il semble qu’il ne prenne pas en compte mon fichier, correctement.

Je vais carrément modifier le fichier nut dans “/etc/init.d”, voir si il y a du mieux.

#13

Voilà ce que j’en ai tiré…

Mise en place d’un script d’essai :

[code]# cat > /etc/init.d/essai-override <<EOF
#!/bin/sh

BEGIN INIT INFO

Provides: essai-override

Required-Start:

Required-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: Essai Override Insserv

Description: Essai Override Insserv

END INIT INFO

echo Faire quelque chose…
EOF

chmod +x /etc/init.d/essai-override

update-rc.d essai-override defaults

update-rc.d: using dependency based boot sequencing

ls -lA /etc/rc2.d/*essai-override

lrwxrwxrwx 1 root root 24 2012-03-16 11:55 /etc/rc2.d/S01essai-override -> …/init.d/essai-override[/code]
Mise en place de l’override :

[code]# cat > /etc/insserv/overrides/essai-override <<EOF

BEGIN INIT INFO

Provides: essai-override

Required-Start: smartd

Required-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

END INIT INFO

EOF

update-rc.d essai-override remove && update-rc.d essai-override defaults

update-rc.d: using dependency based boot sequencing
update-rc.d: using dependency based boot sequencing

ls -lA /etc/rc2.d/*essai-override

lrwxrwxrwx 1 root root 24 2012-03-16 11:57 /etc/rc2.d/S03essai-override -> …/init.d/essai-override[/code]
À noter que le fichier dans /etc/insserv/overrides/ doit bien entendu porter le même nom que celui dans /etc/init.d/ et que les en-têtes que j’y ai mis sont le strict minimum (si j’enlève n’importe laquelle, insserv gueule). Il faut donc recopier complètement les en-têtes du script d’origine avant d’y apporter des modifications.

#14

Bon j’ai accumulé les erreurs de ma part. Avec l’option $time qui utilise hwclock, ça ne peux pas fonctionner car je n’ai pas de RTC sur le Dockstar.
Je reviens donc à l’option ntp.

Je vais vraiment m’essayer sur le fichier nut dans “/etc/init.d” avant de passer par “/etc/insserv/overrides”.

En rajoutant ntp, à la ligne “Required-Start:”, ça ne fonctionne pas comme je l’avais deviné. Il lance bien nut après ntp, mais sachant qu’il y a un délai de quelques secondes avant la récupération de l’heure, j’en reviens au problème initial.
Il faudrait que je puisse rajouter un délai avant le lancement de nut…

EDIT: J’avais quasiment fait comme tu l’as dit dans ton message précédent. Avec le recopiage de l’en-tête, par exemple.

#15

Et merde, mon intuition sur le comportement de ntp était donc fausse.

Là par contre, à part modifier le script de nut (rajouter une commande sleep NOMBRE_DE_SECONDES dans la section start du script) je vois pas vraiment.

Y’a toujours la possibilité de désactiver /etc/init.d/nut et de créer un nouveau script “proxy”, ça éviterait d’avoir à modifier le script de NUT (donc les upgrades se passeraient mieux) mais c’est plus de boulot.

Edit : toujours en reprenant mon exemple…

Mise en place du script d’essai (ton NUT actuel) :

[code]# cat > /etc/init.d/essai-wrapper <<EOF
#!/bin/sh

BEGIN INIT INFO

Provides: essai-wrapper

Required-Start:

Required-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: Essai

Description: Essai

END INIT INFO

echo “Faire quelque chose… [$1]”
EOF

chmod +x /etc/init.d/essai-wrapper

update-rc.d essai-wrapper defaults

update-rc.d: using dependency based boot sequencing[/code]
À ce stade on est dans ta situation (script actif lors du démarrage). Mise en place du “proxy”, à noter les deux modifs au niveau des en-têtes LSB (Provides / Required-Start) :

[code]# cat > /etc/init.d/essai-wrapper-delayed <<EOF
#!/bin/sh

BEGIN INIT INFO

Provides: essai-wrapper-delayed

Required-Start: smartd

Required-Stop:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: Essai

Description: Essai

END INIT INFO

if [ “$1” = “start” ]; then
echo “Script proxy : attendre…”
sleep 10
fi
. /etc/init.d/essai-wrapper
EOF

chmod +x /etc/init.d/essai-wrapper-delayed

update-rc.d essai-wrapper remove

update-rc.d: using dependency based boot sequencing

update-rc.d essai-wrapper-delayed defaults

update-rc.d: using dependency based boot sequencing[/code]
Test du “proxy” :

[code]# service essai-wrapper-delayed start
Script proxy : attendre…
Faire quelque chose… [start]

service essai-wrapper-delayed stop

Faire quelque chose… [stop][/code]
Comme ça ton script d’origine n’est pas modifié, donc lors d’une mise à jour de NUT tout ce que tu as à faire c’est de t’assurer que le script original n’est pas actif (un simple update-rc.d nut remove suffit amplement). Si t’es fainéant comme moi, tu crées un .conf dans /etc/apt/apt.conf.d/ où tu déclares un DPkg::Post-Invoke qui va s’occuper de désactiver le script NUT original à chaque mise à jour, comme ça t’as plus à t’occuper de rien. :mrgreen:

# cat > /etc/apt/apt.conf.d/99disable-nut-original <<EOF DPkg::Post-Invoke { "/usr/sbin/update-rc.d nut remove > /dev/null ; true"; }; EOF

#16

En mettant un sleep (j’ai mis 40 secondes en guise de test), ça fonctionne plutôt bien.
Tu as parlé d’une autre manière, certes plus propre, pourrais-tu développer si tu sais ce qu’il en est?

En tout cas, je te remercie de répondre à mes nombreuses questions.

#17

C’est relativement développé je crois… :wink: Il est possible que ton message et mon edit se soient croisés…

#18

Excuse-moi, je n’avais pas vu l’édit. En tout cas, tu fais de l’excellent boulot.

#19

En fait en y réfléchissant… C’est pas optimum de rajouter un délai à ton script NUT. NTP peut prendre plus ou moins de temps à se synchroniser, et soit tu gardes le risque de faire râler NUT (temps d’attente court) soit tu gaspilles inutilement du temps pendant le boot.

Idéalement, ce que je ferais c’est :

  • utiliser la méthode du script “proxy” pour NTP, mais lancer ntpdate lors du start de ce script (ntpdate ne redonne la main que lorsqu’il a fini de se synchroniser) au lieu de faire un sleep
  • ET utiliser la méthode /etc/insserv/overrides/ pour forcer NUT à attendre NTP

C’est encore un peu plus lourd à mettre en place mais là c’est optimisé au mieux. :wink:

#20

Il y a beaucoup plus propre (car d’autres ont eu ce problème déjà en 1985 :wink: ).

Le problème ici, c’est que NTP se synchronise en faisant de brusques sauts, d’où une incohérence des horodatages. L’astuce est donc d’utiliser une fréquence d’ajustement qui va accélérer ou ralentir l’horloge pour se caler sur le temps réel plutôt que de modifier brutalement le temps machine. Mais ce système n’est utilisé que si le décalage entre le temps réel et le temps machine est inférieur à 128 ms. S’il est supérieur, alors NTP synchronise le temps machine brusquement, en modifiant directement l’heure, ce qui crée des problèmes comme le tiens.

On peut donc demander à NTP d’utiliser un seuil de 600 secondes au lieu des 128 ms par défaut si le système a tendance à être désynchronisé de plusieurs secondes ou minutes assez souvent. Ca se fait en rajoutant le paramètre “-x” au lancement de “ntpd”.

Pour plus d’info :

Mais aussi :

frameip.com/ntp/

fr.wikipedia.org/wiki/Network_Time_Protocol

Dis nous ce que ça donne.

EDIT : pour info :

Voici ce qu’on trouve dans le manuel de “ntpd” :[quote]-q
Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option.[/quote]
Donc “ntpdate” est à bannir dans tous les cas puisque “ntpd” est capable de faire la même chose.