RuTorrent crashe le serveur

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

RuTorrent crashe le serveur

DTH

Bonjour. Je loue actuellement une dedibox SC Large chez ONLINE.net et je fais ces derniers temps face à un problème assez étrange et gênant.
J'ai eu trois dedibox chez ONLINE. La première fonctionnait bien autant que je m'en souvienne. C'est à partir de la deuxième et ensuite sur la 3ème que le problème est survenu.
Il apparaît ainsi que je ne puisse pas me servir de ruTorrent de manière prolongée sans que le serveur ne crashe. En tentant d'enquêter sur le problème, j'ai constaté que les logs étaient vides.
Par "crash", j'entends une indisponibilité subite et totale du serveur, que je suis obligé de redémarrer, sans quoi de toute manière ONLINE le ferait automatiquement.

J'ai d'abord soupçonné VSFTPD, étant donné que j'avais l'impression que le problème survenait surtout dès lors que je commençai un transfert sur un fichier. Mais ne voyant rien dans les logs de VSFTPD et constatant que même avec le daemon non lancé le problème continuait, j'ai abandonné la piste.

Je me suis ensuite intéressé à rtorrent. Configuré pour produire des logs jusqu'aux niveaux "error" et "critical", il n'y figurait non plus rien. J'ai finalement lancé un strace complet dessus, seulement pour me rendre compte que lorsque le serveur "crashait", rtorrent était encore en pleine opération sans message indiquant une quelconque défaillance. Après de multiples downgrades jusqu'aux dernières versions stables, j'ai fini par conclure qu'il n'était pas responsable.

C'est alors que je finis par remarquer une chose. Chaque fois que le serveur crashait, une chose était sous mes yeux comme témoin de ce crash : la fenêtre ruTorrent du navigateur qui m'annonçait que la liaison avec rTorrent venait d'être interrompu. Pour la première fois, je soupçonnais que plus que simple témoin, ruTorrent jouait peut-être un rôle central dans cette affaire, et j'ai fini par confirmer cela. Lorsque je tente d'utiliser ruTorrent dans un navigateur, je crashe soit immédiatement, soit quelques instants plus tard. Mais lorsque ruTorrent n'est pas activé, le serveur reste online quoiqu'il arrive, quelque soit les téléchargements que je fais avec VSFTPD ou encore l'activité de rtorrent, que j'arrive à manipuler avec Transdroid au demeurant. Le fait que ce dernier puisse utiliser l'interface RPC2 gérée par Apache (qui ne pose aucun problème avec d'autres interfaces web telles que Aria2) pour interagir avec rutorrent me fait également penser que le problème vient bien de ruTorrent, même sur version stable.

J'ai jusqu'à présent consulté Kern.log, system, messages, dmesg, les logs apaches et vsftpd sans trouver le moindre début d'explication possible.
J'avais aussi évoqué la possibilité que ce ne soit pas le serveur qui crashe mais simplement une indisponibilité de sa connexion réseau. J'ai donc mis au point un script s'occupant exclusivement de vérifier le status de l'interface réseau et là aussi, je constatais simplement que le log du script s'arrêtait au moment où le serveur tombait, l'interface toujours UP à ce moment là.

Voilà, je vous remercie par avance de toute l'aide que vous pourriez m'apporter.

Magicalex

Tu as regardé le contenu de syslog après le crash?

cat /var/log/syslog | tail -200

DTH

Oui, j'ai essayé plusieurs fois de lancer cette commande : la ligne imklog est générée une seule fois au démarrage :
~> sudo cat /var/log/syslog | grep -B 20 imklog

Jan 22 21:23:58 sd-42806 kernel: [260526.240025] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2721167508:2721169292 (repaired)
Jan 22 21:23:59 sd-42806 kernel: [260526.784018] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2721167508:2721169292 (repaired)
Jan 22 21:24:25 sd-42806 kernel: [260553.040019] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2722167725:2722170645 (repaired)
Jan 22 21:24:26 sd-42806 kernel: [260553.592026] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2722167725:2722170645 (repaired)
Jan 22 21:24:29 sd-42806 kernel: [260556.624017] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2722348765:2722354605 (repaired)
Jan 22 21:24:35 sd-42806 kernel: [260562.944017] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2722643238:2722646158 (repaired)
Jan 22 21:24:36 sd-42806 kernel: [260563.488018] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2722643238:2722646158 (repaired)
Jan 22 21:27:54 sd-42806 kernel: [260762.248027] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2734120056:2734128354 (repaired)
Jan 22 21:27:55 sd-42806 kernel: [260762.792020] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2734120056:2734128354 (repaired)
Jan 22 21:27:59 sd-42806 kernel: [260766.464018] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2734413054:2734414514 (repaired)
Jan 22 21:36:04 sd-42806 kernel: [261251.596021] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2760436513:2760441222 (repaired)
Jan 22 21:36:04 sd-42806 kernel: [261252.140020] TCP: Peer 46.208.156.13:55115/45053 unexpectedly shrunk window 2760436513:2760441222 (repaired)
Jan 22 21:39:02 sd-42806 /USR/SBIN/CRON[11399]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jan 22 22:09:01 sd-42806 /USR/SBIN/CRON[11408]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jan 22 22:17:01 sd-42806 /USR/SBIN/CRON[11961]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 22 22:38:04 sd-42806 kernel: [264972.088579] sched: RT throttling activated
Jan 22 22:39:01 sd-42806 /USR/SBIN/CRON[13641]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jan 22 23:09:01 sd-42806 /USR/SBIN/CRON[13897]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Jan 22 23:17:01 sd-42806 /USR/SBIN/CRON[13969]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jan 22 23:39:01 sd-42806 /USR/SBIN/CRON[14156]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
////LE SERVEUR SE RELANCE APRES CRASH //// Jan 23 00:28:01 sd-42806 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Magicalex

Tu as utilisé un tuto en particulier pour installer ta seedbox?

Pourquoi tu fais un

grep -B 20 imklog

ça correspond à quoi imklog
Moi je voulais les dernières lignes avant le crash serveur

DTH

"imklog" est un string de la première ligne que le kernel émet au démarrage de la machine et elle n'est émise qu'à ce moment là. Donc, "grep -B 20 imklog" permet d'avoir les 20 dernières lignes AVANT le démarrage du kernel donc, savoir ce que le kernel faisait avant le de redémarrer, ce qui correspond à l'output que tu demandes.
Et en fait j'ai utilisé un ensemble de tutos. J'en avais surtout besoin pour Apache. Compiler, chercher des librairies, créer et démarrer des services, ça je sais faire.

Magicalex

ah d'accord peux tu me donner un peu plus de ligne parce que la je vois rien d’Intéressant dans les logs

DTH

http://paste.ubuntu.com/6810294/
Voilà.

Magicalex

bizarre tout ça, c'est quoi cette tache cron avec php?

En tout cas avant chaque reboot le kernel exécute une tâche cron bizarre qui supprime un ou plusieurs fichers. php tu l'as installé comment?

Donc ça peut venir de php (sans grande conviction)

Magicalex

Salut,

As tu résolu ton problème? Visiblement cette tâche cron supprime les session php (stocké sous forme de fichier texte) ce que tu peux faire c'est les désactiver dans un premier temps pour voir si ça vient de ça.

crontab -l -> pour lister les tâches cron
crontab -e -> pour les modifier

commente une ligne qui pourrai ressembler à ça :

[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)

DTH

J'avais déjà viré cette crontask mais ça n'y avait rien changé, le serveur tombait toujours inopinément.

Magicalex

Tu parles au passé, tu as résolu le problème?