Initial debug of client - Need command line help

Martin Pool mbp at samba.org
Tue Apr 16 21:45:02 EST 2002


On 16 Apr 2002, "John E. Malmberg" <wb8tyw at qsl.net> wrote:
> tim.conway at philips.com wrote:
> >Experts, feel free to jump on me for being wrong, but the forking, as i 
> >understand it, is integral to the way rsync currently does its work, and i 
> >don't think you can realy debug it in the classical sense.  Anybody found 
> >a way around this one?
> 
> A multi-process debugger can handle forked processes, but it can be
> tricky.

Personally, I just run two or three debuggers (gdb), one on each
process, in different windows or virtual terminals.  Since rsync only
uses Unix IO to synchronize its various moving parts this works quite
nicely.

gdb is supposed to be able to catch a child just after it forks but a
few months ago that didn't work.  Perhaps it does now.

Failing that, I would just put in a sleep(60) at the start of each
child.

> I am guessing that the initial fork() of RSH is to allow the user to 
> initiate an rsync client session to run in the background with out tying 
> up the main shell session.

OK, really briefly:

There are three rsync processes.  You can think of them as "threads",
and they might be in a Java or Windows program.  Instead, they're
actually seperate processes, both because that's much more portable on
Unix, and because in some ways it is cleaner.

They are:

 generator -- traverses the destination directory, calculating
 checksums and timestamps of existing files, which it sends to the

 sender -- traverses the source directory, consumes the checksums and
 uses them to calculate deltas, which it sends to the

 receiver -- traverses the destination directory, applys deltas and
 produces the new files

So obviously the generator and receiver run on the destination
machine, and the sender on the source, with a socket in between.

The best way to think of this is as two of the "producer-consumer"
patterns from a threading textbook hooked up back to back.  The other
complicating factor is that we also need to pass error messages around.

Obviously there are some tasks like deleting files, etc, that I have
not mentioned but they go into fairly obvious places.

We also fork some additional processes, particularly, as you noticed,
rsh (or ssh, or whatever).  This is forked because unix doesn't have a
spawn() system call -- to start a slave process you fork, fiddle with
file descriptors, and then exec().

The daemon forks itself into the background as a convenience; the
regular program does not do this.

You might enjoy reading "Linux Application Development" by Johnson &
Troan (?), which has a pretty good overview of how all that stuff
works in general.  The relevant chapters are not particularly
Linux-specific.

-- 
Martin 




More information about the rsync mailing list