Re: Mon svnserve ne marche plus

Top Page

Reply to this message
Author: Marc TERRIER
Date:  
To: Yves Martin, Olivier Allard-Jacquin
CC: Guilde
Subject: Re: Mon svnserve ne marche plus
Yves Martin a écrit :
> On Sun, 2011-09-18 at 16:55 +0200, marc.terrier@??? wrote:
>
>> Auriez-vous une piste à me suggérer, SVP ?
>
> Voici quelques contrôles à effectuer:
>
> - Est-ce que le service "xinetd" est bien démarré ? ps
> ou /etc/init.d/xinetd status
>
> - Est-ce que le port 3690 est ouvert ? netstat -anp | grep LISTEN
>
> - Est-ce qu'il y aurait une configuration de firewall chargée ?
> iptables -L
>
> - Que donne "telnet nom-du-serveur 3690" en local et depuis une machine
> du réseau ?
>
> A+


Merci de vos réponses à tous les trois. Entretemps, mon svnserve s'est
décidé à retomber en marche, sans que je ne sache vraiment pourquoi. Je
vais donc suivre point par point à vos différentes pistes, des fois que
ça me permettrait d'en savoir un peu plus :

Suggestions de Yves :

1) Est-ce que le service "xinetd" est bien démarré ? ps
ou /etc/init.d/xinetd status

==> Cette version d'xinetd ne reconnaît pas la commande 'status', mais
ps me montre qu'xinetd est bien lancé :

ps -ef | grep xinetd
root      2819     1  0 21:47 ?        00:00:00 /usr/sbin/xinetd
  -pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root      2976  2945  0 22:55 pts/0    00:00:00 grep xinetd


2) Est-ce que le port 3690 est ouvert ? netstat -anp | grep LISTEN

==> oui :

[...]
tcp   0   0   0.0.0.0:3690   0.0.0.0:*    LISTEN    2819/xinetd
[...]



3) Est-ce qu'il y aurait une configuration de firewall chargée ?

==> Non, c'est une machine à usage interne exclusivement :

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination


Chain FORWARD (policy ACCEPT)
target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


4) telnet nom-du-serveur 3690 est OK, aussi bien depuis le prompt de la
machine elle-même que depuis une autre machine.

Suggestions d'Olivier :

1) Sur une Debian, les logs de xinetd se retrouverons sur
/var/log/daemon.log : c'est bon à savoir, mais dans mon cas, je n'y
trouve aucune différence entre les fois où tout allait bien, la (courte)
période pendant laquelle svnserve et/ou xinetd se sont mis en grève, et
maintenant, où ça refonctionne.

2) Si le problème se situe au niveau de l'authentification de svnserve,
tu peux retrouver des logs dans /var/log/auth.log : non, ce n'était pas
un problème d'authentification, mais un problème de time-out. Le serveur
svnserve ne répondait pas dans un temps imparti, et le client finissait
par s'impatienter.

3) Après le redémarrage de xinetd, vérifie que le port 3690 est bien
ouvert: netstat -taupn|grep 3690.
==> cf. ci-dessus, réponse à Yves. Bizarrement, le redémarrage
d'xinetd n'avait pas suffi à corriger le pb, pas plus que le redémarrage
de la machine (que j'aurai aimé éviter, par principe). En revanche, bien
après le redémarrage, à un moment, j'ai refait un essai depuis le
client, et ô surprise, c'était retombé en marche... :-/

"En lançant la commande en temps que root, le paramètre "n" indique quel
est le nom du process qui écoute sur le port. Dans ton cas, cela doit
être xinetd."

==> oui, tout à fait :

netstat -taupn|grep 3690
tcp        0      0 0.0.0.0:3690            0.0.0.0:* 
LISTEN      2819/xinetd


4) "strace" peut aider à trouver des intormations. Pour cela, tu peux
utiliser: strace -t -f -o /tmp/xinetd.log /etc/init.d/xinetd restart
ou moins verbeux : strace -t -f -o /tmp/xinetd.log -e open
/etc/init.d/xinetd restart

Tu fais alors un un "tail -f /tmp/xinetd.log"
et tu lances une connexion sur ton "svnserve"

==> Je l'ai fait, mais (honte sur moi), je n'ai rien compris (ou pas
grand chose) au résultat.

5) Dans mon cas, rien de tel, puisque c'est retombé en marche sans
action particulière de ma part...

6) Je ne pense que ce soit lié, mais je remarque ça :

root@debibox:~$ su svn

root@debibox:~$ echo $?
1

root@debibox:~$ id
uid=0(root) gid=0(root) groupes=0(root)

Donc je ne peux pas me connecter de façon interactive en tant que 'svn',
même en étant 'root', ce qui n'est pas étonnant, puisque :

grep svn /etc/passwd
svn:x:65533:65533::/nonexistent:/bin/false

Mais je n'ai rien modifié récemment de ce côté, et ça marchait jusqu'ici.

7) root@debibox:~$ netstat -taupn|grep 3690
tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 3130/xinetd

root@debibox:~$ /etc/init.d/xinetd stop
Stopping internet superserver: xinetd.

root@debibox:~$ netstat -taupn|grep 3690    ==> rien


root@debibox:~$ su -c "/usr/bin/svnserve -i -r /srv/svn" svn

root@debibox:~$ netstat -taupn|grep 3690    ==> rien


Et après avoir lancé svnserve de la façon indiquée ci-dessus, le client
SVN échoue, avec un message différent : "Can't connect to host
'debibox': Aucune connexion n'a pu être établie car l'ordinateur cible
l'a expressément refusée." Comment se fait l'association entre
/usr/bin/svnserve et le port 3690 quand svnserve est lancé à la main,
hors xinetd ? Je ne connais rien d'autre, pour cela, que /etc/services,
qui contient bien les deux lignes suivantes :

svn             3690/tcp        subversion      # Subversion protocol
svn             3690/udp        subversion


Mais alors, comment expliquer que je ne vois rien dans netstat -taupn,
ni dans ps -ef ?

ps -ef | grep -i svnserve
root      3186  2945  0 00:03 pts/0    00:00:00 grep -i svnserve


En revanche, si je relance xinetd, tout refonctionne : pas de message
d'erreur, et client SVN content ( donc moi aussi ).

Le mystère n'est donc pas élucidé, mais le problème est résolu, et j'ai
appris quelques trucs au passage. Merci à tous...

--
Marc