CentOS - Apr 2021 - rsync over ssh stalls after completing the job

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 at 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.
>
-- 
Christopher Wensink
IS Administrator
Five Star Plastics, Inc
1339 Continental Drive
Eau Claire, WI 54701
Office:  715-831-1682
Mobile:  715-563-3112
Fax:  715-831-6075
cwensink at five-star-plastics.com
www.five-star-plastics.com

On Tue, 13 Apr 2021 12:43:16 -0500
Christopher Wensink wrote:
> Does it behave any differently when adding a & at the end of the
command
> when running it manually, or running in a screen session?
Nope.  I get the same stall both ways.  Running it in a screen session looks
exactly like what I posted earlier, and the & at the end of the command
looks like this:

[me at mutt temp]$ rsync -avv ../temp/ jeff:temp &
[1] 15694
opening connection using: ssh jeff rsync --server -vvlogDtpre.iLsfxC . temp  (7
args)
[me at mutt temp]$ sending incremental file list
delta-transmission enabled
bookmarks.html is uptodate
abc
total: matches=38  hash_hits=38  false_alarms=0 data=0
^C

The difference here is that I don't see the "rsync error: received
SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(644) [sender=3.1.3]" after
the ctrl-c when I use the &.  That line shows up only without the &.



-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com