On 6/25/07, Glynn Foster <[EMAIL PROTECTED]> wrote:
I'd guess that would be a requirement for an eventual package management system - to be able to split packages up into whether they required a reboot or not.
Instead, how about being able to analyze a running system to determine if it requires a reboot. For example, on many systems applying a patch that changes /kernel/fs/sparcv9/ufs will require a reboot. However, if the machine does not have the module loaded, that should not trigger a reboot. If /export/junk is the only UFS file system, it would be really nice if it could determine that the NFS exports and programs using /export/junk would need to go away so that ufs could be unloaded, the new one reloaded, remount, share, and restart relevant services. Similarly, if libC.so is patched, it would be extremely nice for the system to look at processes that have it mapped, trace those to SMF-managed services, then tell the administrator the minimum set that needs to be restarted (or do it automatically, if so configured). I recently saw a demo of Sun Update Connection Enterprise (I can't help but pronounce it "sucky" - much better than "sucks" that Sun Update Connection Satellite brings to mind). The log of patching a system from 118833-24 to 118833-36 had somewhere between 4 and 6 reboots listed. If the same thing had been done via the install_cluster script that comes with recommended patch bundles, it could have been done in one. This represents a step backwards. Hopefully Indiana can make the giant leap forward that is needed to address this sore spot in Solaris and actually make the patching of OpenSolaris a feature that attracts users because it sucks less than others. (The bar is so low because patching will likely never be a task that people look forward to.) Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ indiana-discuss mailing list [email protected] http://opensolaris.org/mailman/listinfo/indiana-discuss
