Hello,
 
J'ai un serveur ldap (openldap 2.3 sur centos 5.3) sur lequel, sans raison apparente, rpc.statd s'est soudain mis à utiliser le port 636 pour écouter en ipv4, ce qui est assez gênant vu que le serveur ldap est maître et que tous les réplicas l'intérrogent en ldaps. Du coup, la réplication se passe nettement moins bien...
Si je fais un kill du processus rpc.statd et un restart d'openldap c'est bon, ldap écoute à nouveau sur le 636. Le problème c'est qu'au reboot suivant rpc.statd reprend le port 636 pour son compte    
Je ne trouve rien dans la conf de la machine qui explique pourquoi celle-là a ce problème. Aucun autre de mes serveurs ldap n'a ce problème. Je sais que je peux éditer /etc/sysconfig/nfs pour forcer rpc.statd à prendre un autre port que le 636 mais j'aimerais ne pas avoir à modifier la conf d'un service dont je ne me sers pas. Je n'ai pas eu à modifier la conf de nfs de mes autres serveurs et si je peux rester cohérent et homogène ce serait mieux    Je précise que la machine n'a pas de partages nfs.
Une idée?
 
a+

Y a peut-être quelque part un cache ou il stocke le dernier port utilisé ?
 
Regarde si tu n'as pas un fichier /var/run/portmap.state qui traine par hasard (sachant que c'est portmap à priori qui attribue le port).
 
Dans tous les cas, si tu n'utilises pas ce service, tu ne devrais même pas le lancer.

J'ai cherché un éventuel cache du port utilisé mais j'ai rien trouvé...
 
Je n'ai pas configuré de partage nfs mais les machines ont un partage sunrpc automatique :

Je n'ai aucune idée si il est indispensable pour le bon fonctionnement de la machine, ça peut peut-être se désactiver. Faudrait que je teste sur une machine qui n'est pas en prod...