OPTIONS, LATEST_LINK, and RCng
cswiger at mac.com
Tue Feb 24 10:20:01 PST 2004
On Feb 24, 2004, at 11:15 AM, Timur I. Bakeyev wrote:
> On Tue, 24 Feb 2004 10:46:24 +0100
> Oliver Eikemeier <eikemeier at fillmore-labs.com> wrote:
>> Chuck Swiger wrote:
>>> I that life would be better, or less astonishing :-), if rcvar
>>> defaulted to "y" for manual invocation and for startup scripts in
>> I guess I don't really like that. First of all, I'm a big friend of
>> activated services, since then I know what is running on my machine.
>> it would be difficult to make this consistent, since I might only
>> want to
>> start some of the daemons provided in a port (eg. slapd but not
>> slurpd from
>> OpenLDAP). Most of the `classical' script defaulted to `NO' (or
>> But maybe I'm too cautious here?
> I really don't understand, what this arguing is all about :(
I don't think Oliver and I are arguing, or even vigorously disagreeing.
> Noone complains, that the need to enable sendmail, inetd, named, etc.
> for the core system in the rc.conf. As for me, I'm very happy, that
> all the services are described in ONE place and I don't need to jump
> around all the etc/ directories to figure out, what I do run.
So far, so good-- I agree that the /etc/rc.conf mechanism works very
well, and it is the sensible place to configure sshd_enable,
sendmail_enable, and so forth.
> The second thing is that when I'm installing something it doesn't
> mean, that I wan't to run it immediately. And I don't want to see
> annoying messages, that I haven't started 20 daemons I've installed on
> my packaging machine. I think, if you install something you are keen
> to make additional step and explicitly enable new service. BTW, that
> wasn't the case with the old way of installing the ports - you still
> needed to copy startup script from .sample...
You have a point, and I understand the utility of having software
installed but not configured to startup upon system boot. I also
understand that making rcNG produce annoying messages is undesirable.
RC scripts have evolved from BSD's /etc/rc.local, SysV-style runlevels
with /etc/init.d, to rcNG; named was the first software I know of which
shipped a controller script which responded to "start", "stop",
"restart", and others. Consider a command like "ndc" or "apachectl":
doing an "ndc start" should start the nameserver. Having ndc not do
anything unless /etc/rc.conf contains named_enable="YES" would be
surprising to me. Having "ndc start" return without starting the
nameserver and without display a message saying "I didn't start because
of some reason" violates POLA.
On a SysV system, the distinction between "installing software" and
"configuring software to run upon system boot" was handled by
installing all startup scripts in /etc/init.d, and symlink the commands
you actually want to run into /etc/rcN.d. You could also manually
start a service named foo whenever you wanted to by running
For example, one could symlink ndc to /etc/rc2.d/S50named, or do the
same for apachectl, and a SysV system like Solaris would happily start
named, apache, or whatever. I found SysV runlevels tolerable, although
the lack of dependencies requires one to manually order the startup
sequence; rcNG solves that problem.
You've already described the classic pre-rcNG mechanism for FreeBSD
ports, which was to install foo.sh.sample and require the user to copy
or symlink that to foo.sh. However, again, one could run
"/usr/local/etc/rc.d/foo.sh start" (or "foo.sh.sample start") and have
it behave as expected.
I'm willing to live with foo_enable defaulting to NO under rcNG all of
the time-- after all, the patch I suggested doesn't change that
behavior. However, I will make the argument that foo_enable really
ought to default to YES when the command is run interactively. Failing
that, at the very least rcNG needs to tell the user that the command
they just ran didn't actually do what they expected, which is what my
[ I'd also prefer to see rcNG default to NO for services shipped with
the base system, and YES for services added by the user via ports-- aka
services in /usr/local/etc/rc.d-- but I can live with the existing
behavior (as I said, sorry for the repetition :-). ]
More information about the freebsd-ports