RSync random failures
Tue Dec 2 20:08:00 GMT 2008
>>In the event log the following message was found:
>>rsyncd: PID 1800: rsync error: error in file IO (code 11) at
> I downloaded the source, rebuilt and I am running under the debugger. The
> line indicated above is where RSync discovers that the PID file already
> exists. While that specific problem is solved by deleting the PID file,
> the problem is that the PID file should never exist after RSync exits.
> There is some condition that leaves the PID file when RSync shuts down (as
> a service under Windows XP) normally. This problem did not exist in the
> previous version (2.6.9-2).
> I have tried hibernation, stand-by, shutdown & restart, network
> disconnections, various signals passed, etc., and nothing reliably causes
> the problem to manifest itself. But any of these methods has caused the
> problem. It seems to happen more frequently during shutdown & restart than
> any other method.
> Any ideas on how to debug? Anyone else have this problem?
I did not use a PID file. Because that my rsync did not have a problem with
Maybee you did not use a PID file?
Because of your hibernation/stand-by tests. Did you know if it is possible
to disable hibernation/stand-by during rsync is running?
The problem is when rsync is not actively connected to a client. When started as a service, an instance of rsync is running listening for connections. When the connection occurs, the transfer takes place. Afterwards, the original instance remains still listening for connections. When running as a service waiting for a connection, something happens to it which causes it to fail and exit without cleaning up. This leaves a PID file which blocks all restart attempts. I then must manually clean up the PID file to allow the service to restart. Obviously, leaving the PID file should not take place which is the symptom of the true problem.
Something is causing rsync to fail without cleaning up the PID file. Sometimes it is a reboot (most often due to that). Sometimes during a transfer it will fail and not cleanup properly. I have not yet figured this out and was hoping others saw this as well.
I did notice that while debugging (with gdb) rsync that if I type Ctrl-C that the task stops without cleaning up. However, I'm not sure if that is due to how gdb works, or something else.
Again, this is with rsync-3.0.4-1. This cleanup problem did not exist with rsync-2.6.9-2. As a temporary solution, I am back to the older rsync on most of my machines until we get this current problem resolved.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin