Nicolas Williams writes: > Well, the problem is that we're releasing leases too soon because other > parts of the system are still using them, but that use is implied, and > because that use may be crucial to system operation during shutdown (for > / itself) the release operation has to be almost dead last on the list > of things to do (like, just before halt/poweroff/reboot). But "almost > dead last" means "long after all user-land processes have been killed."
I think there's a higher level to this problem. We have a dependency that exists because of a specific system configuration issue, and this is the sort of thing SMF doesn't currently express well. It's analogous to the cases where (for example) configuring 127.0.0.1 in resolv.conf and setting up a local caching server creates a dependency for name services on that local server. I suspect that there are a lot of these sorts of dependencies. Maybe we can just treat each one as a special case, and devise a different solution for each one, but it's also possible that what we need is a "set dynamic dependency" feature. > So either we make it so that dhcpagent can be left alive after all the > other user-land processes have been killed, or we move the lease release > code path into kernel-land. One strike against the former solution is that if your file system is on some network-backed storage (such as iSCSI), then the dhcpagent executable itself is dependent on having that storage still present, unless we do something special to make sure that all of its pages are locked in memory. There's a circular dependency that needs to be broken. Strikes against the latter are that (a) you'd have to move parts of the control path information there, which is icky, and (b) DHCP isn't the only daemon that has this sort of problem; IPMP does as well. Right now, we just exit, and leave everything as it was. That's not completely right, but it's certainly simple and testable, and it's still unclear to me what we'd have to do to be entirely right. > There is another not-a-band-aid option: don't release the lease on > shutdown if proper shutdown past the killall step depends on networking. > > Not releasing a lease is anti-social, but arguably less so than > continuing to use the IP address past releasing it. Then again, I think > most DHCP servers and networks using DHCP will tolerate brief uses of > IP addresses past release. Note that in the solution described in the original project (the one just approved by PSARC), we do not release the lease or clear out the interface before exiting. I think that's actually the safest thing to do, and the most in tune with the standards. Releasing the lease and continuing to use the address would not just be an "anti-social" thing to do, but it could also cause real failures on networks with address use pressure, and would almost certainly cause us to fail various compatibility and conformance tests (like those at UNH). That doesn't seem like a good path to me. -- 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]
