From owner-freebsd-hackers Sat Sep 23 10:20:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA12075 for hackers-outgoing; Sat, 23 Sep 1995 10:20:34 -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 KAA12062 for ; Sat, 23 Sep 1995 10:20:30 -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 IAA28703; Sat, 23 Sep 1995 08:47:28 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA25492; Sat, 23 Sep 1995 08:53:07 -0700 Date: Sat, 23 Sep 1995 08:53:07 -0700 Message-Id: <9509231553.AA25492@asimov.volant.org> To: hackers@freebsd.org, peter@taronga.com, gryphon@healer.com Subject: Re: ports startup scripts X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> From: peter@taronga.com (Peter da Silva) |> > +> But keeping a set of directories for the sole purpose of linking |> > +> to one common directory is hellishly redundant. |> |> ... |> |> > And no, it's not "hellishly redundant". It's actually very convenient. |> > Much more so than referencing via a file: |> |> What I mean was "redundant" is having one directory being a mirror |> of the other. I honestly can't see what is gained. Either you just |> put everything in specific directory you want it to be in, or put |> it in one common directory. Not both. It isn't a mirror, it's a subset. And it is very convienient to have easy access to both the complete set and the individual subsets. |> > + Adding or deleting a script can be done without editing a file. |> |> If you want things to be in one directory, and not have a config file, |> then name the startup scripts based on level. Thus: |> |> NNfoo.# |> |> Where NN is done for ordering, and # is the run level associated with it. First, this makes it a bit more awkward for manually restarting, or for handling services that are -only- started manually. Particularly, the script name must change if you change a service from manual to automatic start, or vice versa. For example, with the SVr4/Solaris scheme I can restart the HTTP daemon via '/etc/init.d/httpd restart'. I don't need to remember (or look up) which run level it is in or what its sequence number is. (Which also makes it convienient for scripts to start/stop/restart services outside the init sequence.) Second, you are still thinking of the levels as a monotonic sequence instead of as states. The state concept adds significant power and flexability at almost no cost. (Pat's design rule #1: Don't get in your users' way. Just because you don't have any use for arbitrary states doesn't mean that nobody else does.) |> > +> Original issue: What do we allow ports and packages to modify? |> |> > Answer: We let them put a file in a directory. |> |> Yep, sounds good to me. The only problem here is making sure the NN |> (for ordering) is handled correctly. That's not that hard. You set a few widely separated sequence points in each directory, and it generally won't matter what order things happen between them. And since the links are of the form '[SK]##service', it doesn't matter if two services happen to choose the same number. Each of the rc?.d directories should contain a README that lists these sequence points. (And reminds the reader that the S* and K* files are links into init.d.) |> > +> This is the "how much of /etc/rc" do I implement. |> > +> On going up, run anything <= level with argument "start". |> > +> On going down, run anything > level with argument "stop". |> |> > You may need separate start and stop entries because the order of execution |> > may be important and not always obvious. Putting start and stop in the same |> > directory is nice, but make sure you run the stops in reverse order at least. |> |> No. I was saying one script per service, that accept (and do the right |> thing) based upon a single command line argument ("start", "stop", |> "restart"). Yes, then going up run them from lowest to highest order |> number, when going down from highest to lowest. This should be relatively |> simple to implement. But not necessarily the right order. This is another reason for the links - you have separate S and K links for start and kill operations. This also makes it easy to see what is happening for any runstate - just look in the rc?.d directory - the K* files tell you what services are being killed (and in what order), the S* files tell you which ones are being started. |> To decide upon an init procedure, we need to make two decisons before |> anything else. First, do we want run-levels or run-states? Second, do |> we want a control file, or just scripts in a directory? |> |> The only thing I have a real strong opinion on is that run-levels are |> a lot cleaner and simpler (and just as useful in most cases). I vote for states, an inittab, and a per-state script that automatically runs other scripts in the directory. (So that package installs -NEVER- have to edit a script.) |> That and don't implement both one directory per level AND one common |> directory. Pick one or the other. You've completely missed the point of the init.d-plus-rc?.d scheme. I suspect that no amount of argument or explanation will make it clear. But I do know that I find it -very- useful. Init.d tells you all of the services available, and is a very convienient place to find the service control scripts under fixed names (e.g. httpd) for invocation outside the system-state-change sequence. Rc?.d tells you which services will be started or stopped, and in what order, for a particular run state. This is not additional complication, it is additional clarity. It makes life easier for both the experienced full-time FreeBSD sysadmin and the inexperienced, occasional, or multi-OS sysadmin. -Pat