We are trying to use a cygwin build of rsync to accomplish backups of
Windows machines.  We are running the backup as a scheduled task.  If
a user is signed in interactively when the task runs, everything works
great.  If no user is signed in, then the task starts but never makes
any progress towards completion.  If a password protected screen saver
is up when the task starts it GP faults.
The task scheduler service is set to run as the 'Local System
Account', and 'Allow service to interact with desktop' is checked.
The task itself is configured to run under the machine's administrator account.
I'm looking for a solution that will allow rsync to be scheduled for
unattended operation while the user is logged off, or a screen saver
is active.

---

Request for Question Clarification by leapinglizard-ga on 02 Jun 2005 22:10 PDT

One possibility is that the fault lies not with rsync but with the
task scheduler. You can test this hypothesis by scheduling the rsync
job using a different tool. For instance, to use the classic UNIX
utility scheduler, cron, make sure your cygwin installation includes
cron and cygrunsrv, then execute

  cygrunsrv -I cron -p /usr/sbin/cron -a -D
  net start cron

to start the cron daemon. Now the administrator can schedule a job by executing

  crontab -e

to edit his cron file. Just to give you an idea of the crontab format,
I would write the line

  00 07 * * * /usr/bin/cdplay

to start my CD player at 7 o'clock every morning, or

  30 14 * * 6 /usr/bin/xmms --play

to play my MP3s at 2:30 in the afternoon on Saturdays. See the
following link for a complete description.

ClockWatchers: Cron Tutorial
http://www.clockwatchers.com/cron_general.html

Please try out the cron approach and tell me whether it improves matters.

leapinglizard

---

Clarification of Question by fluxsmith-ga on 06 Jun 2005 11:54 PDT

Thanks for the suggestion.  We tried scheduling it with cron as you
suggested.  When scheduled with cron then even with the user logged in
rsync starts, but only performs 15 io operations and makes no forward
progress.  At this point I'm suspecting a security issue of some kind,
however the logged in user is in the local administrators group, and
the cron service is running under the system account.
I find it interesting, but don't know the meaning, that when run by
cron with the user logged in, the behaviour is the same as when run as
a window's task with the user logged out.

---

Request for Question Clarification by leapinglizard-ga on 06 Jun 2005 12:30 PDT

Very curious. If these difficulties take place only with rsync and not
with any other scheduled task, then perhaps the rsync implementation
is indeed responsible. If you have the time, you might experiment with
a different build of rsync -- earlier version, later version -- or try
scheduling other tasks that copy files across a network, such as rcp
and scp. I would probably start with the latter experiments myself.

leapinglizard

Could a work around use a scheduled task the does work when a user is
not logged in or a password protection screen saver is present. That
is, can you use a brief inert scheduled task that changes the computer
to the state in which rsync will work to precede it. Are there any?

It seems that the inability of rsync to run (or other programs) in
unattended states prevents security breaches from unauthorized users.
Theoretically, there may be security risks if someone could configure
and schedule rsync to run UNKNOWN to authorized personnel to copy
secure files to another computer in unattended states.

The problem turned out to be a different default location for the .ssh
directory when launched by the scheduler in a non-interactive
environment.  SSH would start up and hang when it would have normally
prompted for an addition to known-hosts.

The solution was simpler than that, just have to log in as the account
the scheduled task is configured to run under and run ssh manually
targeting the backup server so that you can answer the prompts to add
it to known hosts.
What made it confusing is that the scheduled task worked fine when the
normal user was logged in.  I am guessing that in that case the
scheduled task assumes the permissions of the account it is configured
to run under, but retains the environment of the user.