Bonjour,
Impossible de faire un rsync en Debian 10 alors que le même script fonctionne en Debian 9

La commande rsync est lancée par un cron qui lance un script perl et lance la commande suivante :
rsync -vrltH --delete --progress --numeric-ids --stats -pgo -D --exclude-from=/san/pcdsi/L105140/20210323163539/exclude --link-dest=/san/pcdsi/L105140/202102100956/tree "/mnt/pc-backup/L105140/Users/"/ /san/pcdsi/L105140/20210323163539/tree
Voilà ce que je constate en Debian 10 :
strace -o toto /usr/bin/perl /usr/sbin/dirvish --vault L105140
dirvish L105140:default error (23) -- partial transfer
expr: syntax error: unexpected argument '0'
expr: non-integer argument
dirvish error: branch /san/pcdsi/L105140:default image 20210324090006 failed

et
rsync: change_dir "/etc/dirvish//"/mnt/pc-backup/L105140/Users/"" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
Bien sûr sur tous les serveurs en Debian 9 c'est ok

Si je lance la commande rsync ci-dessus en Debain 10 en root tout fonctionne !!!!!

Dans les trace je vois :
unlink("/san/pcdsi/L107240/20210322112155/log.tmp") = 0
openat(AT_FDCWD, "/san/pcdsi/L107240/20210322112155/rsync_error", O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 7
lseek(7, 0, SEEK_END) = 0
ioctl(7, TCGETS, 0x7ffea4b62920) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(7, 0, SEEK_CUR) = 0
fstat(7, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
openat(AT_FDCWD, "/san/pcdsi/L107240/20210322112155/rsync_error.tmp", O_RDONLY|O_CLOEXEC) = 8
ioctl(8, TCGETS, 0x7ffea4b62920) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(8, 0, SEEK_CUR) = 0
fstat(8, {st_mode=S_IFREG|0640, st_size=65530, ...}) = 0
read(8, "rsync: change_dir \"/root//\"/mnt/"..., 8192) = 8192
le change_dir n'apparait pas en Debian 9

il semblerait que les open de fichiers soient différents :
L'appel système openat() opère de la même manière que open(2), excepté pour les différences décrites dans cette page de manuel.

Si le chemin fourni dans pathname est relatif, il est interprété par rapport au répertoire référencé par le descripteur de fichier dirfd (plutôt que par rapport au répertoire de travail courant du processus appelant, comme cela est fait par open(2) pour un chemin relatif).

Si pathname est relatif et si dirfd est la valeur spéciale AT_FDCWD, pathname est interprété par rapport au répertoire de travail courant du processus appelant (comme avec open(2)).

Si pathname est absolu, dirfd est ignoré.
Avez-vous une idée ?

je suis complétement bloqué pour l'installation des nouveaux serveurs. Thanks