Charles Swiger 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 
>>> /usr/local/etc/rc.d...
>> I guess I don't really like that. First of all, I'm a big friend of 
>> manually
>> activated services, since then I know what is running on my machine. 
>> Second
>> 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 
>> .sample).
>> 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 
"/etc/init.d/foo start".

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 
patch does.

[ 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 mailing list