Rainer Heilke wrote: > Darren Reed wrote: >> FWIW, I agree with this... >> >> What I would expect to happen is: >> >> # svcadm start foo >> # svcs -x foo >> (grumble, foo isn't working) >> (do stuff) >> # svcadm start foo >> >> It may be that the requirement here is for SMF to understand >> that it is ok to be told to move from "maintenance" to "online" >> without first going "offline" as a result of "svcadm start"? >> >> *IF* there is some requirement to go from maintenance to >> offline before going online then this should be built into "start". > > Exactly! Thank you! I didn't express this as succinctly as you did, but > this is precisely what I am getting at. (It would be nice if enable had > the same functionality, perhaps. In that case, start being an alias > isn't completely useless anymore.)
So, you guys also want it to be that this happens: # svcadm start [or enable, as you've requested] database <time passes. database goes totally off the rails and nobody notices. ends up in maintenance, but with some processes still running because we couldn't kill them off.> <another admin, or the same admin comes along, and out of habit types:> # svcadm start database <database eats itself. because it was already half running, and much suffering ensues.> That's the case we originally were concerned about. (Rainer's original example *explicitly* never transitions the service into maintenance *because* we know what's wrong with the service.) (And while we could notice some of these situations and still fail the start, we can't protect against all of them.) Maintenance exists for situations after SMF has given up trying to repair the service because administrative intervention is required. Either there's a bug in the framework, or more likely, the admin needs to do something to fix the service. It is complimentary to FMA in the administrative repair action required design. The system does know something about the state of the service, and is trying to inform you that more is necessary than a simple "svcadm enable" to fix it. svcadm enable breaks down because it doesn't tell you it failed. "svcadm start" as an alias for "svcadm enable -st" will! The message should be improved, though, that's trivial and can be done as part of the 'start' changes. (That's why I want to be very careful about the details of what's being requested, and have been pedantic about asking for them. I think people aren't trying their examples -- they're positing based on other behaviour and missing refinements that will be an improvement.) I know this scenario is common during service or service manifest development. How common is it during non-development scenarios that something ends up in maintenance and only an "svcadm clear; svcadm enable" is required to fix it? (I don't mean the one example one person hit once. I mean repeated cases.) (I should probably stop answering about a proposal that isn't mine soon.) liane
