Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Boot tres lent avec nfs dhcp et networkmanager

9 réponses
Avatar
Christophe Maquaire
Bonjour la liste,

Sur une machine en testing, j'ai un probl=E8me de boot tr=E8s lent.

Cette machine monte (fstab,auto) un r=E9pertoire nfs (V4) distant,
elle obtient une adresse IPV4 par dhcp, et network-manager est cens=E9
g=E9rer la connexion au r=E9seau.

Il s'=E9coule environ 3 minutes (visible dans dmesg) ou on attend
probablement un timeout, mais je ne sais pas de qui.

Si le montage nfs auto est comment=E9 dans fstab, la s=E9quence de
d=E9marrage retrouve une dur=E9e normale.

Ce comportement date probablement d'une mise =E0 jour d'il y a environ 2
mois, le probl=E8me n'existait pas auparavant.=20
Ce n'est certes pas bien grave puisque tout fonctionne, c'est
juste aga=E7ant...=20


Les infos:

/etc/network/interfaces ne ressemble plus =E0 grand-chose depuis le
passage de network-manager
=20
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
#NetworkManager#iface eth0 inet dhcp

Modifier /etc/NetworkManager/NetworkManager.conf (managed=3Dtrue ou
false) ne change rien =E0 l'affaire. =20

[main]
plugins=3Difupdown,keyfile
no-auto-default=3D00:1e:8c:26:f4:87,
[ifupdown]
managed=3Dtrue #or false idem...

la ligne utile de fstab:
192.168.2.253:/ /andre nfs4 defaults,user,nolock 0 0

voici ce que dit dmesg:=20

(oui, il ne se passe vraiment rien de visible entre [ 9.137411] et
[ 190.045095]=20

[ 8.037688] loop: module loaded
[ 9.073817] RPC: Registered named UNIX socket transport module.
[ 9.073821] RPC: Registered udp transport module.
[ 9.073824] RPC: Registered tcp transport module.
[ 9.073826] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 9.087008] FS-Cache: Loaded
[ 9.137411] FS-Cache: Netfs 'nfs' registered for caching
[ 190.045095] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 191.324993] fuse init (API version 7.17)
[ 195.435076] sky2 0000:02:00.0: eth0: enabling interface
[ 195.435481] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 196.297910] input: ACPI Virtual Keyboard Device
as /devices/virtual/input/input6=20
[ 198.007855] sky2 0000:02:00.0:
eth0: Link is up at 1000 Mbps, full duplex, flow control both=20
[ 198.008087] ADDRCONF(NETDEV_CHANGE): eth0: link becomes
ready

les logs du serveur dhcp et nfs (c'est le m=EAme...)

Jul 21 16:38:23 albert dhcpd: DHCPDISCOVER from 00:1e:8c:50:76:1a via
eth0=20
Jul 21 16:38:23 albert dhcpd: DHCPOFFER on 192.168.2.2 to
00:1e:8c:50:76:1a via eth0=20
Jul 21 16:38:23 albert dhcpd: DHCPREQUEST
for 192.168.2.2 (192.168.2.253) from 00:1e:8c:50:76:1a via eth0=20
Jul 21 16:38:23 albert dhcpd: DHCPACK on 192.168.2.2 to
00:1e:8c:50:76:1a via eth0=20
Jul 21 16:38:31 albert rpc.mountd[20252]: authenticated mount
request from 192.168.2.2:735 for /export (/export)

et dmesg sans le montage nfs:

[ 9.551736] FS-Cache: Netfs 'nfs' registered for caching
[ 9.574030] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 10.854692] fuse init (API version 7.17)
[ 15.199781] sky2 0000:02:00.0: eth0: enabling interface
[ 15.200125] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 16.094080] input: ACPI Virtual Keyboard Device
as /devices/virtual/input/input6=20
[ 17.716315] sky2 0000:02:00.0:eth0: Link is up at 1000 Mbps, full
duplex, flow control both=20
[ 17.716520] ADDRCONF(NETDEV_CHANGE): eth0:link becomes ready

--=20
Christophe Maquaire=20
Happy Debian User

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20120721173053.fde62b9c919f170cf1ad0071@free.fr

9 réponses

Avatar
Sylvain L. Sauvage
Le samedi 21 juillet 2012 à 17:30:53, Christophe Maquaire a
écrit :
Bonjour la liste,



’jour,

Sur une machine en testing, j'ai un problème de boot très
lent.

Cette machine monte (fstab,auto) un répertoire nfs (V4)
distant, elle obtient une adresse IPV4 par dhcp, et
network-manager est censé gérer la connexion au réseau.

Il s'écoule environ 3 minutes (visible dans dmesg) ou on
attend probablement un timeout, mais je ne sais pas de qui.

Si le montage nfs auto est commenté dans fstab, la séquence
de démarrage retrouve une durée normale.
[…]



Les « infos » que tu donnes ne sont pas très utiles (en
particulier les dmesg). Puisqu’il semble que ce soient le DHCP
et le NFS du côté client qui prennent du temps, ce sont leurs
logs qui nous intéressent. C’est-à-dire
/var/log/daemon.log
et
/var/log/syslog
côté _client_.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Jean-Michel OLTRA
Bonjour,


Le samedi 21 juillet 2012, Christophe Maquaire a écrit...


Cette machine monte (fstab,auto) un répertoire nfs (V4) distant,
elle obtient une adresse IPV4 par dhcp, et network-manager est censé
gérer la connexion au réseau.



J'ai eu ça sur la machine de ma fille. Étant donné que c'est une tour
qui n'a pas besoin de network-manager, je l'ai viré, et tout va bien…

--
jm

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Christophe Maquaire
Le dimanche 22 juillet 2012 à 16:07 +0200, Jean-Michel OLTRA a écrit :
Bonjour,

J'ai eu ça sur la machine de ma fille. Étant donné que c'est une tour
qui n'a pas besoin de network-manager, je l'ai viré, et tout va bien…



J'avoue que j'hésite entre virer network-manager (mais j'ai une
utilisatrice qui a ses habitudes avec le petit widget dans la barre de
gnome) et un montage du partage nfs à la connexion et non plus au boot,
mais que j'aimerais bien que ça tombe en marche, parce que y'a pa
d'raison...

--
Christophe Maquaire
Happy Debian User


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Christophe Maquaire
Le samedi 21 juillet 2012 à 18:11 +0200, Sylvain L. Sauvage a écrit :

’jour,



Re,
mes excuses pour le rythme de la conversation, mais l'appel du grand air
lors de ces rares jours presques estivaux dans ma région d'habitation
est irrésistible...

Les « infos » que tu donnes ne sont pas très utiles (en
particulier les dmesg). Puisqu’il semble que ce soient le DHCP
et le NFS du côté client qui prennent du temps, ce sont leurs
logs qui nous intéressent. C’est-à-dire
/var/log/daemon.log
et
/var/log/syslog
côté _client_.



Avec plaisir, mais je n'y vois pas grand chose de bien plus informatif.

Ils sont ici:
http://www.ce2c.com/files/daemon.log
et là:
http://www.ce2c.com/files/syslog

--
Christophe Maquaire
Happy Debian User

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
moi-meme
Le Sun, 22 Jul 2012 16:10:02 +0200, Jean-Michel OLTRA a écrit :

J'ai eu ça sur la machine de ma fille. Étant donné que c'est une tour
qui n'a pas besoin de network-manager, je l'ai viré, et tout va bien…



+1

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/500c5003$0$6129$
Avatar
Jean-Michel OLTRA
Bonjour,


Le dimanche 22 juillet 2012, moi-meme a écrit...


> J'ai eu ça sur la machine de ma fille. Étant donné que c'est une tour
> qui n'a pas besoin de network-manager, je l'ai viré, et tout va bien…

+1



J'ajoute, uniquement pour mettre de l'huile sur le feu, et parce qu'on
est pas vendredi, que NM pose plus de problèmes qu'il en résoud, dans le
cadre d'une tour. Ce n'est pas la première fois que je le supprime…

--
jm

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Sylvain L. Sauvage
Le dimanche 22 juillet 2012 à 21:12:38, Christophe Maquaire a
écrit :
[…]
Re,



’soir,

mes excuses pour le rythme de la conversation,



C’est pas non plus comme si on attendait fébrilement :o)
(même si la date de cette réponse pourrait indiquer le
contraire… ;o)

[…]
Avec plaisir, mais je n'y vois pas grand chose de bien plus
informatif.

Ils sont ici:
http://www.ce2c.com/files/daemon.log
et là:
http://www.ce2c.com/files/syslog



Ça indique déjà que le DHCP se passe bien et rapidement.
Ça devrait aussi prouver qu’il n’y a pas d’e rreur dans le
montage.

Sinon, les montages doivent aussi apparaître dans
/var/log/boot (si bootlogd est installé). Ça permet d’avo ir une
datation plus précise.

Je vois deux causes possibles au délai :

1. le script /etc/network/if-up.d/mountnfs n’est pas lancé tout
de suite. Mais je ne vois pas vraiment pourquoi ça
attendrait : soit il est lancé, soit il n’est pas lancà ©.
Tu peux essayé d’ajouter quelques commandes dans le script
pour voir quand exactement il est lancé. Si ce n’est pas
immédiat, on pourra vraiment dire que c’est la faute à NM ;

2. c’est le script qui attend (ou, plutôt, le script ne lance le
montage qu’après que la dernière interface résau soit activée
puisqu’il est lancé à chaque interface). Dans ce cas, il
doit y avoir un message. Et puis il faut plusieurs
interfaces…

Quelques options :
— essayer l’option bg ;
— utiliser autofs ;
— supprimer NM (si tu n’en as pas besoin, c’est eff ectivement le
plus simple mais ça ne répond pas au pourquoi (« Dites-nou s ce
dont vous avez besoin ; on vous expliquera comment vous en
passer. »)).

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Christophe Maquaire
Le dimanche 22 juillet 2012 à 22:39 +0200, Sylvain L. Sauvage a écrit :
Le dimanche 22 juillet 2012 à 21:12:38, Christophe Maquaire a
écrit :


bonsoir,

Sinon, les montages doivent aussi apparaître dans
/var/log/boot (si bootlogd est installé). Ça permet d’avoir une
datation plus précise.



Bon, c'est fait, et clairement c'est le montage nfs qui est en echec

Je vois deux causes possibles au délai :

1. le script /etc/network/if-up.d/mountnfs n’est pas lancé tout
de suite. Mais je ne vois pas vraiment pourquoi ça
attendrait : soit il est lancé, soit il n’est pas lancé.
Tu peux essayé d’ajouter quelques commandes dans le script
pour voir quand exactement il est lancé. Si ce n’est pas
immédiat, on pourra vraiment dire que c’est la faute à NM ;



il est bien lancé tôt. C'est effectivement la faute à NM (cf infra)


2. c’est le script qui attend (ou, plutôt, le script ne lance le
montage qu’après que la dernière interface résau soit activée
puisqu’il est lancé à chaque interface). Dans ce cas, il
doit y avoir un message. Et puis il faut plusieurs
interfaces…



Oui, j'ai parcouru aussi les scripts d'init (laborieusement..)
et /etc/network/if-up.d/mountnfs
j'ai tenté d'insérer un nm-online, histoire d'attendre le feu vert sans
le timeout mais sans succès

Quelques options :
— essayer l’option bg ;



Idem, au passage j'ai essayé _netdev (des fois que..) et là c'est encore
plus drôle, on a 2 fois le time-out...

— utiliser autofs ;
— supprimer NM (si tu n’en as pas besoin, c’est effectivement le
plus simple mais ça ne répond pas au pourquoi (« Dites-nous ce
dont vous avez besoin ; on vous expliquera comment vous en
passer. »)).



Ou envisager de patienter 3 minutes à chaque boot en attendant la
correction des mainteneurs...

finalement, en cherchant un peu, j'ai trouvé ça:

http://bugs.debian.org/cgi-bin/bugreport.cgi?buge6584
où il apparaît que le bug est connu, qu'il n'y a pas encore vraiment de
solution, que l'origine du problème est l'interaction entre ifupdown et
network-manager et où l'on assiste à un ping-pong entre mainteneurs
(c'est ton bug, pas le mien...) avec un coup de sifflet de l'arbitre...

Merci encore pour tes indices
--
Christophe Maquaire
Happy debian User

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Sylvain L. Sauvage
Le lundi 23 juillet 2012 à 22:24:04, Christophe Maquaire a écrit
:
[…]
finalement, en cherchant un peu, j'ai trouvé ça:

http://bugs.debian.org/cgi-bin/bugreport.cgi?buge6584
où il apparaît que le bug est connu, qu'il n'y a pas encore
vraiment de solution, que l'origine du problème est
l'interaction entre ifupdown et network-manager et où l'on
assiste à un ping-pong entre mainteneurs (c'est ton bug, pas
le mien...) avec un coup de sifflet de l'arbitre...



Paf, fait la main sur le front. Je l’avais vu mais je m’ étais
arrêté au « pas de montage du tout »…

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/