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. > 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. 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
