Nicolas Williams writes: > > I'd be weakly supportive of having a kernel feature that allows > > dhcpagent to set a time bomb: first have it tell the DHCP server that > > we want only another 5 minutes, then tell the kernel to tear down the > > interface if 5 minutes elapses and the OS hasn't yet halted. > > Set the new lease expiration to one hour, or anything that's long enough > that you can be certain that you'll get from killall to halt/poweroff/ > reboot (or that someone will notice that it's taking long enough to get > there) yet significantly shorter than the orginal lease. > > Out of curiosity: does the protocol (DHCP) even support this??
Yes. The client can request a particular lease time, and can do it whenever it wants. Unfortunately, the server is not required to go along with the client's suggestion, so your alternative (if the server didn't agree) would be to just drop off the net anyway. The server can't force you to stay running. ;-} > > The argument against that (at least historically) is that dhcpagent is > > part of the OS. We shouldn't have to code against its failure any > > more than we should have to code against kernel panics. :-/ > > I think the argument against the above is that it's one thing to allow a > pathological situation to exist in presumably-rare accidents, and > another to do it by design. My point was that your worry seemed a bit > overwrought and I wanted to see how far it went :) > > That dhcpagent is part of the OS is irrelevant; of course dhcpagent can > fail. The whole self-healing philosophy is to react usefully in the > face of failures. There are at least a few of us who are somewhat dubious of that prospect. It probably makes operational sense to put some unreliable services under a restarter (if you have no alternative to fix the service), but from a design perspective, it just seems like darned poor engineering to relaunch a process and hope things go better this time around. "Self-healing" makes sense if you can reconfigure yourself to deal with a failure. I don't think it makes as much sense if you keep trying something that's broken. Sometimes, a deterministic machine actually needs a deterministic fix. ;-} -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
