epmd

[Klacke]

On Tue, May 30, 2000 at 06:14:29PM +0100, Richard Barrett wrote:
> Around lines 135 to 146 of this source file, conditional compilation 
> of a setsocketopt call to enable the SO_REUSEADDR option occurs if 
> the OS being compiled under is not _WIN32_.
> 
> In effect, the coding assumption is that on non-_WIN32_ (that is, on 
> UNIX or Linux I guess), an attempt by a new instance of epmd to bind 
> to port 4369 when another instance of epmd is already bound to that 
> port, will fail even if the SO_REUSEADDR socket option is set on the 
> socket being used to bind to the port  This bind failure is in effect 
> used to determine if epmd is already running.
> 
> It turns out that Suse 6.2 Linux (as on _WIN32_) and possibly other 
> versions of Linux, take the SO_REUSEADDR socket option at face value. 
> In consequence, bind failure, when this socket option is used, is 
> inadequate as the sole determinant of whether epmd is already extant 
> in the system.


Here are my cents ...

1. The only reason (as far as I can see) to have SO_REUSEADDR on the
epmd socket is while debugging epmd. That is while starting and stopping
epmd several times. So the SO_REUSEADDR option should be removed on 
the epmd daemon.

2. This is the first OS I've ever heard of that actualy steals the
port from another unix process that has already bound the port
to a socket. This simply cannot be right. I was living under
the impression that the SO_REUSEADDR ment that a bind attempt
to a port should succeed even if the port was still lingering 
in the kernel queue for old port bindings, assuming that no
process had the port already bound. In the latter case, the bind 
shall fail.


/klacke