What could cause rsync to kill ssh?

[Maurice R Volaski]

This Gentoo VM is ZFS and BIOS based. I have a pretty similar Gentoo VM that is btrfs/UEFI-based. I am able to run rsync on it with no trouble, so I have just switched to that. The cause for why rsync is bringing down sshd likely will remain a mystery. 

Thanks for your inputs.

On 6/3/23, 04:55, "Perry Hutchison" <pluto at agora.rdrop.com <mailto:pluto at agora.rdrop.com>> wrote:


CAUTION: This email comes from an external source; the attachments and/or links may compromise our secure environment. Do not open or click on suspicious emails. Please click on the “Phish Alert” button on the top right of the Outlook dashboard to report any suspicious emails.


Maurice R Volaski <maurice.volaski at einsteinmed.edu <mailto:maurice.volaski at einsteinmed.edu>> wrote:


> Rsync 3.2.7 is running on the Gentoo computer, which doesn't have
> a version, other than it's "current". I'm running the script from
> this computer.
>
> Rsync 3.1.2 is on the source computer, where the files come from,
> which is Ubuntu 18.0.4.6.
>
> I'm copying to a CIFS share mounted on the Gentoo computer.
>
> The rsync scripts are all similar to this one:
>
> /usr/bin/rsync -v -a --progress --exclude-from=${exclude} --safe-links --itemize-changes --no-perms --no-owner --progress --stats \
> alexa at labadmin-precision-tower-3620.montefiore.org <mailto:alexa at labadmin-precision-tower-3620.montefiore.org>:/home/alexa/ /mnt/data.einstein/luke/all_but_dat/alexa/desktop_bkup/profile \
> >> /home/maurice/logs/rsync-client-alexa.log
>
> I re-ran the scripts skipping this one. The next one was running
> and during that period, ssh stopped responded to new connections,
> so it may be the case that the failure is taking place across
> time, and it doesn't fail wholesale immediately.
>
> However, I have other scripts like these copying from other
> sources (not Ubuntu) and they are not causing these failures.


You have several moving parts, which complicates figuring out which
of the various interactions is contributing to the problem.


BTW anyone else on the list is more than welcome to weigh in. I am
hardly an expert on rsync, and not at all familiar with the ins and
outs of either Gentoo or CIFS.


One thing which I think is most likely _not_ involved in the problem is
sshd on the Gentoo system, and this is consistent with the observation
that restarting sshd did not help. (If I'm reading the rsync command
correctly, rsync on the Gentoo system is establishing the ssh
connection and transferring the files over it. Gentoo's sshd would
be involved only if the client were initiating the connection.)


Is there anything interesting in the rsync logfile, especially near the
end, or in the any of the involved machines' system logs (including the
CIFS host) around the time of the hang?


Does the Gentoo system have enough space for rsync to copy the files
to a local drive, so that rsync and Samba are not both working on the
same transfer at the same time? (The files can then be copied to the
CIFS share in a separate step, using "cp -r" or some such.) If rsync
still fails when arranged that way it would tend to eliminate CIFS as
a factor (and it will simplify the environment); OTOH if that "solves"
the problem you'll at least have a workaround.


Totally separate from that, is this Ubuntu system the only client using
Ubuntu 18.0.4.6 and/or rsync 3.1.2?