Date: Tue, 24 Feb 2004 13:19:42 -0500 From: Charles Swiger <cswiger@mac.com> To: "Timur I. Bakeyev" <timur@com.bat.ru> Cc: Oliver Eikemeier <eikemeier@fillmore-labs.com> Subject: Re: OPTIONS, LATEST_LINK, and RCng Message-ID: <04206E1D-66F6-11D8-8D4C-003065ABFD92@mac.com> In-Reply-To: <web-160229@mail.bat.ru> References: <web-160229@mail.bat.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 24, 2004, at 11:15 AM, Timur I. Bakeyev wrote: > On Tue, 24 Feb 2004 10:46:24 +0100 > Oliver Eikemeier <eikemeier@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 :-). ] -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04206E1D-66F6-11D8-8D4C-003065ABFD92>