On Wed, Oct 22, 2008 at 03:41:15PM -0400, James Carlson wrote: > Nicolas Williams writes: > > If the actual proposal is to not release the lease, then I think that's > > a fine proposal. > > Yes; it's the same as with NFS. We just bail out without the normal > shutdown process.
Cool. > Obviously, we could use a *lot* more finesse here. There's no need to > do this unless the specific interface used to communicate with the > iSCSI target is under DHCP control. Except of course for routing- > level fail-over, it should be "safe enough" to wipe out interfaces > that are irrelevant to the problem. > > I guess I'm unconvinced, though, that this is the end of the problem. > Anything that could potentially "lock up" (e.g., an NFSv4 mount) > during shutdown due to the loss of an interface at the wrong time is > something that needs to be addressed with a dependency. If you mean "SMF dependency" well, I'm not sure that we can express everything as SMF services and dependencies. A way to tell SMF that there is a run-time dynamic dependency on some service would be very nice. > > I agree. An option to set negatively extend the lease time to now+5m > > or some such suitable value could be handy. I don't know if it's > > possible to use DHCP option 58 (or some other option) in this way in a > > DHCPREQUEST. > > That sounds like a good idea. If only we knew that we would be > shutting down in that amount of time. > > 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?? > > In any case, if we're really worried about continuing to use an address > > after the lease expires, then one'd think it'd be good for the kernel to > > enforce lease expiration just in case dhcpagent died hard and isn't > > getting restarted. > > Yes, that'd be another instance of the time-bomb concept above. When > initially configuring, set the bomb to go off when the lease expires, > so that no matter what happens to dhcpagent, we're being "good" on the > network. > > 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. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
