rsync error: unexplained error

Dave Dykstra dwd at bell-labs.com
Tue Sep 3 21:48:00 EST 2002


On Sun, Sep 01, 2002 at 05:34:31PM -0700, jw schultz wrote:
...
> This sounds like a problem that was fixed a few months ago.
> You might try searching archives.  Upgrade to current
> (2.5.5) or the CVS tree. 

No, this problem has not been fixed in CVS yet.  I posted a hack patch back
in February
    http://lists.samba.org/pipermail/rsync/2002-February/006371.html

but we're still waiting for an answer from Andrew Tridgell through Martin
Pool as to why Tridge made the change in the first place.  Martin, have you
found out yet?  David's proposed solution, involving an array of exit codes
saved in the signal handler, is probably safer than my suggestion given
that we don't know why Tridge put in the handler.

David, please do submit the patch as a context diff (-c), or better yet as
a unified context diff (-u in GNU diff).

- Dave Dykstra

...
> On Sun, Sep 01, 2002 at 05:12:32PM -0700, David R. Staples wrote: (reformatted)
> > I believe I have found the cause of the unexplained error
> > (code ??) at main.c(line #).  In the version I'm running
> > 2.5.2 (obtained from the Free Software Foundation) the line
> > number is 576.  It appears the root cause is related to a
> > race condition associated with the termination of child
> > processes.
> > 
> > If the signal handler for SIGCHILD is executed, as the
> > result of a child termination, before the wait_process
> > procedure is executed, the status of pid (as passed to
> > wait_process) will not be available and the waitpid call in
> > wait_process will fail with an ECHILD error.  If however,
> > wait_process executes first, it will successfully obtain the
> > exit status of pid and the sigchld_handler can execute, to
> > eliminate zombies, with no adverse affects.  Since signal
> > handlers execute asynchronously there is no way to predict
> > when, if at all, a process will encounter this problem.
> > 
> > I am providing below proposed new code that should resolve
> > the problem.  Certainly I can make these changes within my
> > own environment, but since I would like to remain consistent
> > with the rsync project, I would like to here from someone
> > regarding incorporation of these changes into rsync or an
> > alternative (official) method to fixing this problem.  I can
> > be reached at drstaples at beckman.com;
> > drstaples at drstaples.com; or drstapl at empirenet.com
> > 
> > Sincerely,
> > David R. Staples
> > 
> > --------------------------------------------------------------------------------



More information about the rsync mailing list