> By its nature bootup is (or should be anyway) a read-only activity for > config files. I was reacting to the claim that rebooting during boot > could corrupt SMF's configuration. (Granted that claim may have been > exaggerated.)
That claim is just wrong. The only way rebooting during boot can corrupt SMF is due to a software bug in SMF, or failure of the underlying filesystem or disk infrastructure, as I described. All of those failure modes affect any operating system's mechanism for boot. > I do not believe that it is reasonable system design to allow an > interrupted read to corrupt something that is critical for the system > to operate. If (and I say IF) SMF were designed so that was possible > then I would regard that as sufficient justification to junk it and > start over. Yes, we understand that. SMF does not have this negative attribute. > The fact that SMF's internals are so deliberately opaque makes it > impossible for a typical admin to see if that is the case. The fact > that so many people (who don't want to) are *required* to deal with > SMF means there are a lot of people who need that assurance who won't > get it. SMF's internals are not opaque. There is a read-only copy of every manifest in /var. There are tools (svcprop, svccfg) that examine the database. There are tools (e.g. svcs) to view running services. What else are you looking for? > As I have said before, I do not know enough about SMF to have a > technical opinion. However from a marketing and customer confidence > standpoint it is clearly a disaster. Considering it's been shipping for nearly 3 years now, and hasn't prevented more than 3 million people from downloading and adopting Solaris 10, I think the evidence is overwhelmingly to the contrary. And more than that, it has significantly added value: every Solaris 10 system is able to perform dependency-based automatic restart of services thanks to SMF, including after isolated hardware failure. And we've worked with many customers who have created sophisticated automated service control environments that were not possible before, etc. If you have a *question* about SMF, or a problem, we're all ears. But I'd appreciate it if we could be a bit more data-driven. -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
