Rainer Heilke wrote: > Peter Tribble wrote: >> On Nov 14, 2007 8:43 AM, Jordan Brown (Sun) >> <opensolaris at jordan.maileater.net> wrote: >>> Rainer Heilke wrote: >>>> This, I believe, would be the behaviour expected by admins. >>> Do note that one of the goals of SMF (at least as I perceive it from >>> outside the SMF group) is to change how people do system administration. >>> As a result, expected behavior may or may not be important. Behavior >>> has to be *sensible*, but I'd say it's OK to be different if the result >>> is by some reasonable metric better. The goal is *not* to just put >>> different words around the same old init scripts. >> Which is one reason for using enable/disable rather than start/stop. >> At least then it's clear that it's a different operation. If we do have >> start/stop, then the traditional expectations of start/stop should apply. >> (And if start/stop actually do something different, then they're broken.) >> > > Peter and I are saying essentially the same thing; we're just attacking > the problem from two different angles.
Maybe I missed a mail in the middle (apologies if I did), but I'm a bit confused by what precisely about Mark's current proposal you think doesn't match traditional expectations (i.e. init/rc-based) of start/stop? The only concrete complaint I've seen about Mark's updated proposal in the "doesn't match expectations" vein is from Peter about including current -s behaviour. Current enable -s behaviour is in line with how init scripts used to behave -- it makes the action synchronous with respect to the caller. running "init.d/foo start" was also synchronous with respect to the caller. It seems to meet traditional expectations closely enough to be useful. liane
