Sorry for following up to my own mail. Need more caffeine. Liane Praza writes: > James Carlson writes: > > Alan Maguire writes: > > > i've been working on spec'ing out the delegated restarter > > > behaviour for the Network Auto-Magic project, and one thing > > > i was thinking is it'd be nice to be able to add to the reasons > > > that "svcs -xv" displays - from what i can tell they're > > > hard-coded in svcs/explain.c. is there a way to augment these > > > so a delegated restarter can provide an additonal reason? > > Sort of. A reasonable extension of the existing hard-coded > implementation was scoped as an inetd project, but has been > back-burnered in favor of speeding up initial manifest-import, and > making manifest-import run earlier in boot. > > Today, the aux state is set by restarter_set_states() function in > librestart.h. That aux state is then consumed in a hard-coded > fashion by svcs -x.
(You, of course, had already noticed this, Alan.) > > Why would this be a delegated-restarter-only feature? Unless I'm > > missing something, this would be a very nice thing to have for > > ordinary services. > > In the long term, it shouldn't. However, the tricky part is figuring > out who has the most authoritative description of why a service is in a > certain state: the graph engine, the restarter, or the service itself. > Tied up in that is when a "reason" for each potential provider is reset. > (Today, it's on *every* state change.) > > The second problem is internationalization. The producer of the > free-form text doesn't know what locale the consumer will be running > in. Thus, today the implementation is of a pseudo-human readable > key which is then translated by svcs -x. We also want to make sure > that third party management software can do something useful here. > > The third problem is the fact that we use the FMA msgids for > diagnosis. Stuff bundled with opensolaris can easily add to those, > but we'd need a coherent solution for unbundled software. > > There's probably a resaonable medium-term approach in extending the > existing dance between restarter_set_states() and svcs -x to look > up in a set of restarter-provided tables. Which are provided in the restarter's service manifest, preferably. I don't mean to suggest we create a new filesystem location for these 'tables'. > However, first you'd > want to start with the analysis of svcs -x's usage of aux state to > see if it is even consuming that extra data at a point that > would be reasonable for your restarter. Alan, I'd be happy to set up > some time to talk through this with you, if you'd like. > > > One trick I've seen used in other operating systems is to format the > > field such that it contains a stable identifier plus some application > > supplied (and probably i18n'd) text, something like this: > > > > Cause: SMF-REASON-12345 Network cable on bge0 is unplugged > > (An FMA tie-in is most appropriate. Our diagnoses are all tied > to FMA msgids today so that we can link to appropriate sun.com/msg > pages.) liane
