Date: Fri, 20 Nov 1998 14:58:24 +0100 From: Eivind Eklund <eivind@yes.no> To: Rene de Vries <rene@canyon.demon.nl>, freebsd-hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: /etc/rc.d, and changes to /etc/rc? Message-ID: <19981120145824.53958@follo.net> In-Reply-To: <199811201216.NAA00990@canyon.demon.nl>; from Rene de Vries on Fri, Nov 20, 1998 at 01:16:28PM %2B0100 References: <19981119235019.54220@follo.net> <199811201216.NAA00990@canyon.demon.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 20, 1998 at 01:16:28PM +0100, Rene de Vries wrote: > Wouldn't it be neat to have a command like: "service start apache" which > starts apache (and all other services needed to run apache). > > I think that this could be done along the same lines as Eivind suggested, > but without the "RC:BEFORE" option. Services should know on which other > services they depend on and therefor you don't need a before option. This was what I thought, too. Then I started implementing it. Then I found a definite need for "RC:BEFORE". It is extremely simple to implement (you just insert an edge in the opposite direction in the graph), and it introduce a lot of freedom of expression - and a lot of expressions become very wrong if you don't introduce it. An example of this is the running of 'savecore'. You want to run this early. This is a dependency of savecore, not of the stuff that come later. Expressing it in the stuff that come later is IMO inappropriate, especially as you will have to introduce it everywhere. With RC:BEFORE, it is possible to create blocks in the startup architecture, and let extra services add themselves between the blocks. An example is the network stages: network1 ... network2 ... network3 There are a bunch of things that need to run between network1 and network2. I can easily envision having to add more things there - and having to modify network2 each time would be a pain. This is especially true if the new stuff comes from /usr/local/etc/rc.d - changes there should IMO *never* have to result in changes in /etc/rc.d. > /etc/rc could then use something like ". /sbin/service start all" to start > all services. > > The nice thing is that if you know a dependency graph of all services you > could also use it to stop services, stopping also all services depending > on the stopped service. This would easy starting and stopping of services > that provide a service for other services (like databases). This was the intent, yes :-) It also allow you to create 'runstates' by just composing them of sets of services. [... Suggested user interface snipped ...] > Maybe we should move the stuff that is currently started from rc* to > be seen as a service. This has the *big* disadvantage of removing rc.conf > (or sourcing that file in a lot of services). Heh. I already did the move (including rc.conf support :-), but didn't add the 'start', 'stop', 'restart' and 'verify' (update /var/run/services/ if admin has manually killed daemons) keywords to the stuff in rc.d - as what I did was intended as a proof-of-concept for the topological ordering, not the rest (which we already had Nik's suggestions for, which I basically agreed to). > I don't know if the actual implementation would be easy (or at least > feasible), but the ui would certainly help a lot of sysadmins with > their daily work. Not too difficult to implement, I think. That's why I started to try :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981120145824.53958>