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