Nicolas Williams wrote: > On Wed, Nov 14, 2007 at 07:29:40AM -0800, Liane Praza wrote: >> 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. > > The pre-SMF /etc/init.d/sshd script starts sshd in the background, so > "/etc/init.d/sshd start" is actually asynchronous. The stop operation > of init.d scripts usually use kill(1) and don't wait for the process(es) > to exit, so those are usually asynchronous. > > I think we could say that the init.d scripts, pre-SMF, varied w.r.t. > whether they are synchronous, and for what operations.
Sure. But, the *framework* (if you can call a set of conventions a 'framework' here) acted synchronously to the provided service invocation. That's the main point of control SMF has, and it seems sensible to preserve that behaviour here. (Seems like we're in agreement, though, so I won't belabour the point further.) > > In any case, IMO, svcadm start/stop should be: a) non-persistent That's in Mark's proposal. (but > with a warning about the non-persistence telling the user to use > enable/disable for persistent behaviour), Should ssh tell me every time I use it that maybe I wanted -X too? Really.. think about a system that does this -- emits warning messages with nearly every command you type that maybe you want different behaviour. It seems we'd all go insane for all the noise. And we'd be significantly less likely to notice *actual* errors because output was expected in the non-error case. If a command needs to emit a warning message on proper usage, that command probably shouldn't exist. (Explicitly requested verbose output is, of course, a different story.) (This assertion will probably cause some heated discussion. But, warning messages appearing during as-designed behaviour which happen *every invocation* would be a departure from current design patterns. It certainly isn't a course SMF should pursue on its own. I'm also sure that with the passionate disagreemnts will come counterexamples -- it's software, so there are always counterexamples. If you want to flame me (err, have a civil discussion :) ) about this design pattern, please start a new thread rather than hijacking this one which contains Mark's well-considered proposal.) b) synchronous. That's also in Mark's proposal. > > And, also IMO, enable/disable need to have a flag to affect only the > state on next boot. That's a separate RFE, but is already filed. I concur, but don't think it's fair to tell Mark he has to fix them at the same time -- they're separable, and Mark can fix what he wants. liane
