Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Sep 1995 11:30:47 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        syssgm@devetir.qld.gov.au (Stephen McKay)
Cc:        patl@asimov.volant.org, syssgm@devetir.qld.gov.au, ports@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject:   Re: ports startup scripts
Message-ID:  <199509211830.LAA09130@phaeton.artisoft.com>
In-Reply-To: <199509211256.WAA17842@orion.devetir.qld.gov.au> from "Stephen McKay" at Sep 21, 95 10:56:53 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> What do we need run levels for?  As far as I can tell, it's never done me
> any good on the System V boxes I've administered.  I want single-user mode
> for serious system munging, and multi-user mode for everything else.  The
> rest is useless crap.  If, say, cron is spinning madly out of control and you
> want it shut off, is there a run level for that?  Nope.  You just kill it
> and restart it when you feel like it.  What if the printer daemon has hung.
> No run level for that either.  It adds no value.

/etc/init.d/cron stop
/etc/init.d/cron start

Or pick "reset" in the administrative utility.

Presumably, the administrative utility would get configuration info and
other tags for the cron script out of a comment section (or use of
environment variables set with a different argument to the script) to
automate adding support for administration by dropping the script in.

> All those fiddly little scripts give me the irrits too.  Half of them run
> 'ps' in a reckless manner on shutdown in a hope-I-got-it-right attempt to
> find the server they want to kill.  Some do that on startup too!

Sounds like badly written scripts.

Luckily, being copyrighted, we will be unable to use them and can write
our own.  8-).

> They are a feeble attempt at enabling and disabling services.  If we want
> that sort of thing, let's build some sort of super-server (like init or inetd)
> to look after them properly (plus some system admin tool to flip them on
> and off, and maybe keep track of dependencies on other servers).  Let's not
> embrace this particular bit of System V.

I know.  We can call the "super-server" 'init' and we can call the gross
control of classes of service 'run levels'.

8-)  8-)  8-).

> and having /etc/rc.ports run from /etc/rc.  If you want a read-only root
> filesystem, symlink /etc to some place writable first, then carry on.  You
> want /etc to be read only?  How do you get anything done?  No one adds users
> or changes passwords?  No alias file updates?  You must have built a custom
> /etc to still be enjoying your life, so add a symlink from /etc/rc.ports to
> /var/some/thing or /usr/local/whatever while you are at it.  You must have
> *SOME* writable directories if you expect ports to load! :-)

Not if you load the ports onto the NFS server and expect all diskless or
dataless clients to be able to use them.

The real bitch is a mixture of preloaded and client specific ports.  I
don't know if that's a reasonable configuration or not.

> Let's keep this as simple as we can.  All these grand schemes for hoards
> of shell scripts called from 'for' loops make me nervous.  Is it safer in
> one of the other BSD camps?  (Only kidding guys!  No rocks!  Oww!) 

The 'for' loops for implementation make me nervous as well.  The init
we are using supports the directory and run level transitions necessary
with a few compilation options (or at least it used to).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509211830.LAA09130>