proftp inaccessible au bout d'à peu près 48h!

Edmund · Le 15/02/2015, à 13:22

Bonjour à tous,
régulièrement, le serveur ftp devient inaccessible. Pour qu'il soit à nouveau disponible, je dois alors me reconnecter en ssh, et entrer la commande /etc/init.d/proftpd restart
et tout repart pour encore 48h.

Il doit y avoir un réglage tout bête, mais qui m'échappe!!!!!!

tiramiseb · Le 15/02/2015, à 15:40

Salut,

Que veut dire "inaccessible" : que se passe-t-il ?
Qu'y a-t-il dans les logs de ProFTPd ?

pierrede · Le 15/02/2015, à 16:05

et ce que par hasard ton serveur ne s'arrêterait pas lorsque ta connexion ssh qui l'a lancé s'interrompt.
Je m'explique avec un p'tit exemple vécu.
j'ai un fixe, un portable et une sheevaplug (sorte de mini ordi)
je tente de me connecter à ma sheeva en ssh depuis mon fixe, sans résultat.
Je branche mon portable sur la sheeva (communication directe par port série) et lance un "/etc/init.d/ssh restart"
Je retente un connexion depuis mon fixe, ca marche je ferme la session et j'éteins mon portable. Puis, je réessaye une connexion ssh de mon fixe vers ma sheeva mais plus rien.
Pourquoi ? parce que le "/etc/init.d/ssh restart" était lié à la session initiée par le portable (via le port série), en le déconnectant j'ai tué le processus.

Une solution simple depuis je rajoute un "&" à la fin de la commande pour détacher le process de ma session et ça marche nikel.
donc "/etc/init.d/ssh restart&" et plus de souci
Donc je me demande si tu n'execute pas ton "/etc/init.d/proftpd restart" depuis une session ssh que tu laisse ouverte (et qui s'interrompt au bout de 48h car j'imagine que le keep alive n'est pas eternel...)
Si c'est le cas alors rajoute juste un "&" à la fin de ta commande : "/etc/init.d/proftpd restart&"

Sinon en attendant de trouver l'origine du problème tu peux toujours faire du bricolage (un ptit script qui test si le demon ftp est lancé et le relance le cas échéant, placé dans un crontab), mais n'oublie pas que c'est moche comme solution et donc provisoire

Dernière modification par pierrede (Le 15/02/2015, à 16:06)

tiramiseb · Le 15/02/2015, à 16:12

pierrede:
Normalement un script de démarrage ne souffre pas de ce problème de "lien" avec la session...

pierrede · Le 15/02/2015, à 16:32

---- Post hors sujet : réponse à tiramiseb
ben je suis d'accord avec ton "normalement" mais sur ma sheeva (pour la commande /etc/init.d/ssh restart (ou start d'ailleurs)) exécutée par le port série, je constate cette paternité (debian wheezy); j'avoue que ça me perturbe aussi mais j'ai renouvelé l’expérience suffisamment de fois pour savoir que ma sheeva réagit SYSTEMATIQUEMENT comme ça..
Je précise que je ne parle que de service ssh initié par le port série (via /etc/init.d/ssh (re)start ), aussi j'ai cette sheeva depuis des années et j'ai custom le système dans tous les sens, j'ai récemment été surpris que le serveur web installé dessus m'envoi un "bad request" quand je l'attaque via l'ip locale alors qu'il répond sans problème via ip public, tout ca pour dire que je ne me souviens pas des mesures de sécu que j'avais mise en place à l'époque et qu'il se pourrait même que cette filiation bizarre du ssh pour la session l'ayant initiée puisse être un effet de bord d'une des mesures prises à l'époque (je dis effet de bord parce que je ne vois pas vraiment pourquoi j'aurai fait une telle modif, autant je peux concevoir ma décision de demander à apache de réagir différemment suivant qu'on l'interroge avec une dns ou ip public ou privée ; autant je ne m'imagine pas implémentant une sécu qui modifie les règles d'héritage de processus

Dernière modification par pierrede (Le 15/02/2015, à 16:50)

tiramiseb · Le 15/02/2015, à 16:33

Peut-être un problème dans le script en question sur ce système-là. Cela dit, là on ne parle pas de sheeva...
Je doute fort que le problème soit celui-là.

pierrede · Le 15/02/2015, à 16:49

T'as sûrement raison ça semble des plus improbables.

Pour solutionner ton probleme active tes logs dans la conf de proftp au niveau le plus sensible surement warn ou warning (check la doc officielle pour savoir la valeur exacte).
puis vois si les logs parlent.
Aussi tu pourrais lancer proftp en mode debug, le tracer..

Favorise "service X restart" à "/etc/init.d/X restart" Tu bénéficiera d'un evironnement contrôlé pour ton process
Ca pourrait même solutionner ton problème (ultra improbable mais sait on jamais (si proftp à un autoshutdown qui se réfère à une variable globale et que celle ci est modifiée par un script executé au démarrage mais après proftpd... ouais ultra-ultra-improbable je sais XD)). dans tout les cas ça reste une meilleure pratique de manière générale.
En effet, de ce que j'ai compris (de la 1ère réponse ici http://stackoverflow.com/questions/2250 … ice-start) si j'ai 2 script au démarrage (executé dans l'ordre) A.sh et B.sh (j'ai pas testé hein c'est théorique)
A.sh :
echo $OSTYPE
B.sh:
export OSTYPE=oops

au démarrage le script A.sh écrit "linux-gnu" (si vs êtes sous linux-gnu !)
MAIS un "/etc/init.d/A.sh restart" devrait écrire "oops" (puisque B.sh à depuis modifié OSTYPE) TANDIS QU'un "service A.sh restart" produirait un "linux-gnu" (puisqu'executé dans des conditions similaire à celle du démarrage)

Dernière modification par pierrede (Le 15/02/2015, à 17:11)

Edmund · Le 15/02/2015, à 17:41

Merci pour vos réponses!! Je donne les informations manquantes:

tiramiseb a écrit :

Salut,
Que veut dire "inaccessible" : que se passe-t-il ?
Qu'y a-t-il dans les logs de ProFTPd ?

Impossible de se connecter en ftp. Filezilla indique "impossible de se connecter". Mais après la commande indiquée dans mon premier post, la connexion se fait sans problème.

Edmund · Le 15/02/2015, à 17:41

pierrede a écrit :

et ce que par hasard ton serveur ne s'arrêterait pas lorsque ta connexion ssh qui l'a lancé s'interrompt.

Non, je ne crois pas. je termine ma connexion ssh par exit, le terminal disparait.

Edmund · Le 15/02/2015, à 17:44

pierrede a écrit :

T'as sûrement raison ça semble des plus improbables.
Pour solutionner ton probleme active tes logs dans la conf de proftp au niveau le plus sensible surement warn ou warning (check la doc officielle pour savoir la valeur exacte).
puis vois si les logs parlent.
Aussi tu pourrais lancer proftp en mode debug, le tracer..

Merci beaucoup pour ces infos. Là, il faut que je me documente, car je ne connais rien de ce dont tu parles, mais ça me semble le moment de m'y mettre!

tiramiseb · Le 15/02/2015, à 17:45

Il faut regarder les logs.

Et s'il n'y a rien dans les logs, augmenter leur niveau comme le suggère pierrede.

(autant commencer par les choses simples avant de chercher quelque chose de complexe)

tiramiseb · Le 15/02/2015, à 17:46

Tu trouveras les logs dans /var/log/....... je ne sais pas où se placent les logs de ProFTPd.

De manière générale, avec un logiciel serveur, la première chose à regarder c'est toujours les logs.

Edmund · Le 15/02/2015, à 21:29

Merci, j'y jette tout de suite un coup d'oeil!

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/02/2015, à 13:22

proftp inaccessible au bout d'à peu près 48h!

#2 Le 15/02/2015, à 15:40

Re : proftp inaccessible au bout d'à peu près 48h!

#3 Le 15/02/2015, à 16:05

Re : proftp inaccessible au bout d'à peu près 48h!

#4 Le 15/02/2015, à 16:12

Re : proftp inaccessible au bout d'à peu près 48h!

#5 Le 15/02/2015, à 16:32

Re : proftp inaccessible au bout d'à peu près 48h!

#6 Le 15/02/2015, à 16:33

Re : proftp inaccessible au bout d'à peu près 48h!

#7 Le 15/02/2015, à 16:49

Re : proftp inaccessible au bout d'à peu près 48h!

#8 Le 15/02/2015, à 17:41

Re : proftp inaccessible au bout d'à peu près 48h!

#9 Le 15/02/2015, à 17:41

Re : proftp inaccessible au bout d'à peu près 48h!

#10 Le 15/02/2015, à 17:44

Re : proftp inaccessible au bout d'à peu près 48h!

#11 Le 15/02/2015, à 17:45

Re : proftp inaccessible au bout d'à peu près 48h!

#12 Le 15/02/2015, à 17:46

Re : proftp inaccessible au bout d'à peu près 48h!

#13 Le 15/02/2015, à 21:29

Re : proftp inaccessible au bout d'à peu près 48h!

Pied de page des forums