rsync - Dec 2003 - rsync --daemon fails on systems with nfs-kernel-server

I have been using rsync in daemon mode to get backups of systems.  The
daemon would not start on one system.  Gave the syslog message that
the 'Address already in use'.  netstat, lsof, ps - nothing exposed the
process that was taking the port.  It would not time out and magically
start either.  I started rsync on a different port and it ran fine. 
This still was not a great solution, as I did not code all the parts of
the backup to point to a special port.  And it bugged me.

Turned out that the nfs kernel server was running.  When I shut down
that service, rsync would start in daemon mode on the default port!
I no longer needed this system to serve files, so this solution worked. 
Is this a known conflict, or has anyone seen this?  

My system is a debian (running sid - unstable), and rsync v. 2.5.6-1,
kernel is 2.4.22.  I have another system where I intermittently cannot
start rsync in daemon mode, and it serves nfs as well.

-- 
William Geddes <wgeddes@wgeddes.com>

On Fri 05 Dec 2003, Bill Geddes wrote:
> I have been using rsync in daemon mode to get backups of systems.  The
> daemon would not start on one system.  Gave the syslog message that
> the 'Address already in use'.  netstat, lsof, ps - nothing exposed
the
> process that was taking the port.  It would not time out and magically
That's strange, as it won't say that if the port isn't in fact in
use...
Did you try 'telnet 127.0.0.1 873' ?

I usually do "fuser 873/tcp" to determine the process that's using
that
port.
> Turned out that the nfs kernel server was running.  When I shut down
> that service, rsync would start in daemon mode on the default port!
> I no longer needed this system to serve files, so this solution worked. 
> Is this a known conflict, or has anyone seen this?  
The only thing I can think of is rpc.mountd.
>From the manpage:
       -p  or  --port num
              Force rpc.mountd to bind to the specified port num,  instead  of
              using the random port number assigned by the portmapper.

This implies to me that it basically uses a random port number. In fact,
on my system now it's using 834. On another it's using 1009. So it's
entirely possible that on your system you will find it running on
rsync's port...


Paul Slootman