Paul Hass: re 2.5.5 fork

Trevor Marshall tm at
Mon Sep 9 15:28:59 EST 2002

>Is there more than one rsync running?  In 2.5.4 a failure in another rsync
>process could kill your rsync.  I haven't studied the code recently, but I
>don't think there are any calls to fork() after it has started transfering

I recall 
bash$ ps -aux  
showed 2 rsync processes, maybe three when the rsync was executing on the
other console. I have plenty more available:

bash$  ulimit -a
core file size (blocks)     0
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    unlimited
open files                  1024
pipe size (512 bytes)       8
stack size (kbytes)         unlimited
cpu time (seconds)          unlimited
max user processes          768
virtual memory (kbytes)     unlimited

>    bash$ ps  U `whoami`  | wc -l

>Then see the total number of running processes with ps
>   bash$ ps ax | wc -l

>My system is a long way from running out of processes.
and mine

>I ran into the bug because we had a script that invoked a script that ...
>invoked rsync which invoked ssh, for a total of something like 8 processes
>per client, and we ran it for 20 clients, we misconfigured ssh so it hung
>on all the clients, leaving all 160 processes running, then cron came
>along and started a whole new set of 160 processes.  Which didn't work,
>because the limit was 255.  Fortunately, it wasn't running as root.

Only one client (root) (maybe wwwrun etc) so there shouldn't be a problem
there. Maybe it iis the way that the kill() error trap is reached is
different in your case and my case, but it still may have been the sme
trap. I'll have to look at the code. 

I am not sure that the ulimit display (above) is not a warning - not sure
that virtual memory (kbytes) should be unlimited. I have a finite swap
partition. Maybe a kernel problem there...

Thanks for your help. I will keep looking...


More information about the rsync mailing list