Quoth Bill Edwards - Sun BOS Software on Tue, Apr 18, 2006 at 05:37:54PM -0400:
> I will attempt to fix this by....
>
> o Returning better status codes in my start and stop functions;
> in particular, returning SMF_EXIT_ERR_FATAL when errors that
> prevent the service from running successfully are enountered.
> I'm assuming this will prevent the restarter from repeatedly
> trying to restart my service if it won't run.
Yes. For _FATAL, svc.startd will immediately put the service into the
maintenance state, and will leave it alone.
> o Restructure my start and stop functions, and my standalone
> start command to work through the SMF restarter for S10.
> That is, the standalone start command will call svcadm enable
> to do the actual start. This should make sure there is
> a restarter contract in place.
Right. We've done that for a few well-known init scripts, like sendmail
and nscd.
> o Completely preventing the looping is still problematic, but
> I'll see if I can detect losing track of the process in my
> own service code. In the case I just outlined above, both
> the start and stop function would still return success status
> in this case, so looping might still happen. This last point
> is the reason I asked about controlling the contract group;
> so I could kill all the processes in the contract group for
> a standalone stop command. That way, if I lost track of the
> service process, I could still kill it off and prevent the
> SMF loop.
If your start method discovers that the service is already running, it
should return an error. If you only need to signal the service's
processes for the stop method, then it would be best to use ":kill" --
see smf_method(5). If you need to send a signal and do something else,
then you can request that svc.startd supply the contract ID of the
service to the stop script by including "%{restarter/contract}" in the
stop method's exec string. pkill can kill a contract with -c.
David
