rsync might chroot to any directory (basically whatever is configured as "path" option in /etc/rsyncd.conf) before it starts doing it's thing. During execution rsync calls mkstemp (or mktemp) inside a chrooted environment.
The uClibc environment of mkstemp/mktemp tries to read /dev/urandom (or /dev/random) to generate random contents for the .XXXXXX part of its argument.
In a chrooted environment /dev/[u]random might not be available.
Because of this the mkstemp call fails and returns "-1" and rsync fails and
issues something along the lines of:
rsync: mkstemp ".tmp.XXXXXX" (in <module>) failed: File exists (17)
imho this is a bug in uClibc and not in rsync. mkstemp should not depend on
/dev/[u]random. Perhaps, instead it should fall back (like glibc) on
gettimeofday(2) and getpid(2) for providing randomness instead of failing.
PS: uClibc and busybox are great! We (= isp) use them to build an initrd environment to boot +/- 200 servers. uClibc+busybox have decimated the
time we need to install a new server from a week to 5 minutes! Please keep up the good work.
# gcc -static -Wall -o mkstemp mkstemp.c
# cp mkstemp /tmp
# chroot /tmp ./mkstemp /foo.XXXXXX
mkstemp: File exists
Similar behaviour can be shown for mktemp.
mkstemp.c [^] (223 bytes) 02-18-05 11:49 
