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:
serelhistory [general options] --populate
Query the history:
serelhistory [general options] --query args
Register services as having already started:
serelhistory [general options] --apply-started
Register the service (and dependencies) associated with a pathname:
serelhistory [general options] --apply path
serelhistory supports the four basic steps involved with running boot scripts in parallel:
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.
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
Testing the dependency graph for integrity
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.
num controls the verbosity of the log output:
| 0 - none |
| 1 - default |
| 2 - and above generate increased verbosity |
Output logging to log, which is either a filename or syslog facility (LOG_XXXX)
(default) Append log messages to the log file
Truncate the log file before writing log messages
Report the version number and exit
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]...}
This option takes the form:
serelhistory [general options] --query args
where args is one of: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.
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.
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.
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:
querying the daemon for the service provided by the given path
executing "serelc --provide" for the provided service
executing "serelc --need" for each service required by the provided service