This one time, at band camp, Petter Reinholdtsen said: > [Stephen Gran] > > Now, one thing that has been bothering me - is there a facility in > > these scripts to sya, 'wait until all scripts of type foo are done > > to start, if present'? In other words, something like a > > Should-Start-Group: with the other scripts useing a Member-Of: > > rather than a Provides: header? > > There is some facility for this, using the $<facility> notation. But > it is not very good for this.
My reading of the proposal was that when a single thing providing $facility comes up, the launcher interprets that to mean that $facility is available - exactly what I am trying to address. > My proposal to solve this, is some kind of 'before' statement, but it > is not standardized nor implemented anywere. That's not unreasonable, but since we already have other classful containers for depending objects (all objects waiting on $network, for instance), it seems easier to just abstract that to provide classful containers for providing objects as well. Of course, I am saying this without looking at a whit of code, so I may just be speaking out of my ass, but that's not uncommon :) > > This would be helpful for, for instance, sendmail, where you want it > > to wait for all milters to start - sendmail's init script could wait > > on group milter, and then all the milters could declare themselves > > part of milter, and be started in parallel. > > Here the milters (no idea what a milter is. :) would express that they > want to start before sendmail, and the script ordering system would > try to make sure this happen. :) A milter is a MailfILTER for sendmail - the particular problem here is that sendmail needs them running before it starts processing mail, as it will immediately try to communicate with them and fail. But this was a generalization of a more abstract problem, I think - I can think of many classes of things that may have multiple subparts, and all the subparts should be up. For instance, $time might actually involve hwctosys, ntpdate and ntp-server all coming up, so that an application that is very picky about timing doesn't puke when the system clock suddenly jumps. > But as I said, there is no support for this at the moment. Oh well. Thanks for the discussion, though. Take care, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
