From owner-freebsd-hackers Mon Sep 25 19:28:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05097 for hackers-outgoing; Mon, 25 Sep 1995 19:28:23 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05086 for ; Mon, 25 Sep 1995 19:28:10 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id TAA14346; Mon, 25 Sep 1995 19:27:06 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29636; Mon, 25 Sep 1995 19:32:44 -0700 Date: Mon, 25 Sep 1995 19:32:44 -0700 Message-Id: <9509260232.AA29636@asimov.volant.org> To: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > 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. They aren't multiple copies, they are multiple links to a single copy. I generally agree that having multiple copies or multiple locations can lead to problems; but in this case I believe that the advantages far outweigh the possible difficulties. |> > 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 No, I can easily create my own state using the next available state number. Since there's no implied level-ordering of the states, which number I choose is purely arbitrary. |> > 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". Gack. First, one 'local' isn't enough. Second, the new states may not actually fit between any of the existing states. (E.g., another contractor I know wants a single-user-with-networking state.) |> > 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. But it isn't twice the work. It's barely any more work at all. |> > |> 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. Ok, the script invoking the per-service scripts shouldn't need to know that cron takes a different parameter than other scripts, and a parameter based on the state being entered. The SVr4/Solaris2/etc. technique is the simplest and most powerful mechanism proposed to date. Let's not let a hatred for SysV keep us from adopting one of the things they did -very- well. |> |> 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. How does 'adding a line' differ from 'editing' ? Control file -vs- script is a minor point compared to the fact of installation scripts editing shared system control files. |> > 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 this really confuses you that much, perhaps you aren't well suited to systems administration. Personally, I'd far rather have the tiny bit of potential confusion than the huge potential for damage. |> 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"! Don't say "SysV is doing it so we shouldn't"! I really think you are letting your hatred for SystemV color your judgement here. Sit back and pretend that this mechanism was not invented by SysV. Pretend that we are inventing it here for the first time. Would you really be so adamantly against it? (You don't have to answer publicly - just think about it for yourself.) |> 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". Would it help if we struck out "SysV" and substituted "Solaris2", or do you hate that as well? |> 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. Sounds like less of an improvement over the current system than Windows95 was over Windows 3.1. |> 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. Easily done. 'Inittab' and init.d become the 'required' part of the system, with a control file or rc?.d subdirs and rc? scripts as the 'optional' parts. |> But we'll end up with something that is simply fantastic, |> and will suit both styles. That's a lot tougher. The biggest problem being to make the package installation scripts able to handle the necessary updates for both techniques. (And without turning that into another maintainance nightmare or Rube Goldberg system.) |> 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. And if we go with states, rc?.d subdirs, etc., I'll certainly contribute whatever I can. -Pat