DHCP "static" assignments

[Simon Hobson]

A.L.M.Buxey at lboro.ac.uk wrote:
>> I'm pretty sure when you send a HUP to dhcpd, it dies. You have to stop it and then invoke it again.
>
>if it does then thats annoying and a bug  ;-)....its probably something to do with
>permissions, dropping to the chroot'd etc - who knows. anyway, its an example.

That is it's mode of operation - there is no way to reload the server. Though it's debatable whether it should quit or ignore the HUP signal.
That is by design, and is (at least by frequent mentions on this list) documented behaviour.

The argument is that given what dhcpd does, and how it does it, a reload would in practical terms simply jump to the program entry point and behave in the same way as if it had just been launched. SInce there is little (any ?) benefit, why spend precious developer time on that when there are far more important things to deal with ?
There is also the issue of whether it would be able to re-initialise properly having dropped privileges when it forst started.


Steven Carr wrote:
>My bad, I was under the impression that DHCPD knew that the
>fixed-address was the owner of the address and so wouldn't hand out a
>pool address to a dynamic client (as it was already owned).

It was written on the assumption it would be used by admins who know what they're doing ! In general, it's difficult to allow the richness of config options available in the ISC server while still providing that level of handholding - it may be a perfectly valid and deesired config on the part of the admin (though I do struggle to think of a valid use case !)
There is an argument for adding a startup warning if any fixed-address si within any range statement, as was done (IIRC) for host declarations within a subnet declaration.