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

Jonathan Hogg <[email protected]> Fri, 23 May 2003 09:05:34 +0100
Newsgroups gmane.comp.sysutils.ark.devel
Message-ID <BAF394DE.1B549%[email protected]>
On 21/5/03 23:47, Shprentz, Joel [C] wrote:

> This approach fits well with Arusha, but had two apparent shortcomings:
> 
> 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.
> 2. Many application supplied startup scripts include code to execute
>    before the start/stop branch. This code typically establishes file
>    locations, confirms that the application is installed and configured,
>    and defines functions needed later. Splitting a script into <start/>
>    and <stop/> methods would require duplicating that code.

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

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>

For the first, and:

    <prepare>
        <code once-per="hosts-supported" recordable="no">
            ...
        </code>
    </prepare>

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

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

For the second. The one problem with this kind of hackery is that these
methods have to be marked 'recordable="no"' in order to allow them to be
re-run, but that means that dependencies can result in trying to run a
'start' method multiple times.

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:

    <start>
        <param name="PKGS_STATE_DIR">
            @team:ark-dirs:ARK_STATE@/package
        </param>
        <param name="PKG_PROTO_HOST">!proxy_for.idString</param>
        <param name="PKG_ID">!pkg_id</param>
        <code once-per="hosts-supported">
            ...
            rm -f $PKGS_STATE_DIR/$PKG_ID/stop--$PKG_PROTO_HOST
        </code>
    </start>

    <start>
        <param name="PKGS_STATE_DIR">
            @team:ark-dirs:ARK_STATE@/package
        </param>
        <param name="PKG_PROTO_HOST">!proxy_for.idString</param>
        <param name="PKG_ID">!pkg_id</param>
        <code once-per="hosts-supported">
            ...
            rm -f $PKGS_STATE_DIR/$PKG_ID/stop--$PKG_PROTO_HOST
        </code>
    </start>

(This is sort of like keeping and removing a '.pid' lockfile in /var.)

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.:

    <start-bits>
        <code once-per="hosts-supported" recordable="no">
            echo "Error: You were meant to override this method."
            exit 1
        </code>
    </start-bits>

    <start>
        <constraints>
            <dependency type="essential" name="." on-method="start-bits"/>
        </constraints>
        <param name="PKGS_STATE_DIR">
            @team:ark-dirs:ARK_STATE@/package
        </param>
        <param name="PKG_PROTO_HOST">!proxy_for.idString</param>
        <param name="PKG_ID">!pkg_id</param>
        <code once-per="hosts-supported">
            rm -f $PKGS_STATE_DIR/$PKG_ID/stop--$PKG_PROTO_HOST
        </code>
    </start>

I've not actually tried anything like this, so point out if I've said
anything stupid Will ;-)

Jonathan



-------------------------------------------------------
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