Date: Mon, 25 Sep 1995 22:56:27 -0700 From: patl@asimov.volant.org To: hackers@FreeBSD.ORG, peter@taronga.com, gryphon@healer.com Subject: Re: ports startup scripts Message-ID: <9509260556.AA29927@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> From: peter@taronga.com (Peter da Silva) |> > > > Ordering guarantees within a single run level/state are hard |> > > > to provide |> > +> Actually, a single file is the easiest to control ordering in. |> |> > Not if you're adding to it from a script. |> |> Three cases: (1) by hand (2) a GUI admin tool (3) a package install script |> |> 1 is easy. Humans parse things. Only if the human has enough experience with the service and its dependancies to know where it can safely go... |> 2 is easy. The GUI controls the file writing in all cases If you think this would be a popular decision, talk to anyone who has fought with Solaris2's AdminTool over serial port or printer setup. |> 3 is not very difficult in an of itself. It calls a command tool that uses |> the same library subroutine that the GUI calls to edit the file. And suffers from the same problems; but without the fallback of being able to assume an interactive session where it can ask questions if it's having problems. |> The problem comes with dependancies. Which can be either addition |> information from the package, or guessed at (by any of the above). |> Personally, I can conceive of no reason not to make them explicit |> information contained in the package. Which means that the dependancy can never appearance - i.e. if I have a service which is dependant on having having the automounter running, I can't replace amd with whizzod. Furthermore, your dependancies will be on specific services, not a class of service. (E.g., you will be dependant on 'nfsd started', not on 'all remote file system servers started'. The rc?.d scheme, with identified sequence points, allows for a higher level of abstraction. |> So the package install script is never editing the file itself, |> it is calling something which does. |> |> And I really can't see a difference between correctly using a tool to add |> a line to a file, and correctly using a tool (the file system) to add a |> numbered script to a directory. Either you use it correctly or not, either |> it's written correctly or not. If not, you're in a world of hurt either |> way. Two differences. The first is the complexity and safety of the tool. The second is that the 'file system tool' already exists, and is widely used elsewhere in the system for a variety of purposes; a startup script editing tool would be a new, special-purpose tool. |> > Yeh, but does "httpd" come before or after "nfsiod"? |> > It's much easier to do "ln -s ../init.d/httpd S95httpd" than to figure out |> > where in the middle of a user-hacked script a command needs to go. |> |> I don't know. Personally, since httpd is stand-alone, I'd put it after |> anything else that might have things depending on it (like file system |> daemons). And I'd put it before the PPP links to the outside world... |> But whoever picked the number 95 sure knows... |> Back to my three cases. In your case #1, the person doing the install needed to know. In your cases #2 and #3 it is harder to manually modify them for some site-specific reason. (Ok, the modification itself probably isn't easier, but there's the ripple effect through any other services that are dependant upon it. In the rc?.d system, they stay in the same place, in the control file system, they probably move. Which is desired is purely case-specific. |> Again, if you can figure out the number, you can figure out what |> it is dependent upon. If you can't you can't. The point is who has to do it and when. Figuring out the (default) file number is done once when the package is created. (Probably not even changed for new revs of the software.) Modifying control files must be done on a per-system basis for each install. -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509260556.AA29927>