serelhistory

Name

serelhistory -- Manage and use historical service relationships

Synopsis

serelhistory [general options] [--populate | --query | --apply-started | --apply]

DESCRIPTION

serelhistory improves the performance of a parallel boot by allowing dependency information to persist across boot invocations.

One of the following options must be selected: "populate", "query", "apply", "apply-started".

Populate the history:

Query the history:

Register services as having already started:

Register the service (and dependencies) associated with a pathname:

serelhistory supports the four basic steps involved with running boot scripts in parallel:

  1. Selection of service definitions from among the available sources. Service defintions can be found in .rdf files, and in specially-formatted comments inside boot scripts.

  2. Construction of a dependency graph, informed by:

    • the service definitions found in step 1 above

    • the collection of services being started (or stopped) as a unit

    • the collection of services that were last started (or stopped) as a unit

  3. Testing the dependency graph for integrity

  4. Applying the dependencies represented by the graph

Data from steps 1-3 are persistent, so that a subequent boot using the same services and service-definitions avoids the processing associated with these steps.

GENERAL OPTIONS

-d --debuglevel num

num controls the verbosity of the log output:

0 - none
1 - default
2 - and above generate increased verbosity

-l --log log

Output logging to log, which is either a filename or syslog facility (LOG_XXXX)

-a --log-append

(default) Append log messages to the log file

-t --log-truncate

Truncate the log file before writing log messages

-v --version

Report the version number and exit

POPULATING THE HISTORY

This option takes the form:

serelhistory [general options] --populate

The set of services that are being started as a unit are read from standard input, which takes the form:

[ --started {[service]...}]

followed by:

--pairs {[service path]...}

QUERYING THE HISTORY

This option takes the form:

serelhistory [general options] --query args

where args is one of:

verify

This tests that a directed, acyclic graph can built from the services given to --populate. None of the following can be true for the test to succeed:

  • service A depends on service B, and no dependency information is available for service B

  • the graph is cyclic. That is, service A depends on service B, and (even indirectly) service B depends upon service A

The single word "success" is sent to standard output if the test succeeds, otherwise an informational message.

prior-history

This tests whether the last call to serelhistory --populate used history information from a prior boot. The single word "success" is sent to standard output if history information from a prior boot was used, otherwise an informational message.

SERVICES THAT HAVE ALREADY STARTED

This option takes the form:

serelhistory [general options] --apply-started

Some services may have already started outside the serel framework - the names of these services are passed to the daemon via --populate.

This option instructs the daemon to register the already-started services. This option is equivalent to running "serelc --provide" for each of the already-started services.

STARTING SERVICES

This option takes the form:

serelhistory [general options] --apply

Populating the history establishes relationships between pathnames and services.

This command instructs the daemon to apply the serelc --provide, --need, and --unprovide statements corresponding to the given pathname.

The command is equivalent to, but more efficient than the following steps:

EXIT STATUS

To be written.

CAVEATS

This software is relatively immature, some options may be renamed or may disappear altogether.

REPORTING BUGS

Email bug reports to .

SEE ALSO

serelc (8), sereld (8)

AUTHOR

Leni Mayo