On Wed, 15 Mar 2000, der Mouse wrote:

> > Nice things about the scripts in /etc/rc.d is that dealing with
> > individual daemons/services is much more easier.  They do all the
> > work you would have to do (e.g. ps ax | grep myproc; kill it; start
> > with appropriate flags), plus they manage dependencies.
> 
> They..may try.  They will get it wrong too often.
> 
> ps ax | grep myproc is *not* suitable for automated use.  When human
> intelligence is applied to the output before it's fed into kill, it's
> fine.  Without that, it's an invitation to disaster.  (Which of those
> pppd processes is the one I want to kill?  Or both?  And what about my
> watch-pppd script, why did it kill that?)
> 
	I agree here - it should only target processes whos final
	pathname component exactly matches the specified string.
	(that avoids the watch-pppd issue). I haven't checked that is
	does (offline right now).

	As for which pppd it kills - all of them as it is shutting down
	pppd as the system is going down. If that is not what you want,
	then you do not manually run '/etc/rc.d/pppd stop'.

> > It provides you with much more flexible way to define what depends on
> > what, way to define subsytems so that when you kill a service, all
> > services depending on it are killed, too.
> 
> ...assuming that's what I want, rather than to kill it, move the new
> config into place, and bring it back up, letting the dependent services
> retry a time or two rather than restrting them too.
> 
> And if shutting down Foo shuts down everything currently running which
> depends on Foo, where does it record what those are so that when I
> restart Foo a moment later they're brought back up?
> 
	If the ordering is not what you want in the case of a system not
	shutting down, you do not manually run the 'xxx stop' script.

	If you just want traditional 'init kills the world, shutdown
	behaviour, you ensure rc.shutdown does not call the stop scripts.

> > Or if you start a service which needs other services to run, they are
> > also started.  Very nice.
> 
> ...for turnkey production systems.
> 
> A disaster when, say, I'm trying to run an experimental replacement for
> one of those services and the start script notices the stock one isn't
> running and tries to start it, not able to tell that my replacement is
> running instead.
> 
	The start script is only going to be run when you bring the system
	up, or when _you_ manually decide to run it. In the former case you
	need to tweak the script, but you would have needed to do that with
	a monlithic rc script anyway?

> Remember what I said about the OS-hacker niche?  Guess what perspective
> this message is being written from. :-)

	There are three areas of behaviour I see affected:
	(Note I'm not addressing configuration at this point, to
	try to simplify this section :)

	a) Manual start/stop of individual services:
	   This is what some of us really like. If you know what
	   it does, and are happy with the action, you use it. If
	   not, you don't.

	b) Shutdown:
	   Currently init just kills things. Giving subsystems the
	   option to cleanup in their own way (database shutdown)
	   and shutting things down _in the right order_ seems like
	   a very good thing.  Particularly if the rc system can
	   run them in parallel to speed things up. If someone is
	   really adverse to this, they can throw some comments in
	   rc.shutdown.

	I do not see the above two as issues (please correct me if
	I'm wrong :)

	c) Startup
	   If you wanted something run at a particular point, you
	   added it to the appropriate place in rc.local (or
	   netstart.local, or rc, or netstart). In the new world
	   order you would add a comment to the top of a script if
	   it needs to happen after something else and drop it in
	   the rc.d directory. If you want to take advantage of
	   all the rc.subr help you can, but you do not have to.
	   --or-- you convert the entire rc.d into an old style
	   rc, and tweak to taste. I agree, not as convenient for
	   you as the old system, but it allows a lot of us to
	   get some of the new features we want.

	I can understand this would be less than ideal for some people,
	but we're looking for a solution that fits two conflicting goals.
	- monolithic rc, vs individual start/stop scripts.
	
On Wed, 15 Mar 2000, der Mouse wrote:

> Recently (= approximately this past year), it seems, someone has
> decided that a larger user base is a sufficiently good thing to be
> worth dropping the niche people for, and this has resulted in things
> like the package system and /etc/rc.d, things designed to make life
> easy for the "I don't know computers and don't want to have to" crowd,
> the people whose idea of complicated system administration is having to
> actually type pkg_add at a shell prompt instead of clicking in a GUI.
 
	I'm no guru, but I know my sysadmin-way around NetBSD pretty well,
	and am reasonably familiar with the SysV startup mush on IRIX and
	Solaris (exceeded by the nightmare which is redhat rc.d)

	"I know computers, and I'm very happy doing so, I just want
	the computer to be able to do more repetitive things, so
	I can get on with other work". 

	On my NetBSD systems I install skill. I have no difficulty
	in finding paths and process IDs without it, but I'd rather
	spend my cycles fixing a problem, than mechanically typing
	extra mush, particularly over a sluggish link

	If I had and /etc/rc.d/sendmail, I'd use it when it would
	prove useful to me.

> Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec".  The
> rc.d scheme, as I understand it, has the same basic problems that real
> SysV startup scripts do: they make human understanding and manipulation
> of the startup sequence significantly harder, for the sake of making
> mechanical ditto easier.
> 
	It makes individual process startup easier to understand
	(they all happen the same way), and the dependencies between
	them explicit (rather than just a sequential list, which while
	easier to understand, implies a while bunch of dependencies
	that are just not needed).

	That ordering could be made easir to see by having an
	'rcorder -v' which would list the order and dependencies in
	a clear 'for human consumption' fashion.

> Will there *be* rc.conf and rc.local?  I saw "rc.conf must die" and
> discussion of /etc/rc.d.local/ vs /etc/rc.local.d/, which means either
> there won't be any rc.conf and rc.local, or the new scheme is being
> grossly misrepresented.
> 
	I would also be unhappy if rc.conf or the option to have
	an rc.local was taken away. I should really check but the
	only spare time I have right now is sitting on a train, and
	my rather aged laptop is out of disk right now :(

> > If you run the script that converts evrything into one large rc file
> > and leave it that way, how has it screwed you?
> 
> Quite possibly it hasn't.  Frank said monolithic rc was gone and
> wouldn't be back; I jumped to the (not unreasonable, I think)
> conclusion that it was so.  Now it appears it might not be.  I'll
> probably set up a crash-&-burn machine and try bringing it up to
> -current sometime soon, see how alien the new system feels when I do
> ask it for a single startup script.

	It has to be somewhat alien, but maybe with some changes to the
	way things are generated we can find something that will satisfy
	(if not please) everyone...

		David/absolute