Re: Truc louche avec ssh
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. merci pour ta réponse. marc
Re: Problème impression HP Photosmart C4400 avec buster sur armel
Humh... finalement mon vieux PC est aussi en Buster (10.9) et a donc les mêmes versions des paquets concernant l'impression. Et quand c'est ce PC qui gère l'imprimante, ça fonctionne... Ce serait donc un souci d'architecture ? i686 vs armel ? En refaisant les tests proposés par la page CUPSDebugging, je constate que les PDF intermédiaires sont identiques et que ça se distingue dès la phase de rasterisation. Bref, je n'ai pas fini de creuser... Le dim. 18 avr. 2021 à 17:20, Guilhem Bonnefille a écrit : > > Bonjour, > > Voici quelques jours que je me bataille avec un soucis d'impression. > Ne trouvant pas la solution, je me résoud à demander votre aide. > > Depuis des années, j'ai une imprimante HP PhotoSmart C4400 connecté > sur un petit B3 (armel). Mais suite à une montée de version en Buster > (10.9) voilà que l'impression ne fonctionne plus. J'ai pu constater > deux soucis : > - lorsque je tente l'impression d'une page de test avec hp-setup, > j'obtient une page blanche (il charge une page et la recrache) > - lorsque je tente l'impression d'un doc, il imprime un immense triangle noir. > > J'ai pu vérifier que l'imprimante fonctionne toujours : > - la page de d'auto-test est nickel > - j'arrive à imprimer depuis un vieux PC sous jessie (il me semble) > > Suivant https://wiki.debian.org/CUPSDebugging j'ai tenté de comprendre > ce qui pouvait coincer. J'ai déposé tous les fichiers dans un dossier > partagé : > https://cloud.bonnefille.net/s/ZN5e3CP7pRFYNs4 > > La seule inquiétude en lisant le log tourne autour de message d'alerte > sur les profils de couleur. Mais je pense que c'est un faux problème > vu les autres tests. > J'ai donc décomposé avec cupsfilter. > 1. le fichier original (d1-001) est un PS > 2. en sortie de gstopdf, le PDF semble correct (hp.pdf) > 3. en sortie de pdftopdf, le PDF est altéré : la page est pivotée de > 270° (hp.cups-pdf) > 4. en sortie de gstoraster le document est blanc sur une page > 5. en sortie de hpcups le document est étrangement léger et semble > contenir deux pages > > Le PPD est généré par hp-setup. Son NickName : "HP Photosmart c4400 > Series, hpcups 3.16.11" > Il me semble ressembler beaucoup à celui qui fonctionnait. > > Bref, je ne sais pas trop dans quelle direction chercher. Si vous avez > une piste, je suis vivement intéressé. > > Merci par avance. > > -- > Guilhem BONNEFILLE > -=- mailto:guilhem.bonnefi...@gmail.com > -=- http://nathguil.free.fr/ -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/
Re: Truc louche avec ssh
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 a dit : 1. « Je peux laisser des terminaux ouverts, des éditeurs, le tout durant plusieurs jours et *sans aucune action de ma part*, la connexino ssh ne plante pas » 2. « dès que je fais dérouler un tail -F /var/log/apache2/access.log (par exemple), la connexion se coupe très rapidement » > je comprendrais pas pourquoi un vi resisterait mieux à un tail dans le > cas d'une perte de paquets. L'un ne résiste pas mieux que l'autre, c'est juste que tail sollicite bien plus fréquemment la connexion (en transmettant régulièrement des informations) que Vi. Avec Vi (ou tout autre éditeur en mode texte), si l'utilisateur n'effectue aucune saisie, seuls les pings applicatifs de SSH circulent sur le lien (et SSH résiste à des coupures ponctuelles). De son côté, tail affiche tout nouveau message de log et le serveur SSH va donc chercher à le transmettre au client, il sollicite la connexion. 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. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Truc louche avec ssh
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'à la connexion ssh liée au terminal > courant. Du coup tu peux te déconnecter, te reconnecter depuis une autre > machine, te connecter a plusieurs sur la même sessions ... > > ca te permet aussi d'ouvrir plusieurs fenetres ou de splitter les > fenetres existantes, de mutltiplexer la saisie sur plusieurs terminaux > (pour tapper la meme commande sur plusieurs serveurs ...) ... bref: en > plus de résoudre ton problème, ca t'ouvrirais pas mal de possibilités > comme fermer ta connexion ssh (et éteindre ta machine) sans perdre tes > terminaux. Pour cela, étant donné que je suis un vieux machin, j'utilise screen depuis des années. JB
Re: Truc louche avec ssh
> 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 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 je comprendrais pas pourquoi un vi resisterait mieux à un tail dans le cas d'une perte de paquets. a+ marc
Re: Truc louche avec ssh
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 peux te déconnecter, te reconnecter depuis une autre machine, te connecter a plusieurs sur la même sessions ... ca te permet aussi d'ouvrir plusieurs fenetres ou de splitter les fenetres existantes, de mutltiplexer la saisie sur plusieurs terminaux (pour tapper la meme commande sur plusieurs serveurs ...) ... bref: en plus de résoudre ton problème, ca t'ouvrirais pas mal de possibilités comme fermer ta connexion ssh (et éteindre ta machine) sans perdre tes terminaux. cordialement, marc
Re: Backuppc : can't write 4 bytes to socket
Hello, J'ai déjà eu ce type d'erreur mais pour des sauvegardes vers des hosts distants dont les backup rsync passaient par ssh. L'empreinte du host cible qui avait changé... backuppc m'affichait la même erreur que toi. Félix. Le 18/04/2021 à 15:03, Migrec a écrit : > Bonjour, > > Depuis quelques mois, j'ai un des clients sauvegardé par backuppc qui > ne veut plus rien savoir... > Voici la fin du log > michel/.mozilla/firefox/mns532kb.default/storage/default/moz-extension+++546c6e1d-ebfd-4ee5-9374-506b2a42fbc7^userContextId=4294967295/.metadata-v2 > got digests 381bbe9a2b00734669982984121eb0ea vs > 381bbe9a2b00734669982984121eb0ea > [ 3 lignes sautées ] > Read EOF: > Tried again: got 0 bytes > Can't write 4 bytes to socket > finish: removing in-process file > michel/.mozilla/firefox/mns532kb.default/storage/default/moz-extension+++546c6e1d-ebfd-4ee5-9374-506b2a42fbc7^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.files/20363 > Child is aborting > > J'ai tenté de rajouter -o ServerAliveInterval=1200 dans les options de > RsyncClientCmd mais sans succès. À noter que ce n'est pas toujours le > même fichier qui coince : ça arrive au bout de 10 à 15 minutes > environ. Le pc sauvegardé ne se met pas en veille. > Je ne sais plus trop quoi faire... > > Une idée ? > -- > Migrec -- Félix Defrance PGP: 0x46A603D10F04DC57 OpenPGP_signature Description: OpenPGP digital signature
Re: Truc louche avec ssh
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 et unstable de Debian : >> >> https://tracker.debian.org/pkg/mosh > > Je viens de l'installer, je vous tiens au courant. Ça a l'air de résoudre le problème. Merci, JKB
Re: Truc louche avec ssh
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ù une connexion entretenue par un simple « ping applicatif » ponctuel ne révèle rien du tout. Et c'est d'autant plus vrai avec SSH, qui est conçu pour supporter un certain nombre de requêtes restent sans réponse (cf. ServerAliveCountMax dans la page de manuel de ssh_config). Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Truc louche avec ssh
> 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 > révèle rapidement. 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? cordialement, marc
