Station diskless et Debian testing

Le
BERTRAND Jo=c3=abl
Bonjour à tous.

J'ai depuis quelques jours un problème assez embêtant avec mon poste de
travail. La configuration du réseau est la suivante :
- gros serveur de boot et nfs tournant sous NetBSD 8 (i7, 16 Go de
mémoire, 128 threads du serveur nfsd)
- postes de travail sous Linux ou FreeBSD tous diskless
- serveur connecté au réseau interne par lien agrégés (agr0 sous NetBSD
et un switch manageable qui comprend le protocole). Les cartes réseau du
serveur sont des intel (wm sous NetBSD) et envoient réellement 4 Gbps
vers le réseau (avec la limitation du xor entre mac source et mac
destination). Le switch est capable de gérer ces 4 Gbps sans broncher.

Un poste sous FreeBSD 11.1 fonctionne parfaitement bien. Le player
video sous Linux Debian stable fonctionne normalement lui aussi.
d'autres machines de dev du labo ne bronchent pas (arm et mips).

En revanche, mon poste de CAO électronique est à la ramasse.
Configuration de la machine : i7 4970, 16 Go de mémoire, carte réseau
gigabit. Par moment, tout fonctionne normalement. À d'autres, la charge
monte anormalement, atteignant parfois plus de dix (alors que rien ne le
justifie) et bloquant soit le système en entier, soit une application
particulière. Je précise que le poste ne swappe pas et qu'il n'y a pas
de saturation de réseau (lors de ces montées en charge, le débit réseau
est de quelques dizaines de kbps). La charge du serveur ne monte pas non
plus. La carte-mère du poste en question est une Asus thin mini-itx
(Q87T) avec deux cartes réseau, une Realtek et une intel, j'utilise
actuellement la realtek n'arrivant pas à booter sur le réseau avec la
carte intel.

J'ai l'impression que ce problème s'est aggravé avec le noyau 4.15
(avant cela, ce genre de chose pouvait arriver, mais seulement lorsque
le système commençait à swapper) et la libc qui venait avec lui. La
dernière mise à jour de la libc (hier) semble avoir un peu calmé la
chose, mais sans la corriger.

Typiquement, des applications comme seamonkey, firefox ou chromium
peuvent figer le système. Le lancement de firefox provoquait juste
l'affichage des décorations de la fenêtre, rien d'autre.

Je pensais à des histoires de segments de mémoire partagée, mais sysctl
renvoie des valeurs tout à fait correctes.

Je ne sais plus où chercher. Toute idée sera la bienvenue.

Bien cordialement,

JKB
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
BERTRAND Jo=c3=abl
Le #26472484
BERTRAND Joël a écrit :
Bonjour à tous.
J'ai depuis quelques jours un problème assez embêtant avec mon poste de
travail. La configuration du réseau est la suivante :
- gros serveur de boot et nfs tournant sous NetBSD 8 (i7, 16 Go de
mémoire, 128 threads du serveur nfsd)
- postes de travail sous Linux ou FreeBSD tous diskless
- serveur connecté au réseau interne par lien agrégés (agr0 sous NetBSD
et un switch manageable qui comprend le protocole). Les cartes réseau du
serveur sont des intel (wm sous NetBSD) et envoient réellement 4 Gbps
vers le réseau (avec la limitation du xor entre mac source et mac
destination). Le switch est capable de gérer ces 4 Gbps sans broncher.
Un poste sous FreeBSD 11.1 fonctionne parfaitement bien. Le player
video sous Linux Debian stable fonctionne normalement lui aussi.
d'autres machines de dev du labo ne bronchent pas (arm et mips).
En revanche, mon poste de CAO électronique est à la ramasse.
Configuration de la machine : i7 4970, 16 Go de mémoire, carte réseau
gigabit. Par moment, tout fonctionne normalement. À d'autres, la charge
monte anormalement, atteignant parfois plus de dix (alors que rien ne le
justifie) et bloquant soit le système en entier, soit une application
particulière. Je précise que le poste ne swappe pas et qu'il n'y a pas
de saturation de réseau (lors de ces montées en charge, le débit réseau
est de quelques dizaines de kbps). La charge du serveur ne monte pas non
plus. La carte-mère du poste en question est une Asus thin mini-itx
(Q87T) avec deux cartes réseau, une Realtek et une intel, j'utilise
actuellement la realtek n'arrivant pas à booter sur le réseau avec la
carte intel.
J'ai l'impression que ce problème s'est aggravé avec le noyau 4.15
(avant cela, ce genre de chose pouvait arriver, mais seulement lorsque
le système commençait à swapper) et la libc qui venait avec lui. La
dernière mise à jour de la libc (hier) semble avoir un peu calmé la
chose, mais sans la corriger.
Typiquement, des applications comme seamonkey, firefox ou chromium
peuvent figer le système. Le lancement de firefox provoquait juste
l'affichage des décorations de la fenêtre, rien d'autre.
Je pensais à des histoires de segments de mémoire partagée, mais sysctl
renvoie des valeurs tout à fait correctes.
Je ne sais plus où chercher. Toute idée sera la bienvenue.
Bien cordialement,
JKB


Aucune idée ? C'est franchement pénible. À certains moments, je suis
contraint d'attendre 10 minutes pour que la charge tombe... Ce n'est pas
un problème de serveur, tous les autres postes se comportent bien.
Bien cordialement,
JKB
=c3
Le #26472493
Bonsoir,
J'ai l'impression que ce problème s'est aggravé avec le
noyau 4.15 (avant cela, ce genre de chose pouvait arriver,
mais seulement lorsque le système commençait à swapper) et la
libc qui venait avec lui. La dernière mise à jour de la libc
(hier) semble avoir un peu calmé la chose, mais sans la
corriger.

Aucune idée ?

Pas vraiment d'idée, les problèmes intermittents sont les plus
compliqués à résoudre. À vue de nez, il faudrait tester avec une
autre carte réseau, mais si la carte mère ne permet le PXE boot
que sur sa carte intégrée, ça va être compliqué à vérifier.
Sans toucher au matériel, l'absence générale de charge lors d'un
gel de la machine suggère un timeout quelconque. Ça pourait, par
exemple, venir de la configuration du DNS (mais j'imagine que le
post client monte son NFS root via l'IP), ou peut-être du Name
Service Cache Daemon nscd (mais si vous utilisez directement
/etc/passwd tel que monté en NFS root, vous n'en avez peut-être
pas l'usage, le service est prévu pour doper des outils de
centralisation des logins comme LDAP ou du NIS).
En espérant que ça aide à débroussailler une piste,
--
Étienne Mollier
BERTRAND Jo=c3=abl
Le #26472498
Étienne Mollier a écrit :
Bonsoir,
J'ai l'impression que ce problème s'est aggravé avec le
noyau 4.15 (avant cela, ce genre de chose pouvait arriver,
mais seulement lorsque le système commençait à swapper) et la
libc qui venait avec lui. La dernière mise à jour de la libc
(hier) semble avoir un peu calmé la chose, mais sans la
corriger.


Aucune idée ?

Pas vraiment d'idée, les problèmes intermittents sont les plus
compliqués à résoudre. À vue de nez, il faudrait tester avec une
autre carte réseau, mais si la carte mère ne permet le PXE boot
que sur sa carte intégrée, ça va être compliqué à vérifier.

Je n'ai pas l'impression que la carte réseau soit en cause (les autres
applications appelant elles aussi les disques NFS ne sont pas
impactées). J'ai l'impression que ça touche soit le pilote de la carte
réseau soit le protocole NFS.
Sans toucher au matériel, l'absence générale de charge lors d'un
gel de la machine suggère un timeout quelconque. Ça pourait, par
exemple, venir de la configuration du DNS (mais j'imagine que le
post client monte son NFS root via l'IP), ou peut-être du Name
Service Cache Daemon nscd (mais si vous utilisez directement
/etc/passwd tel que monté en NFS root, vous n'en avez peut-être
pas l'usage, le service est prévu pour doper des outils de
centralisation des logins comme LDAP ou du NIS).

Tout est monté en dur via les adresses IP. Le NIS et le DNS
fonctionnent parfaitement... Lorsque une application se met en attente
NFS, la charge monte très vite et très haut. Jusqu'au moment où ça se
remet à fonctionner normalement. Aucune trace dans les logs, ce serait
trop facile.
Bien cordialement,
JKB
=c3
Le #26472508
Joël Bertrand, le 2018-04-16 :
Je n'ai pas l'impression que la carte réseau soit en
cause (les autres applications appelant elles aussi les disques
NFS ne sont pas impactées). J'ai l'impression que ça touche
soit le pilote de la carte réseau soit le protocole NFS.

[...]
Étienne Mollier a écrit :
Sans toucher au matériel, l'absence générale de charge lors
d'un gel de la machine suggère un timeout quelconque. Ça
pourait, par exemple, venir de la configuration du DNS (mais
j'imagine que le post client monte son NFS root via l'IP), ou
peut-être du Name Service Cache Daemon nscd (mais si vous
utilisez directement /etc/passwd tel que monté en NFS root,
vous n'en avez peut-être pas l'usage, le service est prévu
pour doper des outils de centralisation des logins comme LDAP
ou du NIS).

Tout est monté en dur via les adresses IP. Le NIS et le
DNS fonctionnent parfaitement... Lorsque une application se met
en attente NFS, la charge monte très vite et très haut.
Jusqu'au moment où ça se remet à fonctionner normalement.
Aucune trace dans les logs, ce serait trop facile.


Oups, après l'heure, ce n'est plus l'heure... é_è
J'ai lu de travers le message initial à propos de la charge,
désolé. Effectivement, ça ressemble beaucoup moins à un timeout
et beaucoup plus à un problème de perte temporaire de la
connexion entre le client et le serveur NFS, à ceci près que cela
ne concerne qu'une petite sélection de programmes intensifs.
Curieux...
Autre idée : j'ai eu un cas un peu similaire il y a quelques
années avec gvfsd, un service Gnome qui faisait « des trucs » en
travaillant en boucle sur des petits fichiers dans le home. Avec
un home monté NFS, forcément, ça se passait moins bien.
Symlinker le répertoire concerné dans un espace local (disque
local, /dev/shm, peu importe) avait résorbé le problème. Le
volume de données échangé n'était pas énorme, mais l'attente
entre chaque requête et chaque réponse suffisait à ralentir le
tout. Le problème venait de la latence et non du débit. Mais je
ne me souviens plus exactement du comportement de la charge.
Si le problème se déclenche au lancement d'applications du type à
manipuler du cache pour des raisons de performances (navigateurs
web, java, etc), est-ce que diminuer, rediriger en local, ou
supprimer ledit cache permettrait de diminuer l'ampleur des
sautes d'humeur du poste de CAO ?
En espérant ne pas être tombé trop à côté de la question cette
fois ci, :-)
À plus,
--
Étienne Mollier
BERTRAND Jo=c3=abl
Le #26472524
Étienne Mollier a écrit :
Joël Bertrand, le 2018-04-16 :
Je n'ai pas l'impression que la carte réseau soit en
cause (les autres applications appelant elles aussi les disques
NFS ne sont pas impactées). J'ai l'impression que ça touche
soit le pilote de la carte réseau soit le protocole NFS.

[...]
Étienne Mollier a écrit :
Sans toucher au matériel, l'absence générale de charge lors
d'un gel de la machine suggère un timeout quelconque. Ça
pourait, par exemple, venir de la configuration du DNS (mais
j'imagine que le post client monte son NFS root via l'IP), ou
peut-être du Name Service Cache Daemon nscd (mais si vous
utilisez directement /etc/passwd tel que monté en NFS root,
vous n'en avez peut-être pas l'usage, le service est prévu
pour doper des outils de centralisation des logins comme LDAP
ou du NIS).

Tout est monté en dur via les adresses IP. Le NIS et le
DNS fonctionnent parfaitement... Lorsque une application se met
en attente NFS, la charge monte très vite et très haut.
Jusqu'au moment où ça se remet à fonctionner normalement.
Aucune trace dans les logs, ce serait trop facile.

Oups, après l'heure, ce n'est plus l'heure... é_è
J'ai lu de travers le message initial à propos de la charge,
désolé. Effectivement, ça ressemble beaucoup moins à un timeout
et beaucoup plus à un problème de perte temporaire de la
connexion entre le client et le serveur NFS, à ceci près que cela
ne concerne qu'une petite sélection de programmes intensifs.
Curieux...

N'est-ce pas ? ;-)
Autre idée : j'ai eu un cas un peu similaire il y a quelques
années avec gvfsd, un service Gnome qui faisait « des trucs » en
travaillant en boucle sur des petits fichiers dans le home. Avec
un home monté NFS, forcément, ça se passait moins bien.
Symlinker le répertoire concerné dans un espace local (disque
local, /dev/shm, peu importe) avait résorbé le problème. Le
volume de données échangé n'était pas énorme, mais l'attente
entre chaque requête et chaque réponse suffisait à ralentir le
tout. Le problème venait de la latence et non du débit. Mais je
ne me souviens plus exactement du comportement de la charge.
Si le problème se déclenche au lancement d'applications du type à
manipuler du cache pour des raisons de performances (navigateurs
web, java, etc), est-ce que diminuer, rediriger en local, ou
supprimer ledit cache permettrait de diminuer l'ampleur des
sautes d'humeur du poste de CAO ?

Les programmes incriminés sont principalement les navigateurs web
(seamonkey, firefox, chromium). Pas d'autre activité suspecte lorsque le
problème survient. J'ai forcé le cache de seamonkey à 0. Je ne suis pas
sûr que cela arrange la chose puisque durant les périodes fautives, il
n'y a pas d'activité nfs. Comme si Linux attendait quelque chose. J'ai
aussi l'impression que le problème est survenu avec le noyau 4.15 (je
n'ai pas noté ce genre de problème auparavant sauf lorsque la machine se
mettait à swapper, mais tous les programmes étaient impactés).
Bien cordialement,
JKB
BERTRAND Jo=c3=abl
Le #26472564
Étienne Mollier a écrit :
Si le problème se déclenche au lancement d'applications du type à
manipuler du cache pour des raisons de performances (navigateurs
web, java, etc), est-ce que diminuer, rediriger en local, ou
supprimer ledit cache permettrait de diminuer l'ampleur des
sautes d'humeur du poste de CAO ?

Un petit retour. J'ai désactivé le cache, ça améliore un tout petit peu
les choses. J'ai noté avec un tcpdump que des requêtes NFS passaient
lors des périodes où les applications bloquaient, requêtes ayant des
réponses normales (et à un débit ridicule, quelques dizaines de kbps sur
une réseau loin d'être engorgé et avec un serveur qui fait les pieds au
mur en même temps). Lors de ces problèmes, aucun souci de résolution de
nom ou autre chose. Pas de problème de réseau non plus (j'ai un
vncviewer ouvert sur une machine distante qui continue à fonctionner
parfaitement). C'est un peu comme si le client NFS mettait en cache des
requêtes et oubliait de les envoyer...
Bien cordialement,
JKB
=c3
Le #26472641
Joël Bertrand, le mardi 17 avril 2018 :
Étienne Mollier a écrit :
Si le problème se déclenche au lancement d'applications du
type à manipuler du cache pour des raisons de performances
(navigateurs web, java, etc), est-ce que diminuer, rediriger
en local, ou supprimer ledit cache permettrait de diminuer
l'ampleur des sautes d'humeur du poste de CAO ?

Les programmes incriminés sont principalement les
navigateurs web (seamonkey, firefox, chromium). Pas d'autre
activité suspecte lorsque le problème survient. J'ai forcé le
cache de seamonkey à 0. Je ne suis pas sûr que cela arrange la
chose puisque durant les périodes fautives, il n'y a pas
d'activité nfs. Comme si Linux attendait quelque chose. J'ai
aussi l'impression que le problème est survenu avec le noyau
4.15 (je n'ai pas noté ce genre de problème auparavant sauf
lorsque la machine se mettait à swapper, mais tous les
programmes étaient impactés).
Un petit retour. J'ai désactivé le cache, ça améliore un
tout petit peu les choses. J'ai noté avec un tcpdump que des
requêtes NFS passaient lors des périodes où les applications
bloquaient, requêtes ayant des réponses normales (et à un débit
ridicule, quelques dizaines de kbps sur une réseau loin d'être
engorgé et avec un serveur qui fait les pieds au mur en même
temps). Lors de ces problèmes, aucun souci de résolution de nom
ou autre chose. Pas de problème de réseau non plus (j'ai un
vncviewer ouvert sur une machine distante qui continue à
fonctionner parfaitement). C'est un peu comme si le client NFS
mettait en cache des requêtes et oubliait de les envoyer...

Bonsoir,
C'est toujours ça de pris. Avec un peu de chance, désactiver une
tâche de fond du type à mettre à jour des caches pourrait aider,
typiquement mlocate/updatedb (m'enfin celui-ci n'est censé ne
tourner que quotidiennement par défaut, et n'était probablement
pas en train de tourner lors de vos essais).
Du côté « correction du mal à la racine », le noyau 4.15 a
effectivement vu des modifications de son client NFS, versions 3
et 4, entre autres dans sa gestion des caches, depuis le noyau
4.14 :
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/fs/nfs/?id=v4.14&id2=v4.15.16&dt=2
À part dans nfs4proc.c, les changements ne donnent pas
l'impression d'avoir été francs non plus. La migration depuis
refcount vers atomic est éventuellement suspecte. Avez-vous la
possibilité de tester les diverses versions de NFS pour voir si
le problème se maintient d'une version à l'autre, ou bien c'est
délicat ?
À plus,
--
Étienne Mollier
BERTRAND Jo=c3=abl
Le #26472649
Étienne Mollier a écrit :
Joël Bertrand, le mardi 17 avril 2018 :
Étienne Mollier a écrit :
Si le problème se déclenche au lancement d'applications du
type à manipuler du cache pour des raisons de performances
(navigateurs web, java, etc), est-ce que diminuer, rediriger
en local, ou supprimer ledit cache permettrait de diminuer
l'ampleur des sautes d'humeur du poste de CAO ?

Les programmes incriminés sont principalement les
navigateurs web (seamonkey, firefox, chromium). Pas d'autre
activité suspecte lorsque le problème survient. J'ai forcé le
cache de seamonkey à 0. Je ne suis pas sûr que cela arrange la
chose puisque durant les périodes fautives, il n'y a pas
d'activité nfs. Comme si Linux attendait quelque chose. J'ai
aussi l'impression que le problème est survenu avec le noyau
4.15 (je n'ai pas noté ce genre de problème auparavant sauf
lorsque la machine se mettait à swapper, mais tous les
programmes étaient impactés).

Un petit retour. J'ai désactivé le cache, ça améliore un
tout petit peu les choses. J'ai noté avec un tcpdump que des
requêtes NFS passaient lors des périodes où les applications
bloquaient, requêtes ayant des réponses normales (et à un débit
ridicule, quelques dizaines de kbps sur une réseau loin d'être
engorgé et avec un serveur qui fait les pieds au mur en même
temps). Lors de ces problèmes, aucun souci de résolution de nom
ou autre chose. Pas de problème de réseau non plus (j'ai un
vncviewer ouvert sur une machine distante qui continue à
fonctionner parfaitement). C'est un peu comme si le client NFS
mettait en cache des requêtes et oubliait de les envoyer...

Bonsoir,
C'est toujours ça de pris. Avec un peu de chance, désactiver une
tâche de fond du type à mettre à jour des caches pourrait aider,
typiquement mlocate/updatedb (m'enfin celui-ci n'est censé ne
tourner que quotidiennement par défaut, et n'était probablement
pas en train de tourner lors de vos essais).

C'est le premier truc que je désactive.
Du côté « correction du mal à la racine », le noyau 4.15 a
effectivement vu des modifications de son client NFS, versions 3
et 4, entre autres dans sa gestion des caches, depuis le noyau
4.14 :
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/diff/fs/nfs/?id=v4.14&id2=v4.15.16&dt=2
À part dans nfs4proc.c, les changements ne donnent pas
l'impression d'avoir été francs non plus. La migration depuis
refcount vers atomic est éventuellement suspecte. Avez-vous la
possibilité de tester les diverses versions de NFS pour voir si
le problème se maintient d'une version à l'autre, ou bien c'est
délicat ?

C'est un peu délicat. De toute façon, je n'ai que NFSv2 et v3 côté
NetBSD. Il y a bien le code NEW_NFS qui est le NFS de FreeBSD dans le
noyau, mais il n'est pas aisément compilable et dans un état incertain.
J'ai essayé de le compiler sans succès cet après-midi.
Quoi qu'il en soit, je pourrais forcer un NFSv2, mais je ne suis pas
sûr que ça améliorera les choses...
Pour avoir continué mes essais, j'ai l'impression que le problème
tourne autour de lockd. C'est lui qui semble partir en timeout. Côté
serveur, j'ai un tas de :
Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:01 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:01 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:02 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:02 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:04 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:04 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
Apr 17 12:28:05 legendre rpc.lockd: duplicate lock from hilbert.2
Apr 17 12:28:05 legendre rpc.lockd: no matching entry for hilbert
que je n'avais pas avant. J'ai essayé de remonter la partition /home
(puisque c'est celle qui semble poser problème) avec l'option nolock et
je n'obtiens qu'un :
:~# mount -o remount,rw,nolock /home
mount.nfs: an incorrect mount option was specified
ceci expliquant sans doute cela.
Autre chose qui semble avoir changé. Mon fstab contient :
192.168.10.128:/srv/hilbert / nfs intr,tcp,nfsvers=3,async 0 0
192.168.10.128:/home /home nfs intr,tcp,nfsvers=3,async 0 0
/swapfile.0 none swap sw 0 0
Pourtant, les montages sont reconnus par le système comme :
:~# nfsstat -m
/ from 192.168.10.128:/srv/hilbert
Flags:
rw,relatime,vers=3,rsizee536,wsizee536,namlen%5,hard,nolock,proto=tcp,port 49,timeo=7,retrans,sec=sys,local_lock=all,addr2.168.10.128
/home from 192.168.10.128:/home
Flags:
rw,relatime,vers=3,rsizee536,wsizee536,namlen%5,hard,proto=tcp,timeo`0,retrans=2,sec=sys,mountaddr2.168.10.128,mountvers=3,mountport20,mountproto=tcp,local_lock=none,addr2.168.10.128
Je suppose que c'est encore un coup de la bouse systemd qui modifie les
options puisque / est monté avec un nolock et /home avec un lock. Je
précise que le fstab n'a pas changé depuis le 8 janvier 2017 et que tout
fonctionnait correctement.
Bien cordialement,
JKB
BERTRAND Jo=c3=abl
Le #26473387
Bonsoir à tous,
J'avance sur mon problème. Je viens de m'apercevoir que mon syslog est
plein de lignes comme ceci :
Apr 28 17:35:23 hilbert kernel: [282745.749938] lockd: server
192.168.10.128 not responding, still trying
Apr 28 17:35:23 hilbert kernel: [282745.749969] xs_tcp_setup_socket:
connect returned unhandled error -107
Apr 28 17:35:29 hilbert kernel: [282751.810082] lockd: server
192.168.10.128 OK
Apr 28 18:27:15 hilbert kernel: [285857.121396] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:15 hilbert kernel: [285857.373345] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:16 hilbert kernel: [285858.641114] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:25 hilbert kernel: [285866.965630] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:27:26 hilbert kernel: [285868.225678] lockd: server
192.168.10.128 not responding, still trying
Apr 28 18:28:36 hilbert kernel: [285938.011610] lockd: server
192.168.10.128 OK
Apr 28 18:28:37 hilbert kernel: [285939.019589] lockd: server
192.168.10.128 OK
Apr 28 18:28:45 hilbert kernel: [285947.627997] lockd: server
192.168.10.128 OK
Apr 28 18:28:47 hilbert kernel: [285949.139779] lockd: server
192.168.10.128 OK
Il y a donc un truc qui casse au moins NFSv3 dans le noyau 4.15.17-1 de
chez Debian. Je précise que lorsque je me prends ce genre d'erreur
depuis mon poste de dev, toutes les autres machines diskess utilisant le
même serveur (arm, x86 FreeBSD...) fonctionnement parfaitement. Je
n'arrive pas à savoir si lockd par en timeout sur l'erreur 107 ou si
c'est le contraire.
Bien cordialement,
JKB
BERTRAND Jo=c3=abl
Le #26474167
BOITEUX, Frederic a écrit :
Bonjour,
Je crois que depuis Stretch, le protocole NFS est passé par défaut en TCP, est-ce que tu as bien configuré ton accès NFS si tu veux accéder à un serveur qui est toujours en UDP (j'imagine en NFSv3) ? Voir les options de mount, comme « proto=udp » …

Bonsoir,
Tout est en TCP et en v3, client comme serveur. J'ai viré le lockd et
fait un rapport d'erreur sur le noyau. Avec un noyau plus ancien et la
même version de nfsd/lockd, ça ne provoque pas ce genre d'erreur sur le
serveur.
Bien cordialement,
JKB
Publicité
Poster une réponse
Anonyme