Mark Martin wrote: > On Nov 16, 2007 5:16 PM, Darren Reed <Darren.Reed at sun.com > <mailto:Darren.Reed at sun.com>> wrote: > > Nicolas Williams wrote: > > >On Fri, Nov 16, 2007 at 03:10:26PM -0800, Darren Reed wrote: > > > > > >>To add to Rainer's point, something that I see missing from > >>"enable -st" is the ability to start without all of the dependencies > >>already being "online". > >> > >> > > > >Should "start -r" mean "enable dependencies recursively" or "start > >dependencies recursively"? > > > > > > No! > > Why? > > Because maybe a service that is listed as a depedency has > failed (or cannot start or is in maintenance or whatever) > and what the administrator wants to do is start a very specific > service for whatever reason. > > To expand upon my prior email... > > For example, if nis/client has failed and name-services hasn't > been met, then doing "svcadm start inetd" will NOT get me > the result I want because the "-r" will likely crumble when it > goes back to nis/client. > > > Ok, it sounds like you're looking for a "start -i" or "enable -i" > (-i)gnore... > > Firstly, it occurs to me that how likely is it that you'll be only > transiently enabling a service with lots of dependencies. Even if you > are, can you wholesale ignore them if they exist? Again, sounds like > you're looking for an -i flag.
No, I'm looking for "-i" not to be an option and for it to be the default behaviour. > By default, start won't execute unless there are no unsatisfied > dependencies. start -r will attempt to also start the dependencies > (which I'm pretty sure is the enable -rst behaviour now -- if I'm > wrong, it'll be what enable -srt currently does). > > Initially, I was looking at this as just a bug fix, and it seemed like > low-hanging fruit because it looked like simply an alias. During the > last 2 weeks, as many have offered discussion on it, it has become > obvious that there are many impressions and connotations about what it > means to simply "start" a service ( i.e. enable only until next > reboot). It seems to me that notionally term is a holdover from > init.d rc script days, and as such, there was little in the way of > dependency marking except by way of ordering the scripts by name. You > still had the ability to start a script independently, which is what I > think you're angling towards here, right? In that case, yet again, I > think you're looking for a -i flag which I believe mimics most closely > the old notation's behavior. At best, I'd say maybe that's a useful > option, but it should still be an option. I think what you're missing is that the way in which SMF works is a serious departure from the way systems administrators have interacted with "services" on Un*x previously. At one point in time we had /etc/rc, /etc/rc.local and init scripts as being the way in which Un*xen started things up. Linux has advanced the init style, sort of, with chkconfig but the individual init scripts are still accessible. BSD has moved forward with a system that recognises dependencies for booting but otherwise supports direct access to init scripts for starting services. Windows allows enable/disable of services to be managed seperately from start/stop (although you can't start something that is disabled and has no backdoor access.) Solaris has placed svcadm in front of us and told us that we're not allowed to use the back end scripts. It's like they've cut off our hands and given us prosthetic limbs and told us they'll be sufficient, as all we need to do is get food from the plate to our mouth, right? There's an interesting intersection here for you to navigate. On the one hand, you've got the people who will potentially be using the "start" saying you're not going to deliver what they need to and on the other you've got the implementors/designers of SMF who seem somewhat supportive. Darren
