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

Jonathan Hogg wrote:

> Personally, I usually just have a prototype for Things That
> Should Start At Boot and <start/> and <stop/> methods. ...

As I pondered Jonathan's solution, I began writing what could become the
Sidai documentation for installing boot scripts.  I haven't implemented any
code yet, but here is my current thinking.  Please feel free to comment.

[Sorry, I converted the HTML to text for this mailing list.  Imagine
headings, bold, italic, typewriter text, etc. where appropriate.]

Sidai team: installing /etc/rc.d scripts

Background

Goal: Install server startup scripts in appropriate directories.

At boot time, the system executes scripts that configure system services
and start various servers and daemons. At shutdown time, these same scripts
gracefully stop servers and release system resources.

Systems running Solaris store these scripts in directories named
/etc/rc0.d, /etc/rc1.d, etc. During a typical boot to run level 3, the
system executes startup scripts in rcS.d, rc1.d, rc2.d, and finally rc3.d.
Within each directory, startup script names begin with Snn, where nn is a
two-digit sequence number. For example, in /etc/rc2.d, the system runs
S73nfs.client before S75cron.

At shudown time, the system runs "kill" scripts, which have names beginning
with Knn. The system runs rc2.d kill scripts first, then rc1.d kill
scripts, and so on.

System running Linux store their scripts in /etc/rc.d/rc1.d through
/etc/rc.d/rc6.d. Linux runs startup scripts only in the directory
corresponding to the target run level.

Both Solaris and Linux link the rcn.d scripts to descriptively named files
in a nearby init.d directory. In Solaris, for example, /etc/rc2.d/S75cron
is linked to /etc/init.d/cron. For some reason, Solaris uses hard links,
while Linux uses symbolic links.

Linux includes the chkconfig utility, which can install, remove, and list
startup files based on metadata contained within each script. Solaris
requires manual (or scripted) installation of startup files.

Solaris and Linux startup files vary somewhat in style. For example, Red
Hat Linux startup files import a helpful library, which includes standard
status reporting among many other functions.

An expert suggests ...

Responding to a question on the Ark developers's mailing list, Jonathan
Hogg wrote,

     Personally, I usually just have a prototype for Things That
     Should Start At Boot and <start/> and <stop/> methods. Then I
     have a single script in my /etc/rc.d (or whatever) that does
     something like:

         /ark/bin/ark package start --host=. boot-services

     This works well enough in most cases. It also allows you to use
     ark to do cool things like:

         /ark/bin/ark package reload --host=ALL apache--2.0

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.

Decisions

Use a single script to initiate ark-managed startup activity or use
individual scripts for each application? To best control the sequence of
script execution, install individual scripts in the rcn.d directories.

Store startup scripts in templates or fragments? The sys-cron-config
package gathers crontab fragments from many packages (and hosts and ...)
and assembles them into system and user crontab files. Many other packages
process Ark templates to generate configuration files. Individual startup
scripts are typically under 100 lines, but a package may provide different
scripts for Linux, Solaris, etc. To focus a team's package XML description
files on parameters and to avoid bloat there, store startup scripts in
configurable templates.

Store templates in application configuration directories or in a
centralized configuration directory? Most servers that need startup scripts
already have a separate package and directory to manage configuration
files. For example, Samba has a configuration package samba-config, which
installs templated files from the samba-config directory. To keep all of an
application's templates together, store the startup script template in the
application's configuration directory.

Rely on chkconfig style metadata embedded in startup scripts or on Ark
parameters? Scripts installed by chkconfig must contain metadata describing
their run levels and sequence numbers. A typical script might contain these
lines:

    # chkconfig: 234 21 82
    # description: Provide file service to Windows hosts.

The first line instructs chkconfig to install the script in the directories
for run levels 2, 3, and 4 with start sequence 21 and stop sequence 82.

Since Arusha favors explicit parameters defined in XML over information
embedded within other files, define run levels and sequence numbers with
Ark parameters.

Treat the startup script as "just another template to install" or create a
separate package to manage startup script installations? Startup scripts
differ from other application files because they must be installed as root
and because they have unique path linking requirements. Rather than
contaminate every server package with these requirements, define a separate
package to manage startup script installation and linking.



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