From owner-freebsd-hackers Thu Apr 24 00:20:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA21272 for hackers-outgoing; Thu, 24 Apr 1997 00:20:57 -0700 (PDT) Received: from nyx.pr.mcs.net (nyx.pr.mcs.net [204.95.55.81]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA21266 for ; Thu, 24 Apr 1997 00:20:53 -0700 (PDT) Received: from nyx.pr.mcs.net (localhost [127.0.0.1]) by nyx.pr.mcs.net (8.8.5/8.8.5) with ESMTP id CAA03278; Thu, 24 Apr 1997 02:20:40 -0500 (CDT) Message-Id: <199704240720.CAA03278@nyx.pr.mcs.net> X-Mailer: exmh version 1.6.9 8/22/96 To: "Kevin P. Neal" cc: hackers@freebsd.org Subject: Re: Discussion of boot mechanism (Was Re: /etc/netstart bogons.. ) In-reply-to: Your message of Thu, 24 Apr 1997 02:18:03 -0400. <1.5.4.32.19970424061803.017959d4@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Apr 1997 02:20:39 -0500 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>1. run levels, and lame shell script links like S01*, S10*, etc. There is >>basically no need for this--it is essentially a hack to get around >> the lack of a real dependancy handling system. How best to implement it >> though? Even some people have proposed using make. I dont know if this >> could support the kind of dynamic dependancies we want though. I was >> thinking more along the lines of having something like >> "#require NETWORK" at the beginning of the scripts, and using a generic >> sh script to parse / order / record dependancy information. > >I thought about this also. How about having "classes" of scripts, with >specific names on individual scripts as well. This would allow you to do >things like having, for example, Apache not start up until after the Networking >stuff has started. Also, have some Networking programs not start until >named has started, etc. Have named not start until ifconfig runs, etc. Basically, however hopefully not getting as specific as ifconfig. :) I dont think we should only use predefined "classes" though. You should be able to create dependancies on whatever you want. >Some scripts are going to fail for somebody sometime. In these cases should >you drop back down to the level you are leaving, or continue on up? You most certainly do not continue. :) Have you ever had to wait a half hour for a machine that tries to mount nfs filesystems when the networking is broken? If services that are required are broken, theres nothing else to do. >As for run levels, why not define three: halted, single user, and multiuser. >Have the multiuser level be configurable (if you want it at, say, 3 then you >can have it be 3). Have the other levels be user configurable. Well, this is essentially how things are. We currently have single, and multi. Any further run-level abstraction per say should be handled by rc. We do need something that will be executed upon a halt though.. [ cosmetic stuff deleted ] >As well has keeping rc-style startup for the people that just *like* it. > >I'd like to see the startup scripts get run not by init, but by a program >run by init. This would allow for very easy additions of other rc.d directories. This is essentially how it is. init calls rc. rc can do whatever it wants from there. I don't think this needs to change, however a shutdown hook must be added. Leaving this alone allows us backword compatibility by just replacing the script with the old style one. --Chris Csanady