Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Nov 1998 16:06:54 -0500 (EST)
From:      spork <spork@super-g.com>
To:        Nik Clayton <nik@nothing-going-on.demon.co.uk>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: /etc/rc.d, and changes to /etc/rc?
Message-ID:  <Pine.BSF.4.00.9811241602350.15526-100000@super-g.inch.com>
In-Reply-To: <19981118211919.10512@nothing-going-on.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Personally (and I'm biased since I just started kicking around my Sparc2),
I think there are some serious gains here for people new to FBSD, and some
major conveniences for wizened users.  I would have killed for ./nfsd.sh
top/start this past week.  There seem to be more and more people using
databases and some of them (mysql for one) don't like the way they are
currently shutdown.  If rather than killing the daemon we could call
'mysqladmin shutdown', that would be swell.  

Since you're going through rc.conf for options you could even have
something along the lines of 'ed0 restart/stop/start', which could be
handy.

A nice advantage of this is if you get in the habit of configuring things
in one config file and testing your changes from there rather than on the
fly is that you end up with a more organized and stable system.

And it's not too SysV, as they don't yet have a central config file.  This
is better.

$.02,

Charles

---
Charles Sprickman
spork@super-g.com
--- 
                     "...there's no idea that's so good you can't 
                      ruin it with a few well-placed idiots." 

On Wed, 18 Nov 1998, Nik Clayton wrote:

> On Tue, Nov 17, 1998 at 09:01:38PM +0000, Nik Clayton wrote:
> > If there are no more comments by Thursday I'll take it as tacit agreement,
> > and go ahead. I'll do sendmail first.
> 
> Well, that's certainly one way to kick off a discussion.
> 
> Attached is a quick implementation of what I've been talking about. All
> it does is provide startup scripts for inetd and an NFS server. This is 
> a minimal implementation, provided for people to kick around.
> 
> To use these;
> 
>  1. mkdir /etc/rc.d
> 
>  2. Copy inetd.sh and nfs_server.sh (attached) to this directory. Make
>     them executable.
> 
>  3. Edit /etc/rc and change the line that starts inetd to
> 
>         /etc/rc.d/inet.sh start
> 
>     (keep it wrapped in the test for ${inetd_enable} though)
> 
>  4. Edit /etc/rc.network. Find the block that tests for ${nfs_server_enable}
>     and replace the contents of the block with
> 
>         /etc/rc.d/nfs_server.sh start
> 
> You can then start playing around. 
> 
> inetd.sh is how I expect most of these scripts to look. There's only one
> daemon to start, which makes the surrounding code look somewhat extraneous
> for all it's got to do.
> 
> Hopefully, nfs_server.sh makes my point a little more clearly. As you can
> see there are a number of daemons that need to be started and/or stopped for
> NFS serving. 
> 
> Suppose you've changed the NFS server flags in /etc/rc.conf, and want to
> test that they work. 
> 
> Currently, you would do this by;
> 
>   - Reading /etc/rc.network to determine what daemons have been started.
> 
>   - Kill them. In some cases killall or kill will be sufficient. In others
>     you need to stop programs in a specific order -- for these programs
>     you have to make sure you know what that order is.
> 
>   - Restart them. Either by typing/cutting-pasting the commands from
>     /etc/rc.network, plugging in the same values as you have put in 
>     /etc/rc.conf. Or by crafting together a small shell script to pull
>     in the values from /etc/rc.conf and starting the daemons in this 
>     script.
> 
>   - Even now, you're not 100% guaranteed that what you've just done 
>     mirrors what will be run the next time the system boots.
> 
> With this (new) approach, you just
> 
>     # /etc/rc.d/nfs_server restart
> 
> and watch as it kills the daemons, and restarts them with whatever 
> values you currently have in /etc/rc.conf. It does it consistently,
> correctly, and will happen the same way when the system boots.
> 
> To answer some of the points raised by other people;
> 
> Yes, this will make booting slower, and push up the PID of the first
> login process run. So what? The slow down is imperceptible, and I would
> expect it to be on the order of 3 or 4 seconds maximum if this approach
> is fully adopted (and even then your disks would need to be pretty slow
> for it to be that drastic). You waste more time than that checking that 
> you've killed all the daemons and restarted them properly, so over time 
> it's probably a net win.
> 
> Yes, it's different from how things have been done before. So what? 
> It's not change for change's sake, it brings the benefits I've outlined
> above and in earlier messages which (IMHO) make the change worthwhile.
> 
> Yes, it will confuse old-hand BSD administrators. So did the introduction
> of /etc/rc.conf (nee' /etc/sysconfig). Perhaps confuse is the wrong 
> word. It might disorient them slightly, but only briefly. All that's
> happened is that the content of some of the /rc/rc.* files has been
> moved out into other files in another directory. init hasn't changed,
> the order hasn't changed, the mechanism for deciding what order to run
> things in hasn't changed.
> 
> N
> -- 
> 	    C.R.F. Consulting -- we're run to make me richer. . .
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.00.9811241602350.15526-100000>