RE: Scripts for /etc/init.d or /etc/rc.d

Jonathan Hogg wrote:

> [I'm super-busy this week, but a quick reply:]

Thank you for a very helpful reply.

> On 21/5/03 23:47, Shprentz, Joel [C] wrote:

>> 1. It was not clear how to control the seqence of execution among
>>    ark-controlled scripts and standard startup scripts. For example,
>>    we want to start the database server before the web server.

> It's possible to solve these problems using ARK dependencies.
> You can do something along the lines of:

> <start>
>    <constraints>
>      <dependency type="essential" name="apache" on-method="start"/>
>    </constraints>
>    <code once-per="hosts-supported" recordable="no">
>      ...
>    </code>
> </start>

The remaining challenge is controlling the execution order of
system-supplied startup scripts and Ark-managed startup scripts.  For
example, we may want this sequence (taken from Solaris 8 /etc/rc2.d):

  ...
  Sun autofs
  Ark syslog replacement
  Sun xntpd
  Sun cron
  Sun savecore
  Sun nscd
  Ark lp replacement
  Sun preserve
  Sun spc
  Sun power
  Ark sendmail replacement
  Ark sshd
  ...

Order sometimes does matter: start syslog; start xntpd, which logs date/time
status; start cron, which relies on accurate time.  I'm not sure that Sun's
order is right: shouldn't lp, which can send mail, start after sendmail?
(It depends on how lp sends mail.)

Some possibilities:

* Continue to rely on Unix's script name sequencing and invoke ark from
multiple Snn startup scripts, each time starting some different packages.

* Replace all startup scripts with ark packages. Invoke ark once during
startup.

* Await Jonathan's reply for a more sensible solution.

> ...
> A possible way around this is to pull the sort of tricks that Will's
> 'un-' methods do to forget that something has been done in the past.
> This would go something like:
> ...
> You'd want to hide this sort of madness in a proto-package and use Will's
> usual trick of adding '-bits' methods that you then override in the actual
> packages, e.g.:
> ...

Ah, so that's what Will intended.  I advance one step toward understanding
Arusha.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge