A few responses in one. Apologies. I'm just responding to Mike directly because I think in lists too. ;)
Mike Shapiro wrote: > On Sun, Oct 28, 2007 at 12:47:43PM -0500, Mark Martin wrote: >> Gang, >> >> I'm looking at RFE/bug -- 6182530: svcadm alias "enable -t" as start and >> "disable -t" as stop >> (found here http://bugs.opensolaris.org/view_bug.do?bug_id=6182530 ). >> >> I'd like to invite opinions. >> >> With the integration of 5100812, I believe we're down to the following >> features described in the RFE. >> 1) Provide an alias for enable -(s)t and disable -(s)t >> 2) Clear up any documentation indicating that -t enabled/disabled services >> revert to previous states. >> ... > > I'm sure there will no shortage of contradictory opinions :) > But here's mine, based on observing how customers have used this > stuff since we introduced it and what I think we got wrong: I'd like to make sure we think about the goal of this work. Mark, hopefully you'll think about your goals too. :) (And I'll note that a potential outcome is for you to decide that the bug should be closed as will not fix/not a bug. Someone could open it again, but... you're within your rights as the primary evaluator to decide that the goals of the RFE aren't reasonable or well considered.) My impression of the goal of this RFE is to match common administrator expectations about a "start" action. It isn't to write a better "enable". Because "start" exists historically, and seems to match an administrative action that is at least somewhat common (especially with respect to other service startup frameworks, and UNIX history), I'd expect that we wouldn't try to translate "start" into a better enable -- largely because it would be surprising. If the goal is a better enable, I'd encourage exploring it with a new verb that doesn't have deep existing connotations for UNIX users. I'll note in response to other mails that the goal of this RFE is not to introduce deferred enable/disable. Nobody has declared it unimportant, but it just isn't the bug Mark has chosen to fix right now. If he wants to, that's his choice, but I don't see any conversation here which suggests that the start/stop aliases either conflict with or must be designed in light of deferred enable/disable. That said, onto the specific points. > (a) Synchronous should have been the default, with proper error reporting. Agree. And agree that synchronous matches the expected behaviour for "start". > (b) Recursive should have been the default, since most people are executing > the command with the *intent* of, yes, making the thing start. So > silently not achieving that and then forcing user to re-execute svcs -x > and then re-running with -r is just annoying. Interesting. Historically, "start" means start *only* this service. In the days of init scripts, if the dependencies weren't satisfied, the service would either fail silently, or spew some errors and fail. The big concern about recursive enable as a default in general is that you may end up with a "surprising" service enabled as a result of a recursive enable. For example, a service could be enabled as part of the recursion that violates your policy for open ports on the system. It'd be interesting to hear other opinions on this particular point. I could easily convinced if people generally found the convenience outweighs the risk. After all, you want the service enabled -- you're probably just going to go do a -r anyways. It may be another argument for chatty output. (To say which new services were enabled recursively.) > (b) Temporary should *not* be the default. This one I believe we got right. > A very common admin mistake is to go turn something on, assume all is > well, and then oops, 3 months later someone reboots the box and you have > this lurking timebomb that the service wasn't permanently enabled. > > I used to see this behavior in the pre-SMF world where someone would > run a daemon by hand, watch it go, then drop an untested init.d script > in place, and forget to actually test the script, and thus upon reboot > months later we'd discover syntax error at line 12. This is part of the > reason why we felt strongly that -t should not be the default. I remember being one of the (the only?) crazies on the initial project team who tried to hold out as long as possible for not supporting a "temporary" option at all. In that crazy role, I sympathize with this argument. However, we've admitted -t, and some feedback seems to suggest that start is expected to act temporarily. I think if we're trying to match the common connotation of start, temporary is appropriate. If we're trying to build the better enable mousetrap, let's call it something else. Jason suggested that whichever way gets decided on this we help warn the administrator about what actually happens. I'm OK with slightly chattier output, but... we limit the audience for the command if every time it's run, it moans at you with a bunch of information you already knew. My response to such commands is usually to mutter at the screen: "yes. of course you're doing that. it's exactly what i asked you to do. why are you echoing my intent back at me?" Help for new users of the system is good, but it needs to not amount to reading paragraphs/sentences of the manpage at you as a result of running a (non -h) command. Maybe just improving the usage message of svcadm so it's less terse would be a reasonable compromise. I'd consider printing a message when you're making the system fragile if an unexpected reboot occurs. > So my opinion is this: > > - keep svcadm enable as is for compatibility > - make svcadm start the same as enable -r -s > - make svcadm start -t mean svcadm enable -r -s -t, > i.e. force the user to express the less-common case of temporary enable > - make svcadm stop the same as disable -s (not recursive, not temporary) I'm pretty much onboard for everything except making "start" permanent by default. I'd consider declaring start/stop to mean -v as well. (At least declaring a slightly more verbose on some success cases an intent.) liane
