REVIEW: system initialization changes for the LSB
George Kraft <[email protected]>
| Newsgroups | gmane.linux.lsb.discuss |
|---|---|
| Organization | IBM |
| Message-ID | <1056722609.2967.299.camel@gkraft4> |
Attached is an HTML file of the LSB's system initialization chapter with the proposed changes highlighted. Please review then comment. PS: It has been suggested the should-start and should-stop could be implemented using tsort. -- George (gk4)
wip-sys-init.html
(text/html, 29.2 KB)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<h1 class="TITLE">III. System Initialization</h1>
<div class="TOC">
<dl>
<dt><b>Table of Contents</b></dt>
<dt>3. <a href="#SYSINIT">System Initialization</a></dt>
</dl>
</div>
<div class="CHAPTER">
<hr>
<h1><a name="SYSINIT"></a>Chapter 3. System Initialization</h1>
<div class="SECT1">
<h2 class="SECT1"><a name="CRONJOBS"></a>3.1. Cron Jobs</h2>
<p>Packages may not touch the configuration file <tt class="FILENAME">/etc/crontab</tt>,
nor may they modify the files in <tt class="FILENAME">/var/spool/cron/crontabs</tt>.</p>
<p>If a package wants to install a job that has to be executed via cron, it
shall place a file in one of the following directories:</p>
<table border="0" bgcolor="#e0e0e0" width="100%">
<tbody>
<tr>
<td>
<pre class="PROGRAMLISTING">/etc/cron.daily<br>/etc/cron.weekly<br>/etc/cron.monthly</pre>
</td>
</tr>
</tbody>
</table>
<p>As these directory names say, the files within them are executed on a daily,
weekly, or monthly basis, respectively. See below for the rules concerning
the names of these files.</p>
<p> If a certain job has to be executed more frequently than daily, the package
shall install a file <tt class="FILENAME">/etc/cron.d/<tt
class="REPLACEABLE"><i>cron-name</i></tt></tt> tagged as configuration file.
This file uses the same syntax as <tt class="FILENAME">/etc/crontab</tt>
and is processed by cron automatically.</p>
<p>It is recommended that files installed in any of these directories be scripts
(shell scripts, Perl scripts, etc.) so that they may be modified by the local
system administrator. In addition, they must be registered as configuration
file.</p>
<p>The scripts in these directories have to check, if all necessary programs
are installed before they try to execute them. Otherwise, problems will arise
when a package was removed (but not purged), since the configuration files
are kept on the system in this situation.</p>
<p>To avoid namespace conflicts in the /etc/cron.* directories, the filenames
used by LSB-compliant packages in /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly,
or /etc/cron.d must come from a managed namespace. These filenames may be
assigned using one of the following methods:</p>
<p></p>
<ul>
<li style="list-style-type: disc;">
<p> Assigned namespace. This namespace consists of names which only
use the character set [a-z0-9]. In order to avoid conflicts these cron
script names must be reserved through the Linux Assigned Names and Numbers
Authority (LANANA). Information about the LANANA may be found at <a
href="http://www.lanana.org" target="_top">www.lanana.org</a>. </p>
<p> Commonly used names shall be reserved in advance; developers
for projects should be encouraged reserve names from LANA, so that each
distribution can use the same name, and to avoid conflicts with other projects.</p>
</li>
<li style="list-style-type: disc;">
<p> Hierarchical namespace. This namespace consists of scripts names
which look like this: [hier1]-[hier2]-...-[name], where name is again taken
the character set [a-z0-9], and where there may be one or more [hier-n]
components. [hier1] may either be an LSB provider name assigned by
the LANANA, or it may be owners' DNS name in lower case, with at least
one '.'. I.e., "debian.org", "staroffice.sun.com", etc. The LSB provider
name assigned by LANANA must only consist of the ASCII characters [a-z0-9].</p>
</li>
<li style="list-style-type: disc;">
<p> Reserved namespace. This namespace consists of script names which
begin with the character '_', and is reserved for distribution use only.
This namespace should be used for core packages only, and in general use
of this namespace is highly discouraged. </p>
</li>
</ul>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="INISCRPTACT"></a>3.2. Init Script Actions</h2>
<p>Init files provided by LSB applications shall accept one argument, saying
what to do:</p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>start</td>
<td>start the service</td>
</tr>
<tr>
<td>stop</td>
<td>stop the service</td>
</tr>
<tr>
<td>restart</td>
<td>stop and restart the service if the service is already running,
otherwise start the service</td>
</tr>
<tr>
<td><font color="#33cc00">try-restart</font></td>
<td><font color="#33cc00">restart the service if the service is already
running</font></td>
</tr>
<tr>
<td>reload</td>
<td>cause the configuration of the service to be reloaded without actually
stopping and restarting the service</td>
</tr>
<tr>
<td>force-reload</td>
<td>cause the configuration to be reloaded if the service supports
this, otherwise restart the service</td>
</tr>
<tr>
<td>status</td>
<td>print the current status of the service</td>
</tr>
</tbody>
</table>
<p></p>
<p>The start, stop, restart, force-reload, and status commands must be supported
by all init files; the reload <font color="#33cc00">and the try-restart</font>
options are optional. Other init script actions may be defined by the init
script.</p>
<p>Init files must ensure that they will behave sensibly if invoked with
start when the service is already running, or with stop when it isn't, and
that they don't kill unfortunately-named user processes. The best way to
achieve this is to use the init-script functions provided by <tt
class="FILENAME">/lib/lsb/init-functions</tt>.</p>
<p>If a service reloads its configuration automatically (as in the case of
cron, for example), the reload option of the init file must behave as if
the configuration has been reloaded successfully.</p>
<p>These executable files must not fail obscurely when the configuration files
remain but the package has been removed, as the default in [the packaging
system] is to leave configuration files on the system after the package has
been removed. Only when it is executed with the [purge] option will [the
packaging system] remove configuration files. Therefore, you should include
a test statement at the top of the file, like this:
<table border="0" bgcolor="#e0e0e0" width="100%">
<tbody>
<tr>
<td>
<pre class="SCREEN"><tt class="USERINPUT"><b>test -f program-executed-later-in-file || exit 5</b></tt></pre>
</td>
</tr>
</tbody>
</table>
or take the equivalent action if the init file is not a shell script.</p>
<p>If the status command is given, the init script will return the following
exit status codes. </p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>0</td>
<td>program is running or service is OK</td>
</tr>
<tr>
<td>1</td>
<td>program is dead and /var/run pid file exists</td>
</tr>
<tr>
<td>2</td>
<td>program is dead and /var/lock lock file exists</td>
</tr>
<tr>
<td>3</td>
<td><font color="#33cc00">program is not running</font></td>
</tr>
<tr>
<td>4</td>
<td>program or service status is unknown</td>
</tr>
<tr>
<td>5-99</td>
<td>reserved for future LSB use</td>
</tr>
<tr>
<td>100-149</td>
<td>reserved for distribution use</td>
</tr>
<tr>
<td>150-199</td>
<td>reserved for application use</td>
</tr>
<tr>
<td>200-254</td>
<td>reserved</td>
</tr>
</tbody>
</table>
<p></p>
<p></p>
<p>In the case of init script commands other than "status" (i.e., "start",
"stop", "restart", "reload", and "force-reload"), the init script must return
an exit status of zero if the action described by the argument has been successful.
Otherwise, the exit status shall be non-zero, as defined below. In addition
to straightforward success, the following situations are also to be considered
successful: </p>
<p></p>
<ul>
<li style="list-style-type: disc;">
<p>restarting a service (instead of reloading it) with the "force-reload"
argument</p>
</li>
<li style="list-style-type: disc;">
<p>running "start" on a service already running</p>
</li>
<li style="list-style-type: disc;">
<p>running "stop" on a service already stopped or not running</p>
</li>
<li style="list-style-type: disc;">
<p>running "restart" on a service already stopped or not running</p>
</li>
</ul>
<p></p>
<p>In case of an error, while processing any init script action except for
"status", the init script must print an error message and return one of the
following non-zero exit status codes. </p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>1</td>
<td>generic or unspecified error (current practice)</td>
</tr>
<tr>
<td>2</td>
<td>invalid or excess argument(s)</td>
</tr>
<tr>
<td>3</td>
<td>unimplemented feature (for example, "reload")</td>
</tr>
<tr>
<td>4</td>
<td>user had insufficient privilege</td>
</tr>
<tr>
<td>5</td>
<td>program is not installed</td>
</tr>
<tr>
<td>6</td>
<td>program is not configured</td>
</tr>
<tr>
<td>7</td>
<td>program is not running</td>
</tr>
<tr>
<td>8-99</td>
<td>reserved for future LSB use</td>
</tr>
<tr>
<td>100-149</td>
<td>reserved for distribution use</td>
</tr>
<tr>
<td>150-199</td>
<td>reserved for application use</td>
</tr>
<tr>
<td>200-254</td>
<td>reserved</td>
</tr>
</tbody>
</table>
<p></p>
<p></p>
<p>Error and status messages should be printed with the logging functions
such as log_failure_msg and so on. Scripts may write to standard error or
standard output, but implementations need not present text written to standard
error/output to the user or do anything else with it.</p>
<p>Since init files may be run manually by a system administrator with non-standard
environment variable values for PATH, USER, LOGNAME, etc. init files must
not depend on the values of these environment variables. They should set
them to some known/default values if they are needed. </p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="INITSCRCOMCONV"></a>3.3. Comment conventions for
init scripts</h2>
<p>LSB applications which need to execute script(s) at bootup and/or shutdown
may provide one or more init.d files. These files are installed by the install_initd
program described below, which copies it into a standard directory and makes
whatever other adjustments (creation of symlinks, creation of entries in
a database, etc.) are necessary so that the script can be run at boot-time.
<a name="AEN18803" href="#FTN.AEN18803">[3]</a></p>
<p> In the init.d file, information about the shell script shall be delimited
by the lines "### BEGIN INIT INFO" and "### END INIT INFO". These delimiter
lines may containg trailing whitespace, which shall be ignored. Inside this
block there shall be lines of the form "# {keyword}: [arg1] [arg2] ...".
(All lines inside this block start with a hash ('#') character in the first
column, so that shell treats them as comments.) There must be exactly one
space character between "#" and the keyword.<a name="AEN18806"
href="#FTN.AEN18806">[4]</a> The following keywords, with their arguments
are defined in this specification:</p>
<table border="0" bgcolor="#e0e0e0" width="100%">
<tbody>
<tr>
<td>
<pre class="SCREEN"> # Provides: boot_facility_1 [ boot_facility_2 ...]<br> # Required-Start: boot_facility_1 [ boot_facility_2 ...]<br> # Required-Stop: boot_facility_1 [ boot_facility_2 ...]<br><font
color="#33cc00"> # Should-Start: boot_facility_1 [ boot_facility_2 ...]<br> # Should-Stop: boot_facility_1 [ boot_facility_2 ...]</font><br> # Default-Start: run_level_1 [ run_level_2 ...]<br> # Default-Stop: run_level_1 [ run_level_2 ...]<br> # Short-Description: short_description<br> # Description: multiline_description</pre>
</td>
</tr>
</tbody>
</table>
<p>Additional keywords may be defined in future LSB specifications. Distributions
may define local extensions by using the prefix "X-[distribution name]" ---
for example, "X-RedHat-foobardecl", or "X-Debian-xyzzydecl". </p>
<p>An init.d shell script may declare using the "Required-Start: " header
that it must not be run until certain boot facilities are provided. This
information is used by the installation tool or the boot-time boot-script
execution facility to assure that init scripts are run in the correct order.
When an init script is run with a "start" argument, the boot facility
or facilities specified in the "Provides" header shall be considered present,
and hence init scripts which require those boot facilities would then be
eligble to be run. When an init script is run with a "stop" argument,
the boot facilities specified in the "Provides" header are considered no
longer present. There are naming conventions for boot facilities and system
facilities, as described in a following section.</p>
<p>Similarly, the "Required-Stop:" header defines which facilities must still
be available during the shutdown of that service. Hence, the init script
system should avoid stopping shell scripts which provide those facilities
until this shell script is stopped.</p>
<p><font color="#33cc00">The "Should-Start:" header defines which facilities
if present should be started before this service. This allows for weak dependencies
which do not cause the service to fail if a facility is not available. But
may cause reduced functionality of the service. Compliant applications should
not rely on the existence of this feature.</font></p>
<p><font color="#33cc00">The "Should-Stop:" header defines which facilities
should be still available during the shutdown of that service.</font></p>
<p>The "Default-Start" and "Default-Stop" headers define which run levels
should by default run the script with a start or stop argument, respectively,
to start or stop the services controlled by the init script.</p>
<p>The "Short-Description" and "Description" header fields are used to provide
text which describes the actions of the init script. The "short_description"
shall be a relatively short, pithy description of the init script, where
as the "multiline_description" can be a much longer piece of text that may
span mulitple lines. In a multiline description, each continuation line
must begin with a '#' followed by tab character or a '#' followed by at least
two space characters. The multiline description is terminated by the first
line that does not match this criteria.</p>
<p>The comment conventions described in this session are only required for
use by LSB-compliant applications; system init scripts as provided by LSB-compliant
run-time environments are <i class="EMPHASIS">not</i> required to use the
scheme outlined here.</p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="INITSRCINSTRM"></a>3.4. Installation and removal
of init.d files</h2>
<p>An init.d file is installed by copying it into /etc/init.d (which may be
a symlink to another location). This can be done by the package installer.
During the package's postinstall script, the program "/usr/lib/lsb/install_initd"
configures the distribution's boot script system to call the package's init.d
file at the appropriate time.</p>
<p>The install_initd program takes a single argument, the pathanme to the
/etc/init.d file. For example:</p>
<table border="0" bgcolor="#e0e0e0" width="100%">
<tbody>
<tr>
<td>
<pre class="SCREEN"> /usr/lib/lsb/install_initd /etc/init.d/example.com-coffeed</pre>
</td>
</tr>
</tbody>
</table>
<p><font color="#33cc00">The install_initd program shall return an exit status
of zero if the init.d file has been successfully installed or if the the
init.d file was already installed. If the required boot facilities cannot
be fulfilled an exit status of one shall be returned and the init.d file
shall not be installed.</font></p>
<p> When a software package is removed, the package's preuninstall script
shall call /usr/lib/lsb/remove_initd and pass the pathname to the /etc/init.d
file. The package manager is still responsible for removing the /etc/init.d
file; the remove_initd program is provided in case the distribution needs
to clean up any other modifications in the distribution's boot script system
that might have been made by the install_initd program. For example:</p>
<table border="0" bgcolor="#e0e0e0" width="100%">
<tbody>
<tr>
<td>
<pre class="SCREEN"> /usr/lib/lsb/remove_initd /etc/init.d/example.com-coffeed</pre>
</td>
</tr>
</tbody>
</table>
<p><font color="#33cc00">The remove_initd program shall return an exit status
of zero if the init.d file has been successfully removed or if the the init.d
file is not installed. If another init.d file which depends on a boot facility
provided by this init.d file is installed, an exit status of one shall be
returned and the init.d file shall remained installed.</font></p>
<p>There should be a tool available to the user (e.g., RedHat's chkconfig)
which can be used by the system administrator to easily manipulate at which
init levels a particular init.d script is started or stopped. This specification
currently does not specify such an interface, however.</p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="RUNLEVELS"></a>3.5. Run Levels</h2>
<p> The following run levels are specified for use by the "Default-Start:"
and "Default-Stop:" specifiers as defined by the section <a
href="#INITSCRCOMCONV"><i>Comment conventions for init scripts</i></a>>.
Many LSB run-time environments commonly use these run level definitions,
and in the absence of other considerations, providers of run-time environments
are strongly encouraged to follow this convention to provide consistency
for system administrators who need to work with multiple distributions.
However, it is not required that LSB-compliant run-time environments use
these run levels; the distribution-provided install_initd script may map
the run levels specified below to whatever distribution-specified run levels
are most appropriate. </p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>0</td>
<td>halt</td>
</tr>
<tr>
<td>1</td>
<td>single user mode</td>
</tr>
<tr>
<td>2</td>
<td>multiuser with no network services exported</td>
</tr>
<tr>
<td>3</td>
<td>normal/full multiuser</td>
</tr>
<tr>
<td>4</td>
<td>reserved for local use, default is normal/full multiuser</td>
</tr>
<tr>
<td>5</td>
<td>multiuser with xdm or equivalent</td>
</tr>
<tr>
<td>6</td>
<td>reboot</td>
</tr>
</tbody>
</table>
<p></p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="FACILNAME"></a>3.6. Facility names</h2>
<p>Boot facilities are used to indicate dependencies in init scripts, as defined
in a previous section. Facility names that begin with a dollar sign ('$')
are system facility names, defined by the LSB, and MUST be provided by distributions.
<a name="AEN18850" href="#FTN.AEN18850">[5]</a> LSB applications must not
provide facilities that begin with a dollar sign. This document defines
the following facility names:</p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>$local_fs</td>
<td>all local filesystems are mounted</td>
</tr>
<tr>
<td>$network</td>
<td>low level networking (ethernet card; may imply PCMCIA running)</td>
</tr>
<tr>
<td>$named</td>
<td>daemons which may provide hostname resolution (if present) are running</td>
</tr>
<tr>
<td>$portmap</td>
<td>daemons providing SunRPC/ONCRPC portmapping service<a
name="AEN18861" href="#FTN.AEN18861">[6]</a> (if present) are running</td>
</tr>
<tr>
<td>$remote_fs</td>
<td>all remote filesystems are mounted<a name="AEN18865"
href="#FTN.AEN18865">[7]</a>.</td>
</tr>
<tr>
<td>$syslog</td>
<td>system logger is operational</td>
</tr>
<tr>
<td>$time</td>
<td>the system time has been set <a name="AEN18871"
href="#FTN.AEN18871">[8]</a></td>
</tr>
</tbody>
</table>
<p></p>
<p>Other (non-system) facilities may be defined by other LSB applications.
These facilities shall be named using the same conventions defined for naming
init.d script names. Commonly, the facility provided by an LSB application
init.d script will have the same name as the name assigned to the init.d
script.</p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="SCRPTNAMES"></a>3.7. Script names</h2>
<p>Since the init.d scripts must live in a single directory, they must come
from a single namespace. Three means of assigning names from this namespace
are available:</p>
<p></p>
<ul>
<li style="list-style-type: disc;">
<p>Assigned namespace. This namespace consists of names which only use
the character set [a-z0-9]. This space is desirable for scripts which system
administrators may often wish to run manually: e.g., "/etc/init.d/named restart"
In order to avoid conflicts these init.d names must be reserved through the
Linux Assigned Names and Numbers Authority (LANANA). Information about
the LANANA may be found at <a href="http://www.lanana.org" target="_top">www.lanana.org</a>.</p>
<p>Commonly used names shall be reserved in advance; developers for
projects should be encouraged to reserve names from LANANA, so that each
distribution can use the same name, and to avoid conflicts with other projects.</p>
</li>
<li style="list-style-type: disc;">
<p>Hierarchical namespace. This namespace consists of scripts names
which look like this: [hier1]-[hier2]-...-[name], where name is again taken
the character set [a-z0-9], and where there may be one or more [hier-n]
components. [hier1] may either be an LSB provider name assigned by the
LANANA, or it may be owners' DNS name in lower case, with at least one '.'
(e.g., "debian.org", "staroffice.sun.com"). The LSB provider name assigned
by LANANA must only consist of the ASCII characters [a-z0-9].</p>
</li>
<li style="list-style-type: disc;">
<p>Reserved namespace. This namespace consists of script names which
begin with the character '_', and is reserved for distribution use only.
This namespace should be used for core packages only, and in general use
of this namespace is highly discouraged. </p>
</li>
</ul>
<p>In general, if a package or some system function is likely to be used on
multiple systems, the package developers or the distribution SHOULD get a
registered name through LANANA, and distributions should strive to use the
same name whenever possible. For applications which may not be "core" or
may not be commonly installed, the hierarchical namespace may be more appropriate.
An advantage to the hierarchical namespace is that there is no need to consult
with the LANANA before obtaining an assigned name.</p>
<p>Short names are highly desirable, since many system administrators like
to use them to manually start and stop services. Given this, they should
be standardized on a per-package basis. This is the rationale behind having
a LANANA organization to assign these names. The LANANA may be called upon
to handle other namespace issues, such as package/prerequisites naming (which
is essential to making prerequisites to work correctly).</p>
</div>
<div class="SECT1">
<hr>
<h2 class="SECT1"><a name="INISCRPTFUNC"></a>3.8. Init script Functions</h2>
<p>Each LSB-compliant init.d script must source the file /lib/lsb/init-functions.
This file must cause the following shell script commands to be defined.
This can be done either by adding a directory to the PATH variable which
defines these commands, or by defining sh aliases. While the distribution-provided
aliases may choose to use bash extensions (at the distribution's option),
the LSB init.d files themselves should only depend in /bin/sh features as
defined by POSIX.2.</p>
<p></p>
<table border="0">
<tbody>
<tr>
<td>start_daemon [-f] [-n nicelevel] [-p pidfile] pathname [args]</td>
<td>This runs the specified program as a daemon. start_daemon will
check to see if there is a program named "daemon" already running. If so,
it will not start another copy of the daemon unless the -f option is given.
The -n option specifies a nice level. See nice(1). <font color="#33cc00">start_daemon
should return the LSB defined exit status codes. It shall return 0 if the
program has been successfully started or is running and not 0 otherwise.</font></td>
</tr>
<tr>
<td>killproc [-p pidfile] pathname [signal]</td>
<td>This stops the specified program. The program is found using the
algorithm given by pidofproc. If a signal is specified, using the -<tt
class="REPLACEABLE"><i>signal_name</i></tt> or -<tt class="REPLACEABLE"><i>signal_number</i></tt>
syntaxes specified by the <b class="COMMAND">kill</b> command, the program
is sent that signal. Otherwise, a SIGTERM followed by a SIGKILL after some
number of seconds is sent.<font color="#33cc00"> Compliant applications may
use the basename instead of the pathname. killproc should return the LSB
defined exit status codes. If called without a signal, it shall return 0
if the program has been stopped or is not running and not 0 otherwise. If
a signal is given, it shall return 0 only if the program is running.</font>
</td>
</tr>
<tr>
<td>pidofproc [-p pidfile] pathname</td>
<td>This function returns one or more pid(s) for a particular daemon.
If an entry is found in /var/run/basename.pid, then that value is returned.
If the -p option is used, the given pidfile is used instead. Compliant applications
may use the basename instead of the pathname. Compliant implementations of
the LSB may attempt other mechanisms for determining the pid(s), although
this is not required (and not recommended, since a user can trick startup
scripts by creating processes that appear to be system programs in the process
list thus creating a potential security exposure). Hence, LSB-complaint applications
who wish to use the pidofproc function in their init scripts must store the
pid in /var/run/basename.pid. <font color="#33cc00">pidofproc should return
the LSB defined exist status codes for "status". It shall return 0 if the
program is the process is running and not 0 otherwise.</font></td>
</tr>
<tr>
<td>log_success_msg "message"</td>
<td>This requests the distribution to print a success message. The
message should be relatively short; no more than 60 characters is highly
desirable.</td>
</tr>
<tr>
<td>log_failure_msg "message"</td>
<td>This requests the distribution to print a failure message. The
message should be relatively short; no more than 60 characters is highly
desirable.</td>
</tr>
<tr>
<td>log_warning_msg "message"</td>
<td>This requests the distribution to print a warning message. The
message should be relatively short; no more than 60 characters is highly
desirable.</td>
</tr>
</tbody>
</table>
<p></p>
</div>
</div>
<h3 class="FOOTNOTES">Notes</h3>
<table border="0" class="FOOTNOTES" width="100%">
<tbody>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.STD-231-65"
href="#STD-231-65">[1]</a></td>
<td align="left" valign="top" width="95%">
<p><font color="#33cc00">ISO/IEC 14882: 1998(E) Programming languages
--C++</font></p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.STD-231-10"
href="#STD-231-10">[2]</a></td>
<td align="left" valign="top" width="95%">
<p>Linux Standard Base</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18803"
href="#AEN18803">[3]</a></td>
<td align="left" valign="top" width="95%">
<p>This specification does not require, but is designed to allow, the
development of a system which runs boot scripts in parallel. Hence, enforced-serialization
of scripts is avoided unless it is explicitly necessary. </p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18806"
href="#AEN18806">[4]</a></td>
<td align="left" valign="top" width="95%">
<p>More than one space, or a tab character, indicates the continuation
line.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18850"
href="#AEN18850">[5]</a></td>
<td align="left" valign="top" width="95%">
<p>The dollar sign does not indicate variable expansion as in many
Linux utilities. Starting a facility name with a dollar sign is merely a
way of dividing the namespace between the system and applications.</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18861"
href="#AEN18861">[6]</a></td>
<td align="left" valign="top" width="95%">
<p>as defined in RFC 1833</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18865"
href="#AEN18865">[7]</a></td>
<td align="left" valign="top" width="95%">
<p>In some LSB run-time environments, filesystems such as /usr may
be remote. Many applications that require $local_fs will probably require
also require $remote_fs</p>
</td>
</tr>
<tr>
<td align="left" valign="top" width="5%"><a name="FTN.AEN18871"
href="#AEN18871">[8]</a></td>
<td align="left" valign="top" width="95%">
<p>i.e., using a network-based time program such as ntp or rdate, or
via the hardware Real Time Clock</p>
</td>
</tr>
</tbody>
</table>
<br>
</body>
</html>