G2PC a écrit :
> A tout hasard, tu as assez de ram ?
> Si le fichier est trop lourd, ça peut jouer ?
> Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
> n'avoir que 1 ou 5Mo max par fichier ?
> Le tail pourrait alors peut être ne plus tuer la connexion ?
Je pense que
A tout hasard, tu as assez de ram ?
Si le fichier est trop lourd, ça peut jouer ?
Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
n'avoir que 1 ou 5Mo max par fichier ?
Le tail pourrait alors peut être ne plus tuer la connexion ?
marc
> Non, non, ce n'est pas ça. Ce problème peut survenir mais pas dans mon
> cas où il est exclu par construction. Les paquets passent quels que
> soient leur taille.
y'a des dispositifs filtrant entre toi et le serveur? le problème n'est
pas dans les bouts?
marc
Charles Plessy a écrit :
> Bonsoir à tous,
>
> je me souviens d'avoir eu exactement le même problème.
>
> J'ai même peut-être eu la solution sur cette liste (ou le LUG de
> Strasbourg ?), mais je n'arrive pas à la retrouver.
>
> Je vais peut-être me tromper, mais il me semble que le problème
Bonsoir à tous,
je me souviens d'avoir eu exactement le même problème.
J'ai même peut-être eu la solution sur cette liste (ou le LUG de
Strasbourg ?), mais je n'arrive pas à la retrouver.
Je vais peut-être me tromper, mais il me semble que le problème était
lié à la MTU ou un système similaire:
Bonjour Sébastien,
> Quoi qu'il en soit, cette hypothèse me semble très probable, c'est pour
> cela que j'en ai fait part, mais ce n'est qu'une hypothèse.
c'est bien pour ca que ca m'intéresse: si tmux,screen ou mosh
contournent le problème, ca ne le corrige ni ne l'explique et j'étais
curieux.
Marc Chantreux a écrit :
> Oui mais du coup ca n'explique pas le comportement curieux que décrit
> Bertrand. je crois comprendre que dans les 2 cas:
>
> * on a une session interactive ouverte sur la machine distante
> * un processus qui ne fait rien qui est attaché à la tty
Ce n'est pas ce qu'il
Marc Chantreux a écrit :
> salut Joel,
Bonsoir,
>> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
>> plusieurs jours et sans aucune action de ma part
>
> tmux est parfait pour ce genre d'usages: il te permet de lier tes applis
> à un serveur de sessions plutôt qu'à
> Cela ne stabilise rien du tout, bien au contraire, un trafic incessant
> révèle l'instabilité de la connexion, là où une connexion entretenue par
> un simple « ping applicatif » ponctuel ne révèle rien du tout.
Oui mais du coup ca n'explique pas le comportement curieux que décrit
Bertrand. je
salut Joel,
> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
> plusieurs jours et sans aucune action de ma part
tmux est parfait pour ce genre d'usages: il te permet de lier tes applis
à un serveur de sessions plutôt qu'à la connexion ssh liée au terminal
courant. Du coup tu
BERTRAND Joël a écrit :
> Sébastien Dinot a écrit :
>> Basile Starynkevitch a écrit :
>>> je crois qu'il faut le compiler depuis son code source
>>
>> Inutile, l'outil est disponible en version 1.3.2 (dernière version
>> publiée par le projet, en juillet 2017) dans les versions stable,
>> testing
Marc Chantreux a écrit :
> Je pige pas par quel mécanisme et à quel niveau le fait qu'il y est un
> traffic dans les deux sens stabilise quoi que ce soit. tu pourrais
> expliquer?
Cela ne stabilise rien du tout, bien au contraire, un trafic incessant
révèle l'instabilité de la connexion, là où
> Ne serait-ce tout simplement pas révélateur d'une connexion instable,
> intermittente? Tu ne t'en rends pas compte dans le terminal inactif,
> car la coupure passe justement inaperçue (les sockets restent valides).
> Mais lorsque le flux est continu, là, l'intermittence de la connexion se
>
Sébastien Dinot a écrit :
> Basile Starynkevitch a écrit :
>> je crois qu'il faut le compiler depuis son code source
>
> Inutile, l'outil est disponible en version 1.3.2 (dernière version
> publiée par le projet, en juillet 2017) dans les versions stable,
> testing et unstable de Debian :
>
>
Basile Starynkevitch a écrit :
> je crois qu'il faut le compiler depuis son code source
Inutile, l'outil est disponible en version 1.3.2 (dernière version
publiée par le projet, en juillet 2017) dans les versions stable,
testing et unstable de Debian :
https://tracker.debian.org/pkg/mosh
Basile Starynkevitch a écrit :
>
> On 4/16/21 10:01 PM, Sébastien Dinot wrote:
>> BERTRAND Joël a écrit :
>>> Rien à signaler dans tcpdump. C'est la première chose que j'ai
>>> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
>>> un routeur quelque part qui coupe, mais je ne
On 4/16/21 10:01 PM, Sébastien Dinot wrote:
BERTRAND Joël a écrit :
Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe, mais je ne vois pas comment il
ferait la différence
BERTRAND Joël a écrit :
> Rien à signaler dans tcpdump. C'est la première chose que j'ai
> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
> un routeur quelque part qui coupe, mais je ne vois pas comment il
> ferait la différence entre un terminal inactif et un tail -F.
Ne
Thomas Trupel a écrit :
> Bonjour,
>
> Un tcpdump permettrait de savoir qui met fin à la session tcp.
Bonsoir,
Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe,
Bonjour,
Un tcpdump permettrait de savoir qui met fin à la session tcp.
Cordialement,
Thomas
16 avr. 2021 18:33:40 BERTRAND Joël :
> Bonjour à tous,
>
> Chose louche que je ne m'explique pas. J'ai un serveur distant en
> centre d'hébergement. J'ai accès à la console (au travers d'un genre
Bonjour à tous,
Chose louche que je ne m'explique pas. J'ai un serveur distant en
centre d'hébergement. J'ai accès à la console (au travers d'un genre de
kvm IP) et j'y accède en ssh. Ce n'est pas exactement une Debian mais
une Devuan. Côté client, on est en devian, l'honneur est
21 matches
Mail list logo
