Hi Tony, basically I have a service that could get disabled whenever stop method is called (either expected or unexpected shutdown). Usually there is another service on the system or on different system (usually many services on different systems) that would take over it's functionality. Of course there are better behavior possible, but this one would be simulating the old one, which would be currently sufficient.
If my stop method were to always transition the service always to temporary disable I couldn't use svcadm restart anymore as the service would end up temporary disabled. Probably only clear solution I can see, would be to use libscf in the daemon itself and transition the service to the temporary disable only of certain events and use ":kill" as my stop method. Definitely better behavior, but requires moderate effort. If I could get the reason why is stop method being called, like stopping because of: core signal disable requested restart requested no processes etc I could probably implement the logic in the service methods without the need to change the daemon code and I think I've seen something like "Stopping because restart requested" in the svcs -x output. That's why I was asking if there's way to get the reason for stop method execution. Lubos. Tony Nguyen wrote: > Lubomir Petrik - Sun Microsystems wrote: >> Hi, >> I was wondering if there's way either in script (stop method itself) >> or by using libscf in my code to query the reason why the service is >> calling stop method. >> >> Basically I'd like to react differently based on whether 'svcadm >> restart' or 'svcadm disable' caused the stop method to be called. >> Actually in my case I just want to distinguish restart from other >> reasons of invocating the stop method. >> >> Is there a way? >> > > Probably :^) Can you provide more information on the use case? There > may be a more generic way to do what you want. > > -tony
