[RESOLU] Starting NFS common utilities: statd Failed après un reset

Kasi · Le 04/07/2009, à 19:40

Bonjour,

je suis en train de monter un serveur sous debian lenny pour apprendre différentes choses.

Jusque là tout allait bien, j'avais réussi à configurer iptables, mettre ssh et ftp.

Suite à un article d'iptables, j'ai rajouté une règle qui à bloquer mon accès SSH (oui je sais...). N'ayant pas d'écran ni de clavier de branchés sur le serveur j'ai dû faire un reset après les avoir branchés.

Le problème c'est que maintenant le serveur est extrêmement long à démarrer, il passe plusieurs minutes sur l'instruction "starting NFS common utilities: statd" pour ensuite finir par un "failed" et continuer le chargement.

Une fois le serveur démarrer et que je demande son arrêt, il passe plusieurs minutes sur l'instruction "Stopping portmap deamon...".

La solution de facilité serait de tout formater pour tout réinstaller, mais j'aimerais éviter car je n'ai pas récupéré mes configurations (oui je sais je peux démarrer un live cd pour les récupérer, mais autant essayer de résoudre le problème et apprendre).

Voila, pouvez-vous m'aider ?
Merci

Dernière modification par Kasi (Le 05/07/2009, à 14:05)

Grunt · Le 04/07/2009, à 19:56

Si tu fais ça, ça résoud le problème?

rm -rf /var/run/network/mountnfs

Kasi · Le 04/07/2009, à 20:20

serveur:~# ls -al /var/run/network/
total 8
drwxr-xr-x  2 root root  4096 2009-07-04 14:32 .
drwxr-xr-x  7 root root  4096 2009-07-04 20:10 ..

Il n'y a donc rien à supprimer...

Grunt · Le 04/07/2009, à 20:35

Arf, c'est plutôt une manip' côté client, ce que je t'ai donné.

Je pensais à un bug connu de Debian: quand un client NFS est éteint brutalement, il ne supprime pas le fichier "/var/run/network/mountnfs", ce qui l'empêche de faire le montage automatique au démarrage d'après, il faut alors refaire le montage à la main.

Ça ressemble à ce que tu as, sauf que toi c'est côté serveur. Regarde dans /var/run et /var/lock si un fichier n'est pas resté, qui indiquerait la présence d'un montage NFS.

Kasi · Le 04/07/2009, à 20:43

/var/lock/ est vide.

/var/run/ :

serveur:~# ls -al /var/run/
total 76
drwxr-xr-x  7 root        root        4096 jui  4 20:14 .
drwxr-xr-x 14 root        root        4096 jui  2 14:13 ..
-rw-r--r--  1 root        root           5 jui  4 20:11 acpid.pid
srw-rw-rw-  1 root        root           0 jui  4 20:11 acpid.socket
-rw-r--r--  1 root        root           5 jui  4 20:14 atd.pid
-rw-r--r--  1 root        root           5 jui  4 20:14 crond.pid
----------  1 root        root           0 jui  4 20:14 crond.reboot
-rw-r--r--  1 root        root           5 jui  4 20:09 dhclient.eth0.pid
drwxr-x---  2 Debian-exim Debian-exim 4096 jui  4 20:11 exim4
drwxr-xr-x  2 root        root        4096 jui  4 20:14 fail2ban
-rw-r--r--  1 root        root           5 jui  4 20:14 inetd.pid
-rw-r--r--  1 root        root         358 jui  4 20:11 motd
drwxr-xr-x  2 root        root        4096 jui  4 20:09 network
-rw-------  1 root        root           0 jui  4 20:08 portmap_mapping
-rw-r--r--  1 root        root           5 jui  4 20:08 portmap.pid
drwx------  2 root        root        4096 jui  4 19:02 pure-ftpd
-rw-r--r--  1 root        root           0 jui  4 20:14 rpc.statd.pid
-rw-r--r--  1 root        root           5 jui  4 20:11 rsyslogd.pid
-rw-------  1 root        root           5 jui  4 20:08 sm-notify.pid
drwxr-xr-x  2 root        root        4096 jan 14 01:40 sshd
-rw-r--r--  1 root        root           5 jui  4 20:11 sshd.pid
-rw-rw-r--  1 root        utmp        4224 jui  4 20:41 utmp

Grunt · Le 04/07/2009, à 20:56

Essaie en mettant

NEED_STATD=no

Dans "/etc/default/nfs-common".

Kasi · Le 04/07/2009, à 21:07

Cette solution corrige le problème.

Peux-tu me dire ce que ça fait et quelles en sont les conséquences ?

Grunt · Le 04/07/2009, à 22:03

Kasi a écrit :

Cette solution corrige le problème.

Cool.

Peux-tu me dire ce que ça fait et quelles en sont les conséquences ?

Je sais pas, faut demander ici

Ceci dit, le monsieur qui conseille de faire ça semble s'y connaître: http://linux.leunen.com/

Kasi · Le 04/07/2009, à 22:36

J'ai envoyé un mail, on verra bien la réponse .

Kasi · Le 05/07/2009, à 13:59

Voici l'explication de l'auteur :

statd est un daemon (status daemon) c'est à dire un service qui tourne en fond et qui sert à signaler aux clients NFS des problèmes éventuels avec le serveur NFS. C'est le cas, par exemple, quand le serveur plante et qu'on le relance.
Autrement dit, mettre 'NEED_STATD=no' revient à dire de ne pas utiliser statd. Ce daemon ne sera donc pas lancé en même temps que le serveur. Ca n'a pas grande importance. NFS peut très bien tourner sans. Et si ça permet de contourner un bug, il n'y a pas de raison d'hésiter.

Phoenixian · Le 25/11/2009, à 18:03

merci a toi

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/07/2009, à 19:40

[RESOLU] Starting NFS common utilities: statd Failed après un reset

#2 Le 04/07/2009, à 19:56

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#3 Le 04/07/2009, à 20:20

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#4 Le 04/07/2009, à 20:35

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#5 Le 04/07/2009, à 20:43

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#6 Le 04/07/2009, à 20:56

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#7 Le 04/07/2009, à 21:07

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#8 Le 04/07/2009, à 22:03

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#9 Le 04/07/2009, à 22:36

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#10 Le 05/07/2009, à 13:59

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

#11 Le 25/11/2009, à 18:03

Re : [RESOLU] Starting NFS common utilities: statd Failed après un reset

Pied de page des forums