Rsync on Windows XP works fine on-demand, but hangs when run as a scheduled task

Question

I want to use Rsync to back up a web site to a Windows XP system that gets backed up to tape every night. I've looked at cwRsync and Grsync, and they both work fine, as long as I'm running them while logged in to Windows. I can set up a scheduled task in Windows and run the task on-demand and even that works fine.

But when I try to run the scheduled task while I'm logged out, it hangs. When I next log in, the task shows as still running and I can see RSYNC.EXE and SSH.EXE processes running. I have to stop the task, then kill the two processes. Meanwhile no files were transferred. It does this every time.

I've added as much logging as I could, but the log stops at the Rsync command:

opening connection using: ssh -l user domain.com rsync --server --sender -vvnlogDtpre.iLs . /home/user/backups/site-backup.tar 

To rule out problems with the task scheduler, I created a simple batch job, scheduled it and logged out. When I logged back in some time later, the task had run when it was supposed to and the output was as expected.

The host system is a Linux shared hosting server. I have a CRON job set up that first dumps all the databases using mysqldump, then creates a TAR file of that plus all the folders I need to back up from the host. That part works like a charm.

And as I said, running Rsync on Windows to grab the TAR file also works fine, and I particularly enjoy the way it uses delta copying to move only the bits that are different. This saves a ton of traffic, which is one of the main reasons I wanted to use Rsync in the first place.

Answer 1

Problem solved. I started over with a fresh install of Cygwin to get the latest versions of SSH and RSYNC, and now it's working fine.

Answer 2

I've had this very problem and upgrading my Cygwin didn't do the trick.

I finally isolated the problem to the script which launched rsync; the script had these lines:

REM Set HOME variable to your windows home directory. That makes sure 
REM that ssh command creates known_hosts in a directory you have access.
SET HOME=%HOMEDRIVE%%HOMEPATH%

It seems that under Windows Scheduler the HOMEDRIVE and HOMEPATH aren't initialized so HOME was not set and ssh.exe hung while asking to accept the remote key.

After initializing HOME to a known directory it started working fine.

Answer 3

I had the same problem... I first updated my version of Rsync for windows from rsync.net, but that didn't help.

So Then I looked at their bat example file. I noticed the paths where not right for windows 2008.

I just opened up the environment variables for the system and added the following...

CWRSYNCHOME=C:\Program Files (x86)\cwRsync

CYGWIN=nontsec

CWOLDPATH ----- < just REM out in example batch didn't add to environment variables

*PATH=C:\Program Files (x86)\cwRsync\bin

*add to your already long PATH after a ;

then I just REM out all the set path stuff in the batch file EXCEPT SET HOME=C:\RSYNC <--- I moved my pub and private keys for SSH folders and files to this directory and made sure the security was set to everyone for this folder on the box running this because the task is run as a service account not the admin. and at the time I was trying to eliminate causes to fail.

• the example bat I am talking about comes with the install from Rsync.net for rsync - Its an older version but it worked for me (3.1) (the version i had before was 2.6, and I was trying to change as little as possible)

Rsync now runs as a scheduled task in Windows Server 2008 R2 no problem. every 30min

Lasted version of Rsync from the source (not what I used but probably wont hurt)

http://sourceforge.net/projects/sereds/files/cwRsync

I hope this helps someone stuck on this problem, it was very frustrating!!!

Answer 4

Having just run into this same issue in 2018 on Windows 10, I've discovered the root of the issue in my case being that the SYSTEM account (under which the task is being run) does not trust the target SSH server, and SSH will therefore endlessly prompt for trust, approval, or cancellation of the connection on a headless terminal session.

To address this issue, I added the server to the SYSTEM account's ~/.ssh/known_hosts file, copying it from my own user's.