(Moving to smf-discuss at opensolaris.org. We've been having a split internal/external discussion... I've tried to include the context at the bottom, but apologies for confusion.)
Kedar Mhaswade writes: > Thank you for your response. Sorry I missed it earlier. > > But I think this does not work for me. The start and stop > methods call my start and stop commands that can not change. > The start and stop commands I have, predate SMF. In other > words, I cannot change the semantics of stop command that > I define in stop method. It always exited with a non-zero > status when it found that the process it is trying to > stop has already stopped (anyhow). > > I guess the only solution I have is to write a script around > my stop command and ignore its exit status and use this > script in the stop method. > > Is there a way in which I can ask SMF not to worry about > the exit status of stop method and continue over to the > start method? Yes, you can use a shell script which does the appropriate thing for your service. liane >>Liane Praza wrote: >>>>Kedar Mhaswade wrote: >>>>>David Powell wrote: >>>>>I think I did not do a good job of explaining my dilemma. >>>>>I figured from your explanation and removing "restart" method >>>>>that "restart" method is not used at all. >>>>> >>>>>So, I removed it. Now, here are two situations, that I don't >>>>>know how to deal with. >>>>> >>>>>1- Manifest has a "start" method and a "stop" method. >>>>> >>>>> This works great with "svcadm enable" and "svcadm >>>>> disable", it also helps me bringing up the service >>>>> on system restart. >>>>> Where this fails is when the started server process gets >>>>> a SIGQUIT/SIGSEGV etc. In that case, SMF >>>>> attempts to call "stop" method and since that fails, >>>>> the process is NOT restarted. Note that my stop >>>>> method is "robust". In fact, that's the only way for >>>>> an administrator to gracefully stop my server process. >>>>> But the underlying processes themselves don't start >>>>> gracefully at times because of many factors. I simulated >>>>> that using "kill -9 pid". >>>>> >>>>> This is causing a trouble for me because I was under >>>>> the impression that SMF watchdogs my processes. >>>>> >>>>> Why does SMF call "stop" method when it figures >>>>> out that service processes are killed? >>> >>> >>>Because it doesn't know if there's other cleanup that needs to be done. >>>It can't. If your service method is failing in an expected condition, >>>it *isn't* robust. Make it not fail if your service processes are dead. >>> >>>(Imagine the scenario when only *one* of your processes have died, but >>>the service is comprised of multiple processes. SMF would always need >>>to call the stop method then.) >> >>>>>2- Manifest only has a "start" method. >>>>> [First of all, manpage is confusing for "svc.startd" because >>>>> it says "stop" method is required. I don't think it is. >>>>> I created a manifest with only "start" method and imported >>>>> it into SMF without any problem.] >>> >>> >>>It's required but not validated at this time. If you want to have no >>>stop method, define it as ":true". >>> >>> >>> >>>>> This works great with "svcadm enable" and system reboot, >>>>> but fails with "svcadm disable" obviously because disabling >>>>> the service does not find the "stop" method and only changes >>>>> the visible "state" of the service as shown by svcs command. >>>>> >>>>> Thus, whereas this watchdogs my process, does not help me if >>>>> I want to gracefully shut the service down. >>>>> >>>>>So, if SMF wouldn't be calling "stop" method on finding out >>>>>that the service or processes thereof have been terminated, >>>>>then that would have served my purpose. >>>>> >>>>>Shouldn't "stop" be called only on "svcadm disable service-name"? >>> >>> >>>No. SMF behaves as it is documented -- stop is called whenever there's >>>a service failure, a dependency goes offline, or when the service is >>>disabled. >>> >>>The precise scenarios in which a stop method is called are documented >>>here >>> http://www.sun.com/bigadmin/content/selfheal/sdev_intro.html >>> >>> - Stop methods are run in a number of different scenarios, including if >>> a dependency has gone offline, if your service fails, and if an >>> administrator requests disable or restart. >>> >>> - Thus, stop methods should return success if the service is no longer >>> running after execution is complete, even if the service wasn't >>> running when the execution started. This is because stop methods may >>> be called in error scenarios. >>> >>>and in the svc.startd manpage: >>> >>> Stop the service. In some cases, the stop method can be >>> invoked when some or all of the service has already been >>> stopped. Only return an error if the service is not >>> entirely stopped on method return. -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
