Date: Tue, 15 Jul 1997 08:15:22 -0400 From: Dan Janowski <danj@3skel.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: multiple run-levels (was: Re: /etc/init.d/) Message-ID: <33CB69DA.9B1052@3skel.com> References: <Pine.BSF.3.91.970715103536.27554A-100000@ns.uk.peer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi All, A multiple runlevel mechanism provides some benefits, but most of them are secondary. The runlevel part is mostly smoke. The benefits are that each class or group of programs/processes has its own shell script for initialization. This is a LOT like the way we have stuff in /usr/local/etc/rc.d. The other stuff, concerning what services should be started if you are at init 2 instead of init 3 is more complicated than what a "runlevel" can address. A long time ago, when I was younger, I wrote an entire runlevel and init.d/rc?.d system for Linux based on IRIX. There were only two things that were of any use: 1. At the boot loader prompt you could set a variable (LOCALE) that was available to the rc scripts that would allow the employment of location based control of what services should/shouldn't, network interfaces... 2. chkconfig, which is an IRIX particular rc mechanism that allows one to type 'chkconfig timed off' at a prompt, and the next time you go to a multiuser state, timed would not be started. This meant that no actual file editing was necessary. To REALLY be useful, a mechanism has to be able to change resolv.conf, host.conf, hosts, ifconfigs, fstabs (for local and NFS), libsocks.conf, routes, etc. All kinds of crap really. Init.d ain't gonna do it. Another mechanism can be designed and implemented, but it isn't really going to look like anything that we've seen before. Dan -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33CB69DA.9B1052>