Jordan Brown (Sun) wrote: > Christin Tran wrote: >> Do you want service X to be part of m-u-s? Hard to say, >> without asking what sysadmin fuctions are typical when I boot >> into m-u-s. > > Liane Praza wrote: >> To put it simply, I don't see any reason to bother putting a new and >> unbundled service into a late-boot milestone. But, there's no harm in >> it either. > > Hmm. OK. Currently our service isn't in any of the milestones, which > is compatible with what you're saying. However, it confused one of our > QA people, so I'd like to probe a bit more. > > When we tell an administrator "you can configure the system to boot to > milestone/multi-user-server", what do we tell them about what that > *means*? What services should the SA expect to be running when the > system is at m-u-s?
The ones multi-user-server depends upon. We've never made many guarantees beyond the general definitions offered in init(1M), and I'll suggest that even those general definitions haven't been strictly honored before smf(5) arrived. We went to extra lengths to provide compatibility so that existing practices weren't unnecessarily compromised. But, you're talking about booting to a milestone, which is a new operation. It comes with a new definition. The init manpage pretty carefully uses the word "restrict" when it comes to run levels 2 and 3. > If m-u-s is equivalent to init level 3, then the answer is "all of > them", which would suggest that m-u-s should depend on all services. But > then again, that's what "all" means, so what's the intended distinction > between m-u-s and "all"? > > Perhaps m-u-s was a mistake, and init level 3 should be equivalent to > "all", to avoid that gray area. multi-user-server and all are separate so that a service can be defined that runs "at the end of rc3" for compatibility with the common practice of using rc3/S99 for unbundled products. I believe a number of products use this capability explicitly. (Though, again, explicit dependencies are better if you're in a position to articulate them for the service you're describing.) Depending on "all" would be a fairly nonsensical operation from a system point of view, though I'm sure someone now will request it again. It's fun to postulate what should have been here instead of what we chose, but it turns out that what now exists in this particular area works out pretty well for most deployments. liane
