rsync: erreur 255 bizarre Le sujet est résolu

[tony]

salut,
je pensais que mon script, qui a marché environ 2 ans (au moins) sans problème et qui avait dernièrement des ratés s''était soigné tout seul.Erreur, voilà qu'il s'arrête de nouveau à certaines lignes. J'ai donc exécuté une de ces lignes seule, en générant un log. Voici la commande + 2 dernières lignes du log qui montrent, ama, que la ligne choisie est exécutée sans erreur, mais qu'il y a un blocage à la fin. J'ai d'ailleurs inclus des modifications dans le profil contenu dans le répertoire transféré, .mozilla, elles sont bien apparues dans le profil cible.

Code : Tout sélectionner

~$ rsync -a .mozilla/  mm@192.168.1.19:.mozilla --delete-after --log-file=rsynclog.log
Debian GNU/Linux 11
^Crsync error: unexplained error (code 255) at rsync.c(716) [sender=3.2.7]

less rsynclog.log
.............
2025/04/20 16:38:42 [91535] sent 22832084 bytes  received 38159 bytes  total size 647681295
2025/04/20 16:38:42 [91535] rsync error: unexplained error (code 255) at rsync.c(716) [sender=3.2.7]

D'après ce que j'ai lu, le plus souvent ce code serait en fait celui d'une erreur due à ssh et indiquerait un problème de délai lorsque de très gros fichiers sont transférés, ce qui n'est pas le cas ici. De plus j'utilise ssh pour me connecter à mon ancien portable et le mettre à jour sans aucun problème.

Je viens de tester le même script avec trixie: même problème. Je suppose donc que qq chose cloche dans la connexion ssh avec mon ancien portable, mais uniquement pour ce script. Alors, connexion ssh fautive ou script? Ou autre chose? J'avoue que je ne sais pas quel chemin prendre.

PS: une chose que je ne comprends pas: sent 22832084 bytes received 38159 bytes. Certains se perdent en route?

Code : Tout sélectionner

Total bytes sent: 4,741,953,365
Total bytes received: 202,888

ça n'a pas l'air anormal

[tony]

j'ai avancé car en utilisant la commande rsync -a -v ... et en attendant suffisamment longtemps, je me suis aperçu que en fait le script s'exécutait bien, mais il est extrêmement long, d'où peut-être ce 255. Il me faut donc trouver pourquoi ce transfert entre mon portable et l'ancien portable est si lent.

Pourtant lorsque je me connecte, avec ssh, la connexion est rapide, les commandes exécutées dans le terminal connecté sont assez rapides, seul le transfert de données, rapide au début, devient très très lent tout d'un coup.

[piratebab]

Est ce que tu n'aurais pas une partition bientot pleine ?
Que donne le taux CPU pendant le transfert ?
Ca te fait un debit moyen de combien ?

[tony]

Est ce que tu n'aurais pas une partition bientot pleine ?
Que donne le taux CPU pendant le transfert ?
Ca te fait un debit moyen de combien ?

la commande "df" indique que je suis très loin de la saturation. Pour le reste CPU et débit il faut que je regarde comment on obtient ces renseignements.

mais j'ai trouvé le fautif: le répertoire source .mozilla. Par contre je ne comprends toujours pas le pourquoi.

Par prudence je me suis assuré que les droits de ses éléments étaient corrects avec la commande

Code : Tout sélectionner

chmod -R 755 .mozilla

mais la transmission de ce répertoire bloque toujours au niveau des fichiers qui se trouvent dans le profil: seule une partie est transmise.

Par contre ce même répertoire ne pose pas de problème si j'utilise rsync avec comme destination une clef usb. On dirait bien que la connexion ssh a qq chose à voir là dedans, mais uniquement pour ce répertoire!! En effet, si je commente les commandes où .mozilla intervient comme source dans mon script celui-ci s'exécute normalement. Vraiment très bizarre ce truc.

Je dois répéter une même erreur encore et encore à l'insu de mon plein gré.

PS:

Code : Tout sélectionner

~$ rsync -a -vv .mozilla/  mm@192.168.1.19:.mozilla
opening connection using: ssh -l mm 192.168.1.19 rsync --server -vvlogDtpre.iLsfxCIvu . .mozilla  (9 args)
Debian GNU/Linux 11
sending incremental file list
............
firefox/<profil>/permissions.sqlite
firefox/<profil>/pkcs11.txt
firefox/<profil>/places.sqlite   ----------> [incorrect]pause très longue dans la transmission.... puis reprise... puis arrêt...etc[/incorrect] tcpdump montre un flux de données permanent

[tony]

commande top pendant un arrêt anormal de la transmission

Code : Tout sélectionner

~$ top -d 5

Tâches: 255 total,   1 en cours, 253 en veille,   0 arrêté,   1 zombie
%Cpu(s):  4,8 ut,  1,2 sy,  0,0 ni, 94,1 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st 
MiB Mem :  15618,3 total,   9892,7 libr,   3090,6 util,   3534,2 tamp/cache     
MiB Éch :    977,0 total,    977,0 libr,      0,0 util.  12527,6 dispo Mem 

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.          
  10134 mmas      20   0   11,5g 599280 208272 S  32,9   3,7  27:34.55 firefox-esr   
  10522 mmas      20   0 2561920 168956 103524 S  21,3   1,1  12:43.50 Isolated Web+ 
   1195 mmas       9 -11 1525024  40588  25900 S   6,2   0,3  16:11.56 pulseaudio    
   5167 mmas      20   0 1652452 147132  81564 S   3,6   0,9   9:39.50 rhythmbox     
   5144 mmas      20   0  749300  63204  44832 S   1,8   0,4   4:42.22 pavucontrol   
   1013 root      20   0 2130996 135244  80596 S   1,4   0,8  11:44.93 Xorg          
   5225 mmas      20   0  914172  76748  43460 S   0,8   0,5   1:31.61 blueman-mana+ 
    872 root       0 -20       0      0      0 I   0,4   0,0   0:46.32 kworker/u25:+ 
  12934 mmas      20   0   11820   5608   3448 R   0,4   0,0   0:00.04 top           
   1384 mmas      20   0  611220  35024  26612 S   0,2   0,2   0:29.79 panel-8-puls+ 
   1549 mmas      20   0  281752  37692  23528 S   0,2   0,2   0:23.96 blueman-tray  
   4785 root       0 -20       0      0      0 I   0,2   0,0   0:39.65 kworker/u25:+ 
  11901 mmas      20   0 2699844 198232 100200 S   0,2   1,2   0:40.62 Isolated Web+

[piratebab]

Tu essaie de copier un fichier mozilla alors que firefox est actif. Il a peut étre verrouillé le fichier.

[tony]

Tu essaie de copier un fichier mozilla alors que firefox est actif. Il a peut étre verrouillé le fichier.

j'y ai bien pensé et j'ai essayé en fermant FF, le résultat est le même.

Je sais bien qu'il faut modifier/copier un profil une fois fermé pour des questions d'enregistrements qui se font au moment de cette fermeture, aussi de temps à autre j'utilisais ce script en fermant Firefox. En l'espèce l'erreur est toujours là FF en cours ou fermé.

Dans le résultat de la commande top (ci-dessus) je ne vois rien qui implique le processus lié à "ssh".

PS: il me semble, pas très sûr quand même, qu'il y a eu des modifications assez récentes apportées aux fichiers de configuration de ssh/sshd, pourrait-il y avoir un lien?

[tony]

en attendant suffisamment longtemps le transfert s'est terminé correctement. Voici les dernières lignes au cas où elles contiennent qq chose d'utile:

Code : Tout sélectionner

rsync -a -vvvv .mozilla/  mm@192.168.1.19:.mozilla
......
data recv 26212 at 17498112
got file_sum
set modtime, atime of plugins/.libflashplayer.so.SRg3hr to (1708851990) 2024/02/25 10:06:30, (1745227819) 2025/04/21 11:30:19
renaming plugins/.libflashplayer.so.SRg3hr to plugins/libflashplayer.so
touch_up_dirs: plugins (3)
set modtime, atime of plugins to (1725698206) 2024/09/07 10:36:46, (1745210261) 2025/04/21 06:37:41
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=10542  hash_hits=75402  false_alarms=0 data=62897854
recv_files phase=2
recv_files finished
generate_files phase=3
generate_files finished
client_run waiting on 16864

sent 63.082.485 bytes  received 3.665.668 bytes  194.885,12 bytes/sec
total size is 642.943.026  speedup is 9,63
[sender] _exit_cleanup(code=0, file=main.c, line=1338): entered
[sender] _exit_cleanup(code=0, file=main.c, line=1338): about to call exit(0)

PS1: le top du top c'est que maintenant tout fonctionne normalement. Comme ça m'est déjà arrivé une fois je ne crie pas victoire, surtout que la source du problème reste inconnue. Une interférence avec je ne sais quoi?

PS2: effectivement, maintenant c'est une autre ligne du script qui bloque.

PS3: même chose, le blocage a fini par disparaître tout seul et maintenant tout fonctionne correctement. pff...

[tony]

comment mesurer le taux de transfert de la connexion ssh en temps réel?

[piratebab]

Tu peux essayer speedometer.
Perso je transfere plus fichiers de taille différente et je regarde le temps d'rxécution avec time

[tony]

Ce qui me paraît bizarre c'est que lorsque je réalise une mise à jour de Debian 11 sur mon ancien portable à partir de mon portable actuel je n'observe pas ce phénomène de pause puis de reprise etc.., pourtant la quantité de données transférées est bien, au moins dans certains cas, màj d'un noyau par exemple, environ 400Mo, du même ordre que celle nécessitée par la sauvegarde du répertoire .mozilla, environ 600 Mo au maximum. Dans les deux cas, script et màj, j'utilise le protocole ssh il me semble.

Je vais être plus attentif lors d'une prochaine màj d'ampleur.

PS: j'ai ecrit une bêtise, la màj vient d'internet et non de ssh , seul l'ordre de la màj passe par ssh.

[tony]

je viens d'avoir la réponse sur le site US: il s'agit d'un bogue, bug#1018106, qui dépendrait des versions en présence. Le correctif, qui fonctionne pour moi, à apporter dans /etc/pam.d/sshd

Code : Tout sélectionner

#session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale  ---> ligne fautive
session    required     pam_env.so envfile=/etc/default/locale

je n'ai toujours pas pris l'habitude de vérifier la liste de bogues connus en cas de problème. Dans une autre vie peut-être.

PS: c'est pas gagné, même avec le N° je ne le trouve pas! Duckduckgo est plus intelligent que moi: https://bugs.debian.org/cgi-bin/bugrepo ... ug=1018106 --> date de 2022, eh bé, ça sert à quoi les mises à jour?

[piratebab]

Plus un paramètre obsolète qu'un bug. C'est étonnant que lors des mises à jour, il ne t'ai pas demandé la mise à jour de ton fichier sshd. C'est peut étre ça le "bug".

[tony]

Plus un paramètre obsolète qu'un bug. C'est étonnant que lors des mises à jour, il ne t'ai pas demandé la mise à jour de ton fichier sshd. C'est peut étre ça le "bug".

c'est ce que Duckduck vient juste de me montrer. Mais il a mis du temps à se manifester ce bogue.

PS1: ce qui est curieux avec ce "bogue" c'est que la ligne que j'ai corrigée sur mon ancien portable est aussi présente actuellement sur celui que j'utilise, elle n'a pas l'air de poser problème. Par contre la réponse à la commande journalctl -b 0 -g sshd --no-pager n'était pas la même: aucun retour de mon portable actuel, mais retour "positif" de mon ancien portable, soit:

Code : Tout sélectionner

sshd[1308]: pam_env(sshd:session): deprecated reading of user environment enabled

j'ai donc apporté la correction proposée au fichier de mon ancien portable et ça a l'air de fonctionner, au moins jusqu'à présent. Mais comme mon portable est le client, donc n'utilise pas le fichier sshd_config, peut-être est-ce normal? C'est vraiment curieux tout ça.

Si jamais ça devait recommencer je passerais la config de sshd (ancien portable) de UsePAM = yes à UsePAM=no, ça devrait le calmer.

PS2: dans le rapport de bogue, à la date du 30/10/2024, il est indiqué:

Code : Tout sélectionner

Marked as fixed in versions openssh/1:9.8p1-3.

, or les versions sur mes deux portables sont les mêmes, 1:9.2p1, donc non corrigées

Code : Tout sélectionner

~$ apt policy openssh-server
openssh-server:
  Installé : 1:9.2p1-2+deb12u5
  Candidat : 1:9.2p1-2+deb12u5

effectivement, c'est peut-être là que se trouve le fameux bogue. Si un jour mon portable devient "serveur" je pourrais bien avoir le même problème.

[tony]

je viens d'avoir le même problème avec la commande

Code : Tout sélectionner

rsync -a /home/<user>/ mm@192.168.1.19:/win/home/<user> --delete-after

les autres répertoires, .mozilla, .thunderbird et Documents ne présentent aucun problème. Donc cette modif ne suffit apparemment pas. J'ai donc mis UsePAM = no dans la config de sshd, et enfin, la commande récalcitrante est exécutée assez rapidement (vu le volume de données c'est peut-être normal?). Mais quand même, avant ça fonctionnait sans cet artifice.

[piratebab]

Je ne me suis jamais posé de questions sur usePAM, j'utilise une authentification par mot de passes.
Peut étre as tu des problème avec le PAM ? J'ai découvert un peu par hazard que le PAM ne fonctionnait pas bien sur une de mes machines à cause d'un probleme avec la base de données.
Cette discussion est interessante:
https://unix.stackexchange.com/question ... -usepam-no

[tony]

configurer sshd n'est pas une mince affaire et il est possible que, faute de comprendre ce qui est en jeu, mes choix ne soient pas très cohérents. J'ai simplifié l'affaire en utilisant les choix qui apparaissent dans cette page pour ce qui est des chiffrements en particulier: https://www.ssh.com/academy/ssh/sshd_config.

Quant au choix de UsePAM je vois que ça ne fait pas l'unanimité. Je vais le laisser à "no" et m'inspirer de ce commentaire:

So in my opinion I would rather set it to no and don't lose sleep over it anymore.

[piratebab]

D'autant plus que le man ne semble pas étre clair d'aprés les commentaires.

[tony]

ça fonctionne bien 10 fois et la 11ème ça devient de nouveau très lent qq soit le répertoire transféré.

J'ai installé tcpdump pour capturer le traffic sur le port 22: ça m'a déjà fourni un résultat = même lorsque j'ai l'impression que le transfert est arrêté, en fait il continue car la sortie de la commande

Code : Tout sélectionner

tcdump -i wlx30689305a55c port 22

défile constamment, indiquant donc un flux continu de données sortant du port 22.
Comment est-ce que je pourrais utiliser cette commande pour aller plus loin?

[piratebab]

Si tu veux analyser un flux réseau, utilise wireshark.
J'espere que ton ssh n'est pas en train d'envoyer tes données sur des serveurs en chine ou en russie :)