Le 17 f?vr. 08 ? 21:16, Peter Tribble a ?crit : > On Feb 17, 2008 8:04 PM, Nicolas Dorfsman <ndo at unikservice.com> wrote: >> >> Le 17 f?vr. 08 ? 20:10, Peter Tribble a ?crit : >> >>> >> Well, the concept is to have something you can trust in. >> How could you trust SMF if it decides by itself to ignore a bad >> stop ? > > The user expectation here, I believe, is that the service should be > started. At least, that's what the users are telling me. (Telling me > rather strongly, at that.)
Well. SMF isn't guilty here. Tomcat restarter method is. >>> In terms of availability, this is the wrong way round, as it has >>> taken crucial services offline for us (and without any indication to >>> the user). >> >> Without indication ? Is the maintenance state not an indication ? > > Only if the user looks. It's about trust - my users are starting to > not > trust smf to do the right thing as a result. Hum. So your user tell smf to start Tomcat, and then don't check anything. As many users ! ;-) The question is, where is the lack of trust...I mean does your user compare this behavior to anything else ? SMF is clear about its model...svcs start (or restart) is not enough to be sure a service is up. On the other hand, "svcs -x" is sufficient to know that everything is ok on a machine. Isn't that great ? The issue is...you have to type more than one line to start...and check. svcs start/restart svcs -x You're right then, we nees some "svcs -i start" which ask SMF to start the service, and then wait for the next status, and if the service falls down to maintenance state display the log to the user. Before anyone writes that, I think you may inform your user about "svcs -x" and explain them that this simple command check for Tomcat, and Apache, and their SGBD, and for ZFS status, etc, etc. In one word, if svcs -x is ok, everything is ok. >>> Why doesn't it try to start the service back up even if the stop >>> fails? >> >> Any service in maintenance state must be cleared (svcs clear) before >> accept any other action. > > Is a service normally placed in maintenance in the case that a normal > disable fails in the same way? Huh, not sure. Check man smf_method . > (Do you need a clear - normally the users do disable/enable > rather than clear.) I did that before. These are the two first subcommand we learn. Since I worked a litle bit more with SMF, I do use "clear". >>> Or is there some other way of telling it that it's OK if the stop >>> method failed? >> >> Do you really want to do that ? > > Yep. I want the service started. That's the state it's meant to be in. > > And normally, if you disable a service and you get the same error > on the way down, then the service isn't placed into maintenance. > The restart case doesn't behave the same way as disable + enable. Again...what the service log is saying about ? >>> (The application is tomcat, which doesn't always shut down >>> when you ask it to nicely.) >> >> I guess smf specialist on this list may provide you a best howto. >> Anyway, the easiest is to modify the stop method...forcing it to be >> happy in any circumstance. > > I'm really wanting to avoid having to replicate all the functionality > of SMF in my method scripts, and to have to consider in advance > every possible failure mode when SMF ought to be able to handle > it all for me. Check the service log, and the Tomcat method...solution is on this path. Nicolas
