From owner-freebsd-hackers Mon Sep 25 14:56:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23634 for hackers-outgoing; Mon, 25 Sep 1995 14:56:47 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23626 for ; Mon, 25 Sep 1995 14:56:21 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA13441; Mon, 25 Sep 1995 17:52:42 -0400 Date: Mon, 25 Sep 1995 17:52:42 -0400 From: Coranth Gryphon Message-Id: <199509252152.RAA13441@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: patl@asimov.volant.org > And hard links are even more useful than symlinks. With hard links, > you can easily determine how many states are using a given script > simply by checking the number of links to the master copy. ... > Right. One directory per state, and one directory for the cannonical > location of the scripts. Same problem. I've just seen two many times when keeping multiple copies of something has led to problems. |> Yep. That works. The only problem is shutting things down, if you |> are not simple shutting everything down. > |> Actually, at that point you'd need a matrix of what to stop and start > |> depending upon what run-state you are going from and to. > |> > |> All the more reason to go with linear run-levels. > Not really - a stateX-to-stateY transition could be done by shutting > down stateX completely and then starting stateY from scratch. Yeah, thought of that. Was trying to avoid it to maintain continuity between daemons. > My problem with run levels is that if I want a state which does not > correspond to any of the standard levels, it will probably need to > go inbetween two of the standard ones. (E.g. multi-user, with full Same problem occurs with states - you have to pick the one closest to what you want and > as levels, I'd have to re-number the levels to insert my new state. Granted, that is a problem. We could solve most of it by allocating a half-way state that is unused at each point a "local". > If the implementation supports states, it is easy to provide levels. > If it only supports levels, using it to get distinct states is going > to be pretty tough. Yep, you're right. That's the biggest drawback of levels. It quickly becomes a matter of - how much flexibility is really going to be used how often. If it's twice the work for twice the functionality, it's worth it. If it's twice the work to make +5% people happy, then it's questionable. If twice the work makes ten people happy, then it's not. > |> Yep. Alternately, the "cron" script can take an argument of "multi-user" > |> or "network" and do the right thing. > Cron shouldn't need to know. And doing that limits the possible cron > actions choosable from the different states. Cron doesn't know. The script that runs starts/runs/creates/whatever the crontab entry knows. |> in summary, my druthers are: |> > one directory for all start and stop scripts |> > explicit invocation order, a list |> > one name per script regardless of run-state/level |> > (no links hard or soft) |> > One master directory for start/stop/restart scripts. > One directory per run state, with hardlinks to above. > Invocation order dictated by digits in script name. As I said in my response to Terry, it quickly becomes religious discussion of which is better, numbered scripts or control files. > --- NO SCRIPT EDITING !!! ---- We are not talking about script editing. We are talking about adding a line to a control file, versus adding a line to a directory. > I cannot possibly overemphasize the advantages of a system which > avoids the need to ever automatically edit any file. This avoidance > is the single biggest advantage of the SVr4 model. And one of it's single biggest confusions. I prefer BSD variants over SysV variants BECAUSE of design decisions like this. A lot of other people probably do as well. If you want SysV, use Linux. If you want FreeBSD to get some new flexibility (based upon concepts from anywhere else) - GREAT. But don't say "SysV is doing it so we should"! At this point, we have two distinct camps - those who want to see the {S|K}NNfoo scripts in "rc?.d" with a copy in "init.d" subdir. In other words "SysV". And those of us who want one directory ("init.d") and a control file to specify what gets run when. In other words, a hybrid. Neither camp is going to convince the other. So someone who can make the decision of which direction to head in should do so, and let us get down to doing the best implementation of whichever that we can, rather than debating it for another three months, and then kludging something together in a hurry. Or, if we want to put a little more work in, we can do both and make everyone happy. We have to define the commonalities (one script per subsys/package/component, a copy in "init.d") and a fixed interface so that the two different startup "descriptions" can both use the underlying mechanism. What this means is that both camps will write versions, and make sure they work together. But we'll end up with something that is simply fantastic, and will suit both styles. If we go with control files, or with the do-it-both-ways system, count me in as willing to do a large chunk of it. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa...