Does it behave any differently when adding a & at the end of the command when running it manually, or running in a screen session?
Chris
On 4/13/2021 11:45 AM, Frank Cox wrote:
Here's a weird one.
I have two Centos 8 machines that use rsync-over-ssh to back up files between each other. (Each machine acts as a backup machine for the other one.)
There's are nightly cronjobs that do the backing up, the commands look like this:
rsync -av --delete /home/mydirectory jeff:/home/mydirectorybackup
That command works fine when it's run through the cronjob.
When I try to run a rsync command between mutt and jeff from the commandline, that's where the problem starts. It worked a few days ago but now when I log into jeff and do a rsync to or from mutt it works fine. When I log into mutt and do a rsync to or from jeff it works and does the job, but then it seems to stall afterward and I have to hit ctrl-c to get my cursor back.
Here's a test run so you can see what happens.
[me@mutt temp]$ rsync -avv ../temp/ jeff:temp opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC . temp (7 args) sending incremental file list delta-transmission enabled bookmarks.html is uptodate ./ abc total: matches=0 hash_hits=0 false_alarms=0 data=26321 ^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(644) [sender=3.1.3]
A file named bookmarks.html existed in both directories so it wasn't changed, and a new file abc was copied to the backup directory. Then my ctrl-c stopped the job and brought the cursor back after it stalled.
scp works fine to copy files either way when logged into either machine and, again, my backup-this-to-that cronjobs that run rsync seem to be working fine as well. I just discovered this last night when I went to rsync some files manually between these machines. The last time I did that was at least a few days ago and it worked fine then.