Posté(e) le 3 septembre 201212 a Auteur Hello all ! Pour ma part, combo de MàJ pour le Qnap et OSX (Mountain Lion oblige)... Donc bon, c'est pas en ce moment que je vais faire tomber les high-score En attendant, bonne rentrée et bon à tous !
Posté(e) le 7 septembre 201212 a Kill, si t'as un peu de place pour les logs, tu peux faire tourner le démon avec l'option -xtradaemondebug :)
Posté(e) le 10 septembre 201212 a Passage de mes serveurs à Wheezy, pas mal de redémarrages ce week-end dernier. Normalement, ce soir, tout rentre dans l'ordre.
Posté(e) le 11 septembre 201212 a Auteur Kill, si t'as un peu de place pour les logs, tu peux faire tourner le démon avec l'option -xtradaemondebug :) J'ai de la place, mais ça m'apporte quoi ? A moins que ce soit pour te depanner, dans ce cas, pas de soucis.
Posté(e) le 19 septembre 201212 a je pense qu'il me parlait plutot, non ? j'ai tenté la commande mais elle marche pas. Donc j'ai mis le "--debug" rien de plus dans la log a part des "(monitor) Using replay because of socket down" de temps en temps le process est tombé le 15 sept entre 2H et 3H du mat
Posté(e) le 19 septembre 201212 a Salut Ken, Bon si tu as bien la release Harlock du TUPm (et je viens de le vérifier, tu l'as bien ) , et si tu lances ton client en mode démon, tu devrais être en mode debug avec ca : ./TUPm --xtradaemondebug Si tu n'as pas fixer l'option " -l " pour donner le chemin vers un répertoire de log, ca crache dans le répertoire ./logs/ dans un fichier qui doit s'appeller debug.log me semble Par contre ce qui est intéressant, c'est la fonction replay qui s'active . Je pense que tu perds la connexion avec le serveur, même si le serveur est toujours up . Tu n'aurais pas des problèmes de stabilité de ligne chez toi par hasard ? Bon par contre, on est d'accord, ca devrait pas faire planter le client. Il faut que je trouve le temps de faire le test en lui coupant l'herbe sous le pied pendant quelques connexions voir comment les socks tcp se comportent. C'est vrai que j'ai eu la faiblesse, par souci ergonomique, de demander à l'établissement de la connexion TCP que le timeout soit inférieur à une dizaine de secondes, peut être que c'est un effet de bord. Merci pour les tests
Posté(e) le 19 septembre 201212 a ok c'est activé stabilité de la ligne. non je pense pas, sauf quand la box deco/reco et change d'ip je pense pas avoir un soucis sur mon reseau cablé non plus, vu que j'utilise tous les jours le serveur on va laisser tourner le truc
Posté(e) le 27 septembre 201212 a Salut les jeunes . Pour ken et les autres , version 2.4 du client TUPm qui corrige des soucis sous Kernel 3.x :) Sinon ca gaze ?
Posté(e) le 29 septembre 201212 a Auteur Slt Tugs, Ca gaz ! Bcp de mouvement coté pomme croquée donc uptime en berne mais sinon ça va ! Je vais faire une passe sur mon serveur pour remettre le client à jour... Ca doit faire des années que j'y ai pas touché
Posté(e) le 1 octobre 201212 a tugs : mp je vais tester ton dernier client edit : bizarre, impossible de le compiler, j'avais ni gcc ni make sur la becane.... j'avais du le compiler sur ma becane de test
Posté(e) le 1 octobre 201212 a Intéressant comme info. ca voudrait dire que tu as utilisé le binaire sur une machine qui n'avait pas forcément la même version de lib (glibc , libstd++ et version kernel) Est ce que tu aurais compilé sur du 2.6 et exécuté sur du 3.2 ?
Posté(e) le 1 octobre 201212 a Bonne question... Je pense pas car l'autre version que j'utilise est une vieille version sur mon server en 2.6 elle ne fonctionnait pas sur mon nouveau server, donc j'avais down la derniere version. Par contre, oui, j'ai du le compiler sur la becane qu'est dans ma chambre, meme proc, meme ram, meme cm, meme os
Posté(e) le 8 octobre 201212 a pas mieux derniere log [Oct 05, 2012; 12:24:50] - (tupmdebug) Main under execute - il a tenu... 4 jours
Posté(e) le 10 octobre 201212 a Faudrait voir à ce qu'un mécanisme quelconque mette pas fin au process parce que le problème n'apparait pas chez les autres (les miens, sur 4 bécanes tournent sans interruption . Genre sur mon proxy bsd, le process est up depuis le 1er septembre 2012 .
Posté(e) le 10 octobre 201212 a ben je vais le mettre dans la crontab, ca sera plus simple le serveur en lui meme est up depuis juin sans pb
Posté(e) le 1 janvier 201312 a raaaaaaaaaaaa j'ai reussi a bloquer un process modprobe en jouant avec ma nouvelle clé usb wifi .... qui n'a pas de driver sur noyau 2.6 ..... puttaaaaaaiiiinnnnnnnnnn obligé de reboot..... mon uptime !!! 184j .... :'( bon le NAS est encore vivant, avec 188j
Posté(e) le 1 janvier 201312 a atta, faut que je la mette sur le NAS maintenant, bien capable de le faire freezer aussi de toute facon, je vais bientot changer de processeur, donc il faudra que je le redemarre passage du pentium E6300 au quad core Q9550 il va depoter un peu plus, trop charette avec toutes mes VM ^^
Posté(e) le 16 janvier 201312 a ouinnnnnnnnnnnnnnnnnnnnn mon onduleur a laché ce matin et couic les deux serveurs ...
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.