On Fri, Jan 25, 2008 at 02:54:14PM -0800, David Bustos wrote: > Quoth Nicolas Williams on Fri, Jan 25, 2008 at 04:30:32PM -0600: > > I don't see why a neatly packaged interface for asking restarters (or > > svc.configd) for state information would be the same thing as exposing > > implementation details. > > I don't either. There's already an interface for asking restarters > about the state of a service: smf_get_state(). If you're talking about > state other than the SMF state, there is the auxiliary_state property, > but beyond that will have to be restarter-specific (currently).
smf_get_state() is polling. And per-instance. Using smf_get_state() to track multiple services won't scale. > But that's not what we were talking about. Alan wants nwamd to observe > the commands which administrative tools issue for services. The design > assumes that you only want to do that if you're the service's restarter, > and then you should use the restarter interfaces. If there are cases > where non-restarter components need to do that, then we need to consider > whether the existing interfaces can be expanded, or a new interface > designed, or perhaps even the implementation of SMF tool / svc.startd > communication exposed. Alan asked for one thing (which I think we need), but perhaps needs something else? I agree. NWAM is either in control of these services, or it isn't -- if it isn't then it needs what Alan asked for. But if there's no reason for NWAM not to be the restarter for these services, and if there's significant benefit to having it be the restarter, then that may well be the better answer. > > Also, I think that limiting event consumers to restarters, and further > > limiting them to learn only about the state of their spawn, is just > > too... limiting. Why constrain these interfaces so? Or did you mean > > something else? > > If you know of a case where it would be useful for a non-restarter > component to observe events other than the state, then please file an > RFE. Sure. GUI interfaces to SMF that keep a near real-time dashboard up to date, for example. I'm certain too that system integrators will appreciate such an interface too, though there's a lot that SMF can do to lessen their need (e.g., a networked SMF protocol, monitor methods, ...). But then, a networked SMF protocol too would have to provide a way to subscribe to and report events. And, as long as we push towards modelling things like NWAM network profiles as SMF services, an SMF event interface can double as (or provide the underlying implementation of) a source of events for daemons like nscd, smbd, idmapd, in.iked, ... Nico --
