Gandi.net Groups

Bonjour,

Depuis le 20 Février
j'ai 2 VM fédora et sur les deux le fichier /var/log/messages et rempli
de la trace suivante


Feb 26 08:47:57 svr dhclient: DHCPREQUEST on eth0 to 255.255.255.255
port 67
Feb 26 08:48:31 svr last message repeated 3 times
Feb 26 08:49:32 svr last message repeated 4 times
Feb 26 08:50:36 svr last message repeated 5 times
Feb 26 08:51:37 svr last message repeated 4 times
Feb 26 08:52:51 svr last message repeated 5 times
Feb 26 08:54:00 svr last message repeated 4 times
Feb 26 08:55:03 svr last message repeated 4 times
Feb 26 08:56:05 svr last message repeated 4 times
...

et ca finit par:
Feb 26 23:44:08 svr NET[21323]: /sbin/dhclient-script : updated
/etc/resolv.conf
Feb 26 23:44:08 svr avahi-daemon[2068]: Withdrawing address record for
217.70.189.87 on eth0.
Feb 26 23:44:08 svr avahi-daemon[2068]: Leaving mDNS multicast group on
interface eth0.IPv4 with address 2
Feb 26 23:44:08 svr avahi-daemon[2068]: Interface eth0.IPv4 no longer
relevant for mDNS.
Feb 26 23:44:08 svr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255
port 67 interval 6
Feb 26 23:44:08 svr dhclient: send_packet: Network is down
Feb 26 23:44:14 svr dhclient: DHCPDISCOVER on eth0 to 255.255.255.255
port 67 interval 11
Feb 26 23:44:14 svr dhclient: DHCPOFFER from 0.0.0.0
Feb 26 23:44:14 svr dhclient: DHCPREQUEST on eth0 to 255.255.255.255
port 67
Feb 26 23:44:14 svr dhclient: DHCPACK from 0.0.0.0
Feb 26 23:44:14 svr avahi-daemon[2068]: Joining mDNS multicast group on
interface eth0.IPv4 with address 2
Feb 26 23:44:14 svr avahi-daemon[2068]: New relevant interface eth0.IPv4
for mDNS.
Feb 26 23:44:14 svr avahi-daemon[2068]: Registering new address record
for 217.70.189.87 on eth0.IPv4.
Feb 26 23:44:14 svr avahi-daemon[2068]: Withdrawing address record for
217.70.189.87 on eth0.
Feb 26 23:44:14 svr avahi-daemon[2068]: Leaving mDNS multicast group on
interface eth0.IPv4 with address 2
Feb 26 23:44:14 svr avahi-daemon[2068]: Interface eth0.IPv4 no longer
relevant for mDNS.
Feb 26 23:44:14 svr avahi-daemon[2068]: Joining mDNS multicast group on
interface eth0.IPv4 with address 2
Feb 26 23:44:14 svr avahi-daemon[2068]: New relevant interface eth0.IPv4
for mDNS.
Feb 26 23:44:14 svr avahi-daemon[2068]: Registering new address record
for 217.70.189.87 on eth0.IPv4.
Feb 26 23:44:14 svr NET[21393]: /sbin/dhclient-script : updated
/etc/resolv.conf
Feb 26 23:44:14 svr dhclient: bound to 217.70.189.87 -- renewal in 42171
seconds.

et ca recommence à 11h
Feb 27 11:27:05 svr dhclient: DHCPREQUEST on eth0 to 255.255.255.255
port 67 .....

Est ce que cela concerne toutes les merdes des derniers jours?
a+
Eric

UP.
Pour moi les pb ont commencé le 25 février, mais même constat sur une
ubuntu 7.10. Le 25 est la journée ou j'ai perdu mon serveur de midi à
18h, mais le pb continue (il y maintenant des dhcp ack une fois par jour
seulement alors que le lease consenti est de environ 35000 secondes,
d'où des pb.
Voici les logs depuis un peu avant le pb et jusque maintenant :

Feb 23 11:06:26 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 23 11:06:26 metapipes1 dhclient: DHCPNAK from 10.0.42.137
Feb 23 11:06:27 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Feb 23 11:06:27 metapipes1 dhclient: DHCPOFFER from 10.0.42.137
Feb 23 11:06:27 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 23 11:06:27 metapipes1 dhclient: DHCPACK from 10.0.42.137
Feb 23 11:06:28 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 38648 seconds.

... (aucun message dhcp)

Feb 23 21:50:36 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 23 21:50:36 metapipes1 dhclient: DHCPNAK from 10.0.42.137
Feb 23 21:50:42 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 5
Feb 23 21:50:42 metapipes1 dhclient: DHCPOFFER from 10.0.42.137
Feb 23 21:50:42 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 23 21:50:42 metapipes1 dhclient: DHCPACK from 10.0.42.137
Feb 23 21:50:43 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 41514 seconds.

... (aucun message dhcp)

Feb 24 09:22:37 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 09:22:37 metapipes1 dhclient: DHCPNAK from 10.0.42.137
Feb 24 09:22:38 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 3
Feb 24 09:22:38 metapipes1 dhclient: DHCPOFFER from 10.0.42.137
Feb 24 09:22:38 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 09:22:38 metapipes1 dhclient: DHCPACK from 10.0.42.137
Feb 24 09:22:38 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 37414 seconds.

... (aucun message dhcp)

Feb 24 19:46:12 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 19:46:12 metapipes1 dhclient: DHCPNAK from 10.0.42.137
Feb 24 19:46:14 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 5
Feb 24 19:46:14 metapipes1 dhclient: DHCPOFFER from 10.0.42.137
Feb 24 19:46:14 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 24 19:46:14 metapipes1 dhclient: DHCPACK from 10.0.42.137
Feb 24 19:46:17 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 38808 seconds.

... (rien pd cette période sur le dhcp, puis les début du PB :)

Feb 25 06:33:07 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 25 06:33:26 metapipes1 last message repeated 3 times
Feb 25 06:34:32 metapipes1 last message repeated 4 times
Feb 25 06:34:49 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67

... (les memes messages encore et encore : mon serveur est tombé à
11h55 vu de l'extérieur)

Feb 25 17:25:12 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 25 17:54:10 metapipes1 syslogd 1.4.1#21ubuntu3: restart.

... (ici les logs du reboot, c'est à ce moment que mon serveur est
remonté)
... (plus de log dhcp jusque :)

Feb 26 03:40:48 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 26 03:41:18 metapipes1 last message repeated 3 times
Feb 26 03:42:25 metapipes1 last message repeated 5 times
Feb 26 03:43:28 metapipes1 last message repeated 5 times
Feb 26 03:44:17 metapipes1 last message repeated 4 times
Feb 26 03:44:52 metapipes1 last message repeated 2 times

...(les memes messages encore et encore)

Feb 26 17:54:05 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Feb 26 17:54:05 metapipes1 dhclient: DHCPOFFER from 0.0.0.0
Feb 26 17:54:05 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 26 17:54:05 metapipes1 dhclient: DHCPACK from 0.0.0.0
Feb 26 17:54:05 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 37831 seconds.

... (j'ai une IP, donc plus de messages dhcp jusque :)

Feb 27 04:25:09 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 27 04:25:50 metapipes1 last message repeated 2 times
Feb 27 04:27:01 metapipes1 last message repeated 5 times
Feb 27 04:28:07 metapipes1 last message repeated 4 times
Feb 27 04:28:53 metapipes1 last message repeated 3 times
Feb 27 04:29:47 metapipes1 last message repeated 3 times

...(les memes messages encore et encore, jusque : )

Feb 27 17:54:10 metapipes1 dhclient: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 4
Feb 27 17:54:10 metapipes1 dhclient: DHCPOFFER from 0.0.0.0
Feb 27 17:54:10 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 27 17:54:10 metapipes1 dhclient: DHCPACK from 0.0.0.0
Feb 27 17:54:11 metapipes1 dhclient: bound to 217.70.188.73 -- renewal
in 33603 seconds.

... (j'ai une IP, donc plus de messages dhcp jusque :)

Feb 28 03:15:05 metapipes1 dhclient: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Feb 28 03:15:50 metapipes1 last message repeated 3 times
Feb 28 03:16:56 metapipes1 last message repeated 5 times

...(les memes messages encore et encore, jusque maintenant )

Bonjour,

On peut observer deux familles de traffic dhcp:

- du dhcpnak/ack d'une RFC1918 type 10.0.x.x : c'est l'ancienne version
du dhcpd, encore presente sur quelques nodes, et qui va disparaitre sous
peu. Elle est cependant stable.

- des reponses de 0.0.0.0: c'est la nouvelle version, qui entre le ~18
et le 28 fevrier, pouvait parfois arreter de repondre.

A priori, concernant ce bug (plus de réponses) c'est normalement fixé.

Si vous observez toujours des problemes dhcp, remontez les ici.

non ca marche pas:
Feb 28 10:40:46 svr last message repeated 6 times
Feb 28 10:41:56 svr last message repeated 6 times
Feb 28 10:43:05 svr last message repeated 5 times
Feb 28 10:44:15 svr last message repeated 5 times
Feb 28 10:45:27 svr last message repeated 5 times
Feb 28 10:46:44 svr last message repeated 5 times

En plus, j'ai essayé un reboot sur 92.243.1.39 pour
voir si cela était mieux et je suis maintenant planté, 
comme tous les autres ...
Le reboot est MORTEL depuis une semaine ...
Ce serait génial de revenir à la stabilité d'avant ...

Eric



Le 28 fév 2008 à 10:27 CET, kalou a écrit :

Bonjour,

On peut observer deux familles de traffic dhcp:

- du dhcpnak/ack d'une RFC1918 type 10.0.x.x : c'est l'ancienne
version
du dhcpd, encore presente sur quelques nodes, et qui va disparaitre
sous
peu. Elle est cependant stable.

- des reponses de 0.0.0.0: c'est la nouvelle version, qui entre le ~18
et le 28 fevrier, pouvait parfois arreter de repondre.

A priori, concernant ce bug (plus de réponses) c'est normalement
fixé.

Si vous observez toujours des problemes dhcp, remontez les ici.

Le 28 fév 2008 à 10:49 CET, macgiver a écrit :

Feb 28 10:45:27 svr last message repeated 5 times
Feb 28 10:46:44 svr last message repeated 5 times

En plus, j'ai essayé un reboot sur 92.243.1.39 pour
voir si cela était mieux et je suis maintenant planté, 
comme tous les autres ...

Okay, ça lève le bug aléatoire de montée des vifs/vbds que nous
corrigeons.

Le reboot "aide" dans ce cas -- lorsque c'est "bloqué".

Ce problème n'est censé pouvoir aparaitre qu'à l'initilaisation du
dev
mais lors d'une migration, on le recrée pour l'occasion. Du coup, les
clients que nous migrons (suite à une panne de node, ou pour une
mise à jour) peuvent voir ce problème.

La vm a migré le 2008-02-20 18:52:53.877765. D'où vienennt les logs
du 28 ? (du ssh, la machine était joignable ?). On vérfiie sur sur son
ancien
node.

Pour le bug, on freeze les migrations, et on cherche.

ok, c'est reparti en faisant stop/marche sur interface gandi.
La deuxieme VM a rebooté en 30 secondes seulement (reboot depuis ssh).

Les logs sont ok à présent

Les précédents logs du 28 au matin venait de cette VM par console ssh.
Contrairement aux autres testeurs aux serveurs down,  mes 2 VM sont
quasiments toujours accessibles. Seuls les reboots sont délicats (et
pas toujours). 

Le reboot semble effectivement nécessaire pour bénéficier des
correctifs
et migrations.

Merci

Eric



Le 28 fév 2008 à 12:30 CET, kalou a écrit :

Le 28 fév 2008 à 10:49 CET, macgiver a écrit :

Feb 28 10:45:27 svr last message repeated 5 times
Feb 28 10:46:44 svr last message repeated 5 times

En plus, j'ai essayé un reboot sur 92.243.1.39 pour
voir si cela était mieux et je suis maintenant planté, 
comme tous les autres ...

Okay, ça lève le bug aléatoire de montée des vifs/vbds que nous
corrigeons.

Le reboot "aide" dans ce cas -- lorsque c'est "bloqué".

Ce problème n'est censé pouvoir aparaitre qu'à l'initilaisation du
dev
mais lors d'une migration, on le recrée pour l'occasion. Du coup, les
clients que nous migrons (suite à une panne de node, ou pour une
mise à jour) peuvent voir ce problème.

La vm a migré le 2008-02-20 18:52:53.877765. D'où vienennt les logs
du 28 ? (du ssh, la machine était joignable ?). On vérfiie sur sur
son
ancien
node.

Pour le bug, on freeze les migrations, et on cherche.