Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Nov 1998 20:55:29 -0600
From:      Jacques Vidrine <n@nectar.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:  <199811180255.UAA01561@spawn.nectar.com>
In-Reply-To: <19981117235348.41074@nothing-going-on.org> 
References:  <19981115235938.22908@nothing-going-on.org> <19981117210138.03327@nothing-going-on.org> <199811172241.QAA00519@spawn.nectar.com> <19981117235348.41074@nothing-going-on.org>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----

These are good points, so I hope you don't mind me copying them back
to -hackers where my original message was posted.

On 17 November 1998 at 23:53, Nik Clayton <nik@nothing-going-on.demon.co.uk> wrote:
> On Tue, Nov 17, 1998 at 04:41:03PM -0600, Jacques Vidrine wrote:
> > Let's see ... you will be adding complexity.  Please specify
> > the payback.
> 
> 1. When killing system daemons (i.e., inetd, sendmail, named, lpd, and
>    so on) no need to try and find the right PID, playing with ps, grep, 
>    and friends. This is a win when explaining the process to someone 
>    newer to Unix than most members of this list, particularly because
>    the process is the same each time. They don't (yet!) need or want to
>    understand what the script is doing, that can come later. It also
>    makes documentation simpler.

Unless the user is from a System V world, this will be no simpler
than using ``killall''.

> 2. No wondering whether or not there's a lock file lying around that's
>    been forgotten.

Start up scripts in ${PREFIX}/etc/rc.d should take care of this for
ports.  What lock files are you concerned about in the base system?

> 3. Makes updating /etc simpler after a 'make world'. If each script 
>    starts with something like
> 
>        if [ -x /usr/local/etc/rc.d/`basename $0` ]; then
>             exec /usr/local/etc/rc.d/`basename $0` $*
>        fi
> 
>    then you could completely replace sendmail (which would be started
>    from smtp.sh) by creating a /usr/local/etc/rc.d/smtp.sh script. One
>    less thing to worry about.

I don't understand your point here.  If you want to use something other
than sendmail, just set sendmail_enable="NO" in rc.conf.

> 4. Those that like run levels/run states (I'm not one of them) could
>    make their own init and other bits and pieces and make it available
>    as a port.

Who cares?  If they want ``their own init and other bits and pieces,''
there isn't anything to stop them from doing this today.  Maybe I 
again don't get your point.

> This would involve the removal of some knobs from /etc/rc.conf. For 
> example, "named_enable" would remain, but "named_flags" would be part
> of /etc/rc.d/domain.sh (I think naming these scripts after the service
> the daemon provides, rather than the name of the daemon itself, is a
> win -- the same protocol might be implemented by a variety of differently
> named daemons).
>
> This is not strictly necessary of course. There's no reason that
> /etc/rc.d/domain.sh couldn't suck in rc.conf and look for a named_flags
> variable. 
>
> Again, at the moment, I'm only thinking of daemons. I'm not touching
> things like ifconfig commands, or console maps, or anything like that.

I don't see anything broken with the current setup.  I much prefer it
to System V-like model that you are proposing. 

If you really believe in this model, I'd suggest making a ``sysvadmin port''  
that does what you want.  I don't see a lot of users upgrading to
FreeBSD 3.0.1 or what have you and being pleased that they now are lost
because of a gratuitous change.

Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNlI3ITeRhT8JRySpAQF9bwP/Q1Th5HGJUNli/DX01FXVViIoY5Fekkzj
aeSFaDzPglY/0HX8Qc/4nASX6euM0izrVJ7bTFDdFZvW12V2D1AcDW0qt6Y6J+7P
6ChSum8lkRINrvEcC0ByBGOJqIRlx5aQ9XXxNl+pJcaC6QOZZih/oiGdNTMirnBf
2yderajQC2U=
=vKFm
-----END PGP SIGNATURE-----

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?199811180255.UAA01561>