Subject: Re: The new rc.d stuff...
To: Greywolf <greywolf@starwolf.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: current-users
Date: 03/28/2000 16:50:58
    Date:        Mon, 27 Mar 2000 23:33:33 -0800 (PST)
    From:        Greywolf <greywolf@starwolf.com>
    Message-ID:  <Pine.NEB.4.21.0003272327220.12707-100000@starwolf.com>

  | I sure hope that "/usr/pkg" is not hard-coded in (HINT!).

One might assume that these scripts are built (using sed, m4, ...) from
a master script which has LOCAL_PREFIX in it, and then the generated
form is the one that is installed (so you would get whatever is appropriate
for you).   That has little or nothing to do with any real issue here.


  | #      Why don't these daemons create /var/run/*.pid files?
  | Indeed.
  | Folks, if we HAVE to do this, let's do it correctly?

This has nothing whatever to do with rc.d related stuff - the startup
scripts have to cope with the code as it is written - if atalkd doesn't
create a pid file (and particularly if it backgrounds itself, so it
the startup script can't use the $! hack and make the pid file for itself)
then there's nothing that can be done about.   Sure, fix the process,
but that's a 100% orthoganal issue.

  | AND:  What ever happened to 'ps axc | grep ...' so you don't have to
  | grep -v the grep?

I think there was a reply here to an earlier message in the sequence.
I doubt anyone was deliberately regressing in time.


And now, just to avoid this being a total noise message - I have two
issues with rc.d as it exists now.

First, relatively minor, I'm using this stuff now in the IETF terminal
room (well, right now in a meeting room) - when I started all this I
found that the dhclient script turns out to be one of the last that
rcorder picks to run.   That's weird - dhclient assigns the hostname
and the addresses for the box, lots of other stuff shouldn't be being
started until after dhcp has completed.

Of course, in a sense, that's just a trivial issue of a bug in the
dependancy lists, and should be easy to fix.

The second issue came from when I started wanting to fix it for myself.
I started looking at the dependancies, and finding that lots of stuff
needed to be fiddled .. for me.   Even worse perhaps, some of the stuff
really needs to be dynamically fiddled - which order I want to run things
in can't be statically defined, and certainly can't be statically defined
by a NetBSD distribution.

Of course, rc.d makes almost all of this easier than it was before.
I used to regularly edit rc (yes, I am one for which even the order
that things were started was never right) - being separate stand alone
scripts, and especially given that they explicitly state their dependencies
it is much easier to be confident in rearranging things without breaking
anything too badly.   However, it is rather less transparent, and it
can take quite a lot of imagination to construct the ordering in your
head to get the sequence that is needed.

The ordering problem isn't new of course - we have had endless debates
before about which order various things should be done in rc (especially
in the early part of the startup sequence - when should filesystems be
mounted compared whith when the network is started...).

If we could have some kind of dynamic dependencies (conditional dependencies
really I suppose I mean) a lot of this would be much easier - critical
filesystems depends upon net if /usr is nfs mounted (etc).  The condition
needs to be a command to be run and return true/false of course.

And last, this has convinced me totally that rc.conf must die (for all
purposes).   Enabling/disabling of scripts needs to be done either by
linking them into the magic directory from someplace else, or by using
the 'x' (or 't' or who cares) bit in the permissions - something that
can trivially be done by one of these scripts (so I can write a script
that looks and sees whether for this particular boot I need to run some
other script or not, and enable/disable others as appropriate ... eg if
I am mobile, and not connected, and running on batteries, then I will
probably want to start a lot less daemons, as the daemons consume mem,
and more mem consumed means more swapping, which means more disc use,
which means less battery life).   Even the options might need to be
modified dynamically - so perhaps the options need to be in a file per
process to be started (not one per script, a script might start several
related processes).

kre