Hi Stephen, See below...
Stephen Hahn wrote: > * Michael Goff <michael.goff at sun.com> [2007-03-16 18:18]: >> I'd like to be able to tell when my monitored service is restarted as a >> result of its process dying vs. started normally upon boot. I've done >> some tracing, and it seems that the start/stop methods are called with >> the same SMF_FMRI, SMF_METHOD, and SMF_RESTARTER settings in either >> case. The %r %m %s %i %f parameter values are also the same. > > When you say "I", do you mean you as a human operator, you as an > administrative tool, or you as any subsequent invocation of the > service? "I" means subsequent invocation of the start/stop methods. For example, I want start to behave differently for the fault-induced restart case versus starting cleanly after boot. This is actually a continuation of a thread I had with Liane last year: https://opensolaris.org/jive/thread.jspa?messageID=31269稥 Since SMF still doesn't support fail-once semantics, I'm fine-tuning the workarounds in the methods of our unique service. >> Is there anything else I can check? The only evidence I see of a fault >> is in the log for that service: >> >> [ Mar 17 00:23:27 Stopping because process received fatal signal from >> outside the service. ] >> >> but I really don't want to have to log scrape or keep state files. > > I believe we'll need either to determine how to integrate these events > with FMA, or introduce some additional interface, depending on the set > of information and circumstances involved. So you mean creating a fault event that the methods can check? I think that some kind of SMF interface to the context in which the methods are being called would be useful. The current SMF environment passed to the methods: SMF_FMRI: svc:/application/honeycomb-test:default SMF_METHOD: /opt/honeycomb/bin/testsvc start SMF_RESTARTER: svc:/system/svc/restarter:default Could be extended with something like: SMF_CONTEXT: [start | stop | fault_restart | fault_stop] to convey the state that I'm looking for, which SMF already logs. thanks, Mike
