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" <pl...@agora.rdrop.com <mailto:pl...@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.vola...@einsteinmed.edu <mailto:maurice.vola...@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 \ > al...@labadmin-precision-tower-3620.montefiore.org > <mailto:al...@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? -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
