Patch to prevent multiple dhclients starting on an interface

[Ted Lemon]

On Jun 15, 2005, at 10:57 AM, LaMont Jones wrote:
> Some (old??) Unixes would have the port remain busy so long as  
> there was
> any association with it, including some time beyond the final close.
> Hence SO_REUSEADDR - which does suck for this case.
That makes sense for a stateful connection, such as a TCP connection,  
but not for a stateless socket, such as a UDP socket, where there is  
no actual connection.

> It could check against basename(argv[0]), which would then just  
> require
> that the client be the same name as ours.  Likewise, it could parse
> netstat -an output, which is probably even more OS-specific in format.
This depends on the shell that loaded the process, doesn't it?   My  
experience has been that some shells set argv[0] to the filename, and  
others set it to the basename.   But this is really nitpicking; the  
main problem is that it's not portable.

> In the more-complete department, one could add a unix socket to the
> daemon, which the new one could try issuing commands through, and
> determine live/dead status that way....  Actually, long term, that's
> far better than talking to it with signals, although it's more code to
> deal with.

Right.   This is why I suggested d-bus.   I think the DHCP client  
should be a lot dumber (e.g., not do DNS updates, and not write  
resolv.conf) but should use d-bus as a way both of being controlled  
and of reporting the network configuration information it's gotten.

This opinion is somewhat moderated by the observation that d-bus  
looks a little bit more complicated than it needs to be, but given  
that a lot of people are implementing to it, it still seems like the  
best candidate.