Gecko [ fernandoquevedodop.com ]

Name	Size	Permission
_images	[ DIR ]	drwxr-xr-x
_sources	[ DIR ]	drwxr-xr-x
_static	[ DIR ]	drwxr-xr-x
ap-flowcharts.html	7.02 KB	-rw-r--r--
ap-license.html	4.8 KB	-rw-r--r--
ap-pkg-alternatives.html	6.79 KB	-rw-r--r--
ap-pkg-binarypkg.html	17.44 KB	-rw-r--r--
ap-pkg-conffiles.html	12.14 KB	-rw-r--r--
ap-pkg-controlfields.html	12.4 KB	-rw-r--r--
ap-pkg-diversions.html	11.4 KB	-rw-r--r--
ap-pkg-scope.html	7.81 KB	-rw-r--r--
ap-pkg-sourcepkg.html	33.32 KB	-rw-r--r--
ap-process.html	18.49 KB	-rw-r--r--
ch-archive.html	28.57 KB	-rw-r--r--
ch-binary.html	38.01 KB	-rw-r--r--
ch-controlfields.html	107.38 KB	-rw-r--r--
ch-customized-programs.html	53.09 KB	-rw-r--r--
ch-docs.html	33.97 KB	-rw-r--r--
ch-files.html	69.51 KB	-rw-r--r--
ch-maintainerscripts.html	40.34 KB	-rw-r--r--
ch-opersys.html	84.18 KB	-rw-r--r--
ch-relationships.html	67.18 KB	-rw-r--r--
ch-scope.html	18.54 KB	-rw-r--r--
ch-sharedlibs.html	88.6 KB	-rw-r--r--
ch-source.html	79.4 KB	-rw-r--r--
genindex.html	3.48 KB	-rw-r--r--
index.html	59.51 KB	-rw-r--r--
objects.inv	4.75 KB	-rw-r--r--
search.html	2.99 KB	-rw-r--r--
searchindex.js	58.77 KB	-rw-r--r--
upgrading-checklist.html	121.38 KB	-rw-r--r--

Code Editor : ch-opersys.html

<!DOCTYPE html>

<title>9. The Operating System &#8212; Debian Policy Manual v4.6.0.1</title>
 <link rel="stylesheet" type="text/css" href="_static/pygments.css" />
 <link rel="stylesheet" type="text/css" href="_static/nature.css" />
 <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
 <script src="_static/jquery.js"></script>
 <script src="_static/underscore.js"></script>
 <script src="_static/doctools.js"></script>
 <link rel="index" title="Index" href="genindex.html" />
 <link rel="search" title="Search" href="search.html" />
 <link rel="next" title="10. Files" href="ch-files.html" />
 <link rel="prev" title="8. Shared libraries" href="ch-sharedlibs.html" /> 
 </head><body>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 accesskey="I">index</a></li>
 <li class="right" >
 <a href="ch-files.html" title="10. Files"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="ch-sharedlibs.html" title="8. Shared libraries"
 accesskey="P">previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">9. The Operating System</a></li> 
 </ul>
 </div>

<div class="document">
 <div class="documentwrapper">
 <div class="bodywrapper">
 <div class="body" role="main">
 
 <section id="the-operating-system">
<h1>9. The Operating System<a class="headerlink" href="#the-operating-system" title="Permalink to this headline">¶</a></h1>
<section id="file-system-hierarchy">
<h2>9.1. File system hierarchy<a class="headerlink" href="#file-system-hierarchy" title="Permalink to this headline">¶</a></h2>
<section id="file-system-structure">
<h3>9.1.1. File System Structure<a class="headerlink" href="#file-system-structure" title="Permalink to this headline">¶</a></h3>
The location of all files and directories must comply with the
Filesystem Hierarchy Standard (FHS), version 3.0, with the exceptions
noted below, and except where doing so would violate other terms of
Debian Policy. The following exceptions to the FHS apply:
<ol class="arabic">
<li>The FHS requirement that architecture-independent
application-specific static files be located in <code class="docutils literal notranslate">/usr/share</code> is
relaxed to a suggestion. In particular, a subdirectory of
<code class="docutils literal notranslate">/usr/lib</code> may be used by a package (or a collection of packages)
to hold a mixture of architecture-independent and
architecture-dependent files. However, when a directory is entirely
composed of architecture-independent files, it should be located in
<code class="docutils literal notranslate">/usr/share</code>.</li>
<li>The optional rules related to user specific configuration files for
applications are stored in the user’s home directory are relaxed. It
is recommended that such files start with the ‘<code class="docutils literal notranslate">.</code>’ character (a
“dot file”), and if an application needs to create more than one dot
file then the preferred placement is in a subdirectory with a name
starting with a ‘.’ character, (a “dot directory”). In this case it
is recommended the configuration files not start with the ‘.’
character.</li>
<li>Only the dynamic linker and libc are allowed to install files
in <code class="docutils literal notranslate">/lib64</code>.</li>
<li>The requirement for object files, internal binaries, and libraries,
including <code class="docutils literal notranslate">libc.so.*</code>, to be located directly under <code class="docutils literal notranslate">/lib{,32}</code>
and <code class="docutils literal notranslate">/usr/lib{,32}</code> is amended, permitting files to instead be
installed to <code class="docutils literal notranslate">/lib/triplet</code> and <code class="docutils literal notranslate">/usr/lib/triplet</code>, where
<code class="docutils literal notranslate">triplet</code> is the value returned by <code class="docutils literal notranslate">dpkg-architecture -qDEB_HOST_MULTIARCH</code> for the architecture of the
package. Packages must not install files to any triplet path other
than the one matching the architecture of that package; for
instance, an <code class="docutils literal notranslate">Architecture:&#160; amd64</code> package containing 32-bit x86
libraries must not install these libraries to
<code class="docutils literal notranslate">/usr/lib/i386-linux-gnu</code>. <a class="footnote-reference brackets" href="#id7" id="id1">1</a>
Packages must not install files in <code class="docutils literal notranslate">/usr/lib64</code> or in a subdirectory
of it.
The requirement for C and C++ headers files to be accessible through
the search path <code class="docutils literal notranslate">/usr/include/</code> is amended, permitting files to be
accessible through the search path <code class="docutils literal notranslate">/usr/include/triplet</code> where
<code class="docutils literal notranslate">triplet</code> is as above. <a class="footnote-reference brackets" href="#id8" id="id2">2</a>
Applications may also use a single subdirectory under
<code class="docutils literal notranslate">/usr/lib/triplet</code>.
The execution time linker/loader, ld*, must still be made available
in the existing location under /lib or /lib64 since this is part of
the ELF ABI for the architecture.
</li>
<li>The requirement that <code class="docutils literal notranslate">/usr/local/share/man</code> be “synonymous” with
<code class="docutils literal notranslate">/usr/local/man</code> is relaxed to a recommendation</li>
<li>The requirement that window managers with a single configuration file
call it <code class="docutils literal notranslate">system.*wmrc</code> is removed, as is the restriction that the
window manager subdirectory be named identically to the window
manager name itself.</li>
<li>The requirement that boot manager configuration files live in
<code class="docutils literal notranslate">/etc</code>, or at least are symlinked there, is relaxed to a
recommendation.</li>
<li><code class="docutils literal notranslate">/var/run</code> is required to be a symbolic link to <code class="docutils literal notranslate">/run</code>,
and <code class="docutils literal notranslate">/var/lock</code> is required to be a symbolic link to <code class="docutils literal notranslate">/run/lock</code>.</li>
<li>The <code class="docutils literal notranslate">/var/www</code> directory is additionally allowed.</li>
<li>The requirement for <code class="docutils literal notranslate">/usr/local/share/color</code> to exist if
<code class="docutils literal notranslate">/usr/share/color</code> exists is relaxed to a recommendation.</li>
<li>The requirement for <code class="docutils literal notranslate">/usr/local/libqual</code> to exist if <code class="docutils literal notranslate">/libqual</code>
or <code class="docutils literal notranslate">/usr/libqual</code> exists (where <code class="docutils literal notranslate">libqual</code> is a variant of
<code class="docutils literal notranslate">lib</code> such as <code class="docutils literal notranslate">lib32</code> or <code class="docutils literal notranslate">lib64</code>) is removed.</li>
<li>On GNU/Hurd systems, the following additional directories are
allowed in the root filesystem: <code class="docutils literal notranslate">/hurd</code> and <code class="docutils literal notranslate">/servers</code>. <a class="footnote-reference brackets" href="#id9" id="id3">3</a></li>
<li>As an exception to the requirement for there to be no subdirectories
in <code class="docutils literal notranslate">/usr/bin</code>, the <code class="docutils literal notranslate">mh</code> mail-handling suite may create
<code class="docutils literal notranslate">/usr/bin/mh/</code>, as was allowed in FHS version 2.3. Other
subdirectories are not allowed.</li>
</ol>
The version of this document referred here can be found in the
<code class="docutils literal notranslate">debian-policy</code> package or on <a class="reference external" href="https://www.debian.org/doc/packaging-manuals/fhs/">FHS (Debian
copy)</a> alongside
this manual (or, if you have the debian-policy installed, you can try
<a class="reference external" href="file:///usr/share/doc/debian-policy/fhs/">FHS (local copy)</a>). The
latest version, which may be a more recent version, may be found on <a class="reference external" href="http://refspecs.linuxfoundation.org/fhs.shtml">FHS
(upstream)</a>. Specific
questions about following the standard may be asked on the
<code class="docutils literal notranslate">debian-devel</code> mailing list, or referred to the FHS mailing list
(see the <a class="reference external" href="http://refspecs.linuxfoundation.org/fhs.shtml">FHS web site</a>
for more information).
</section>
<section id="site-specific-programs">
<h3>9.1.2. Site-specific programs<a class="headerlink" href="#site-specific-programs" title="Permalink to this headline">¶</a></h3>
As mandated by the FHS, packages must not place any files in
<code class="docutils literal notranslate">/usr/local</code>, either by putting them in the file system archive to be
unpacked by <code class="docutils literal notranslate">dpkg</code> or by manipulating them in their maintainer
scripts.
However, the package may create empty directories below <code class="docutils literal notranslate">/usr/local</code>
so that the system administrator knows where to place site-specific
files. These are not directories in <code class="docutils literal notranslate">/usr/local</code>, but are children
of directories in <code class="docutils literal notranslate">/usr/local</code>. These directories
(<code class="docutils literal notranslate">/usr/local/*/dir/</code>) should be removed on package removal if they are
empty.
Note that this applies only to directories below <code class="docutils literal notranslate">/usr/local</code>, not
in <code class="docutils literal notranslate">/usr/local</code>. Packages must not create sub-directories in the
directory <code class="docutils literal notranslate">/usr/local</code> itself, except those listed in FHS, section
4.9. However, you may create directories below them as you wish. You
must not remove any of the directories listed in 4.9, even if you
created them.
If <code class="docutils literal notranslate">/etc/staff-group-for-usr-local</code> does not exist, <code class="docutils literal notranslate">/usr/local</code>
and all subdirectories created by packages should have permissions
0755 and be owned by <code class="docutils literal notranslate">root:root</code>. If
<code class="docutils literal notranslate">/etc/staff-group-for-usr-local</code> exists, <code class="docutils literal notranslate">/usr/local</code> and
subdirectories should have permissions 2775 (group-writable and
set-group-id) and be owned by <code class="docutils literal notranslate">root:staff</code>.
Since <code class="docutils literal notranslate">/usr/local</code> can be mounted read-only from a remote server,
<code class="docutils literal notranslate">/usr/local/*/dir/</code> directories must be created and removed by the
<code class="docutils literal notranslate">postinst</code> and <code class="docutils literal notranslate">prerm</code> maintainer scripts and not be included in
the <code class="docutils literal notranslate">.deb</code> archive. These scripts must not fail if either of these
operations fail.
For example, the <code class="docutils literal notranslate">emacsen-common</code> package could contain something like
<div class="highlight-default notranslate"><div class="highlight"><pre>if [ ! -e /usr/local/share/emacs ]; then
 if mkdir /usr/local/share/emacs 2&gt;/dev/null; then
 if test -e /etc/staff-group-for-usr-local ; then
 if chown root:staff /usr/local/share/emacs; then
 chmod 2775 /usr/local/share/emacs || true
 fi
 elif chown root:root /usr/local/share/emacs; then
 chmod 0755 /usr/local/share/emacs || true
 fi
 fi
fi
</pre></div>
</div>
in its <code class="docutils literal notranslate">postinst</code> script, and
<div class="highlight-default notranslate"><div class="highlight"><pre>rmdir /usr/local/share/emacs/site-lisp 2&gt;/dev/null || true
rmdir /usr/local/share/emacs 2&gt;/dev/null || true
</pre></div>
</div>
in the <code class="docutils literal notranslate">prerm</code> script. (Note that this form is used to ensure that if
the script is interrupted, the directory <code class="docutils literal notranslate">/usr/local/share/emacs</code> will
still be removed.)
If you do create a directory in <code class="docutils literal notranslate">/usr/local</code> for local additions to a
package, you should ensure that settings in <code class="docutils literal notranslate">/usr/local</code> take
precedence over the equivalents in <code class="docutils literal notranslate">/usr</code>.
However, because <code class="docutils literal notranslate">/usr/local</code> and its contents are for exclusive use
of the local administrator, a package must not rely on the presence or
absence of files or directories in <code class="docutils literal notranslate">/usr/local</code> for normal operation.
</section>
<section id="the-system-wide-mail-directory">
<h3>9.1.3. The system-wide mail directory<a class="headerlink" href="#the-system-wide-mail-directory" title="Permalink to this headline">¶</a></h3>
The system-wide mail directory is <code class="docutils literal notranslate">/var/mail</code>. This directory is part
of the base system and should not be owned by any particular mail
agents. The use of the old location <code class="docutils literal notranslate">/var/spool/mail</code> is deprecated,
even though the spool may still be physically located there.
</section>
<section id="run-and-run-lock">
<h3>9.1.4. <code class="docutils literal notranslate">/run</code> and <code class="docutils literal notranslate">/run/lock</code><a class="headerlink" href="#run-and-run-lock" title="Permalink to this headline">¶</a></h3>
The directory <code class="docutils literal notranslate">/run</code> is cleared at boot, normally by being a mount
point for a temporary file system. Packages therefore must not assume
that any files or directories under <code class="docutils literal notranslate">/run</code> other than <code class="docutils literal notranslate">/run/lock</code>
exist unless the package has arranged to create those files or
directories since the last reboot. Normally, this is done by the package
via an init script. See <a class="reference internal" href="#s-writing-init">Writing the scripts</a> for more
information.
Packages must not include files or directories under <code class="docutils literal notranslate">/run</code>, or under
the older <code class="docutils literal notranslate">/var/run</code> and <code class="docutils literal notranslate">/var/lock</code> paths. The latter paths will
normally be symlinks or other redirections to <code class="docutils literal notranslate">/run</code> for backwards
compatibility.
</section>
</section>
<section id="users-and-groups">
<h2>9.2. Users and groups<a class="headerlink" href="#users-and-groups" title="Permalink to this headline">¶</a></h2>
<section id="introduction">
<h3>9.2.1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h3>
The Debian system can be configured to use either plain or shadow
passwords.
Some user ids (UIDs) and group ids (GIDs) are reserved globally for use
by certain packages. Because some packages need to include files which
are owned by these users or groups, or need the ids compiled into
binaries, these ids must be used on any Debian system only for the
purpose for which they are allocated. This is a serious restriction, and
we should avoid getting in the way of local administration policies. In
particular, many sites allocate users and/or local system groups
starting at 100.
Apart from this we should have dynamically allocated ids, which should
by default be arranged in some sensible order, but the behavior should
be configurable. When maintainers choose a new hardcoded or dynamically
generated username for packages to use, they should start this username
with an underscore. This minimizes collisions with locally created user
accounts.
Packages other than <code class="docutils literal notranslate">base-passwd</code> must not modify <code class="docutils literal notranslate">/etc/passwd</code>,
<code class="docutils literal notranslate">/etc/shadow</code>, <code class="docutils literal notranslate">/etc/group</code> or <code class="docutils literal notranslate">/etc/gshadow</code>.
</section>
<section id="uid-and-gid-classes">
<h3>9.2.2. UID and GID classes<a class="headerlink" href="#uid-and-gid-classes" title="Permalink to this headline">¶</a></h3>
The UID and GID numbers are divided into classes as follows:
<dl>
<dt>0-99:</dt><dd>Globally allocated by the Debian project, the same on every Debian
system. These ids will appear in the <code class="docutils literal notranslate">passwd</code> and <code class="docutils literal notranslate">group</code> files
of all Debian systems, new ids in this range being added
automatically as the <code class="docutils literal notranslate">base-passwd</code> package is updated.
Packages which need a single statically allocated uid or gid should
use one of these; their maintainers should ask the <code class="docutils literal notranslate">base-passwd</code>
maintainer for ids.
</dd>
<dt>100-999:</dt><dd>Dynamically allocated system users and groups. Packages which need a
user or group, but can have this user or group allocated dynamically
and differently on each system, should use <code class="docutils literal notranslate">adduser --system</code> to
create the group and/or user. <code class="docutils literal notranslate">adduser</code> will check for the
existence of the user or group, and if necessary choose an unused id
based on the ranges specified in <code class="docutils literal notranslate">adduser.conf</code>.
</dd>
<dt>1000-59999:</dt><dd>Dynamically allocated user accounts. By default <code class="docutils literal notranslate">adduser</code> will
choose UIDs and GIDs for user accounts in this range, though
<code class="docutils literal notranslate">adduser.conf</code> may be used to modify this behavior.
</dd>
<dt>60000-64999:</dt><dd>Globally allocated by the Debian project, but only created on
demand. The ids are allocated centrally and statically, but the
actual accounts are only created on users’ systems on demand.
These ids are for packages which are obscure or which require many
statically-allocated ids. These packages should check for and create
the accounts in <code class="docutils literal notranslate">/etc/passwd</code> or <code class="docutils literal notranslate">/etc/group</code> (using <code class="docutils literal notranslate">adduser</code>
if it has this facility) if necessary. Packages which are likely to
require further allocations should have a “hole” left after them in
the allocation, to give them room to grow.
</dd>
<dt>65000-65533:</dt><dd>Reserved.
</dd>
<dt>65534:</dt><dd>User <code class="docutils literal notranslate">nobody</code>. The corresponding gid refers to the group
<code class="docutils literal notranslate">nogroup</code>.
</dd>
<dt>65535:</dt><dd>This value must not be used, because it was the error return
sentinel value when <code class="docutils literal notranslate">uid_t</code> was 16 bits.
</dd>
<dt>65536-4294967293:</dt><dd>Dynamically allocated user accounts. By default <code class="docutils literal notranslate">adduser</code> will not
allocate UIDs and GIDs in this range, to ease compatibility with
legacy systems where <code class="docutils literal notranslate">uid_t</code> is still 16 bits.
</dd>
<dt>4294967294:</dt><dd><code class="docutils literal notranslate">(uid_t)(-2) == (gid_t)(-2)</code> must not be used, because it is
used as the anonymous, unauthenticated user by some NFS
implementations.
</dd>
<dt>4294967295:</dt><dd><code class="docutils literal notranslate">(uid_t)(-1) == (gid_t)(-1)</code> must not be used, because it is the
error return sentinel value.
</dd>
</dl>
</section>
<section id="non-existent-home-directories">
<h3>9.2.3. Non-existent home directories<a class="headerlink" href="#non-existent-home-directories" title="Permalink to this headline">¶</a></h3>
The canonical non-existent home directory is <code class="docutils literal notranslate">/nonexistent</code>. Users
who should not have a home directory should have their home directory
set to this value.
The Debian autobuilders set HOME to <code class="docutils literal notranslate">/nonexistent</code> so that packages
which try to write to a home directory will fail to build.
</section>
</section>
<section id="starting-system-services">
<h2>9.3. Starting system services<a class="headerlink" href="#starting-system-services" title="Permalink to this headline">¶</a></h2>
<section id="s-services-intro">
<h3>9.3.1. Introduction<a class="headerlink" href="#s-services-intro" title="Permalink to this headline">¶</a></h3>
Packages that include system services should include <code class="docutils literal notranslate">systemd</code> service
units to start or stop those services. See systemd.service(5)
for details on the syntax of a service unit file. In the common case that
a package includes a single system service, the service unit should have
the same name as the package plus the <code class="docutils literal notranslate">.service</code> extension.
If the package does not include a service unit (if, for example, no one
has yet written one), including an init script, as described below, to
start the service is encouraged.
Packages including a service unit may optionally include an init script to
support other init systems. In this case, the init script should have the
same name as the <code class="docutils literal notranslate">systemd</code> service unit so that <code class="docutils literal notranslate">systemd</code> will ignore
it and use the service unit instead. Packages may also support other init
systems by including configuration in the native format of those init
systems.
If a service unit is not present, <code class="docutils literal notranslate">systemd</code> uses dependency information
contained within the init scripts and symlinks in <code class="docutils literal notranslate">/etc/rcn.d</code> to decide
which scripts to run and in which order. The <code class="docutils literal notranslate">sysv-rc</code> runlevel system
for <code class="docutils literal notranslate">sysvinit</code> uses the same symlinks in <code class="docutils literal notranslate">/etc/rcn.d</code> to decide which
scripts to run and in which order at boot time and when the init state (or
“runlevel”) is changed. See the <code class="docutils literal notranslate">README.runlevels</code> file shipped with
<code class="docutils literal notranslate">sysv-rc</code> for implementation details. Other alternatives might exist.
The sections below describe how to write those scripts and configure those
symlinks.
</section>
<section id="writing-the-scripts">
<h3>9.3.2. Writing the scripts<a class="headerlink" href="#writing-the-scripts" title="Permalink to this headline">¶</a></h3>
Init scripts are placed in <code class="docutils literal notranslate">/etc/init.d</code>. In the common case that a
package starts a single service, they should be named
<code class="docutils literal notranslate">/etc/init.d/package</code>. They should accept one argument, saying what to
do:
<dl class="simple">
<dt><code class="docutils literal notranslate">start</code></dt><dd>start the service,
</dd>
<dt><code class="docutils literal notranslate">stop</code></dt><dd>stop the service,
</dd>
<dt><code class="docutils literal notranslate">restart</code></dt><dd>stop and restart the service if it’s already running, otherwise
start the service
</dd>
<dt><code class="docutils literal notranslate">try-restart</code></dt><dd>restart the service if it’s already running, otherwise just report
success.
</dd>
<dt><code class="docutils literal notranslate">reload</code></dt><dd>cause the configuration of the service to be reloaded without
actually stopping and restarting the service,
</dd>
<dt><code class="docutils literal notranslate">force-reload</code></dt><dd>cause the configuration to be reloaded if the service supports this,
otherwise restart the service.
</dd>
<dt><code class="docutils literal notranslate">status</code></dt><dd>report the current status of the service
</dd>
</dl>
The <code class="docutils literal notranslate">start</code>, <code class="docutils literal notranslate">stop</code>, <code class="docutils literal notranslate">restart</code>, and <code class="docutils literal notranslate">force-reload</code> options should
be supported by all init scripts. Supporting <code class="docutils literal notranslate">status</code> is encouraged.
The <code class="docutils literal notranslate">reload</code> and <code class="docutils literal notranslate">try-restart</code> options are optional.
The <code class="docutils literal notranslate">init.d</code> scripts must ensure that they will behave sensibly (i.e.,
returning success and not starting multiple copies of a service) if
invoked with <code class="docutils literal notranslate">start</code> when the service is already running, or with
<code class="docutils literal notranslate">stop</code> when it isn’t, and that they don’t kill unfortunately-named
user processes. The best way to achieve this is usually to use
<code class="docutils literal notranslate">start-stop-daemon</code> with the <code class="docutils literal notranslate">--oknodo</code> option.
Be careful of using <code class="docutils literal notranslate">set -e</code> in <code class="docutils literal notranslate">init.d</code> scripts. Writing correct
<code class="docutils literal notranslate">init.d</code> scripts requires accepting various error exit statuses when
daemons are already running or already stopped without aborting the
<code class="docutils literal notranslate">init.d</code> script, and common <code class="docutils literal notranslate">init.d</code> function libraries are not safe
to call with <code class="docutils literal notranslate">set -e</code> in effect. <a class="footnote-reference brackets" href="#id10" id="id5">4</a> For <code class="docutils literal notranslate">init.d</code> scripts, it’s
often easier to not use <code class="docutils literal notranslate">set -e</code> and instead check the result of each
command separately.
If a service reloads its configuration automatically (as in the case of
<code class="docutils literal notranslate">cron</code>, for example), the <code class="docutils literal notranslate">reload</code> option of the <code class="docutils literal notranslate">init.d</code> script
should behave as if the configuration has been reloaded successfully.
The <code class="docutils literal notranslate">/etc/init.d</code> scripts must be treated as configuration files,
either (if they are present in the package, that is, in the .deb file)
by marking them as <code class="docutils literal notranslate">conffile</code>s, or, (if they do not exist in the
.deb) by managing them correctly in the maintainer scripts (see
<a class="reference internal" href="ch-files.html#s-config-files">Configuration files</a>). This is important since we want
to give the local system administrator the chance to adapt the scripts
to the local system, e.g., to disable a service without de-installing
the package, or to specify some special command line options when
starting a service, while making sure their changes aren’t lost during
the next package upgrade.
These scripts should not fail obscurely when the configuration files
remain but the package has been removed, as configuration files remain
on the system after the package has been removed. Only when <code class="docutils literal notranslate">dpkg</code> is
executed with the <code class="docutils literal notranslate">--purge</code> option will configuration files be
removed. In particular, as the <code class="docutils literal notranslate">/etc/init.d/package</code> script itself is
usually a <code class="docutils literal notranslate">conffile</code>, it will remain on the system if the package is
removed but not purged. Therefore, you should include a <code class="docutils literal notranslate">test</code>
statement at the top of the script, like this:
<div class="highlight-default notranslate"><div class="highlight"><pre>test -f program-executed-later-in-script || exit 0
</pre></div>
</div>
Often there are some variables in the <code class="docutils literal notranslate">init.d</code> scripts whose values
control the behavior of the scripts, and which a system administrator is
likely to want to change. As the scripts themselves are frequently
<code class="docutils literal notranslate">conffile</code>s, modifying them requires that the administrator merge in
their changes each time the package is upgraded and the <code class="docutils literal notranslate">conffile</code>
changes. To ease the burden on the system administrator, such
configurable values should not be placed directly in the script.
Instead, they should be placed in a file in <code class="docutils literal notranslate">/etc/default</code>, which
typically will have the same base name as the <code class="docutils literal notranslate">init.d</code> script. This
extra file should be sourced by the script when the script runs. It must
contain only variable settings and comments in POSIX.1-2017 <code class="docutils literal notranslate">sh</code> format. It
must either be a <code class="docutils literal notranslate">conffile</code> or a configuration file maintained by the
package maintainer scripts. See <a class="reference internal" href="ch-files.html#s-config-files">Configuration files</a> for
more details.
To ensure that vital configurable values are always available, the
<code class="docutils literal notranslate">init.d</code> script should set default values for each of the shell
variables it uses, either before sourcing the <code class="docutils literal notranslate">/etc/default/</code> file or
afterwards using something like the <code class="docutils literal notranslate">: ${VAR:=default}</code> syntax. Also,
the <code class="docutils literal notranslate">init.d</code> script must behave sensibly and not fail if the
<code class="docutils literal notranslate">/etc/default</code> file is deleted.
Files and directories under <code class="docutils literal notranslate">/run</code>, including ones referred to via the
compatibility paths <code class="docutils literal notranslate">/var/run</code> and <code class="docutils literal notranslate">/var/lock</code>, are normally stored
on a temporary filesystem and are normally not persistent across a
reboot. The <code class="docutils literal notranslate">init.d</code> scripts must handle this correctly. This will
typically mean creating any required subdirectories dynamically when the
<code class="docutils literal notranslate">init.d</code> script is run. See <a class="reference internal" href="#s-fhs-run">/run and /run/lock</a> for more
information.
</section>
<section id="interfacing-with-init-systems">
<h3>9.3.3. Interfacing with init systems<a class="headerlink" href="#interfacing-with-init-systems" title="Permalink to this headline">¶</a></h3>
Maintainer scripts for packages including init scripts must use
<code class="docutils literal notranslate">update-rc.d</code> as described below to interact with the service manager
for requests such as enabling or disabling services. They should use
<code class="docutils literal notranslate">invoke-rc.d</code> as described below to invoke init scripts for requests
such as starting and stopping service.
Directly managing the <code class="docutils literal notranslate">/etc/rc?.d</code> links and directly invoking the
<code class="docutils literal notranslate">/etc/init.d/</code> init scripts should be done only by packages providing
the init script subsystem (such as <code class="docutils literal notranslate">init-system-helpers</code>).
<section id="managing-the-links">
<h4>9.3.3.1. Managing the links<a class="headerlink" href="#managing-the-links" title="Permalink to this headline">¶</a></h4>
The program <code class="docutils literal notranslate">update-rc.d</code> is provided for package maintainers to
arrange for the proper creation and removal of <code class="docutils literal notranslate">/etc/rcn.d</code> symbolic
links, or their functional equivalent if another method is being used.
It is intended for use in package maintainer scripts.
You must not include any <code class="docutils literal notranslate">/etc/rcn.d</code> symbolic links in the actual
archive or manually create or remove the symbolic links in maintainer
scripts; you must use the <code class="docutils literal notranslate">update-rc.d</code> program instead. (The former
will fail if an alternative method of maintaining runlevel information
is being used.) You must not include the <code class="docutils literal notranslate">/etc/rcn.d</code> directories
themselves in the archive either. (Only the <code class="docutils literal notranslate">init-system-helpers</code>
package is permitted to do so.)
To get the default behavior for your package, put in your <code class="docutils literal notranslate">postinst</code>
script:
<div class="highlight-default notranslate"><div class="highlight"><pre>update-rc.d package defaults
</pre></div>
</div>
and in your <code class="docutils literal notranslate">postrm</code>:
<div class="highlight-default notranslate"><div class="highlight"><pre>if [ &quot;$1&quot; = purge ]; then
 update-rc.d package remove
fi
</pre></div>
</div>
The default behaviour is to enable autostarting your package’s daemon.
The local administrator can override this using the command
<code class="docutils literal notranslate">update-rc.d package disable</code>. If, however, the daemon should not
be autostarted unless the local administrator has explicitly requested
this, instead add to your <code class="docutils literal notranslate">postinst</code> script:
<div class="highlight-default notranslate"><div class="highlight"><pre>update-rc.d package defaults-disabled
</pre></div>
</div>
and add a dependency on <code class="docutils literal notranslate">init-system-helpers (&gt;= 1.50)</code>, which
introduced the <code class="docutils literal notranslate">defaults-disabled</code> option. Then the local
administrator can enable autostarting the daemon using the command
<code class="docutils literal notranslate">update-rc.d package enable</code>.
An older practice, which should not be used, was to include a line
like <code class="docutils literal notranslate">DISABLED=yes</code> in the package’s <code class="docutils literal notranslate">/etc/default</code> file. The
package’s init script would not start the service until the local
system administrator changed this to <code class="docutils literal notranslate">DISABLED=no</code>, or similar. The
problem with this approach was that it hides from the init system
whether or not the daemon should actually be started, which leads to
inconsistent and confusing behavior: <code class="docutils literal notranslate">service &lt;package&gt; start</code> could
return success but not start the service; services with a dependency
on this service will be started even though the service isn’t running;
and init system status commands could incorrectly claim that the service
was started.
Note that if your package changes runlevels or priority, you may have to
remove and recreate the links, since otherwise the old links may
persist. Refer to the documentation of <code class="docutils literal notranslate">update-rc.d</code>.
For more information about using <code class="docutils literal notranslate">update-rc.d</code>, please consult its man
page, update-rc.d(8).
It is easiest for packages not to call <code class="docutils literal notranslate">update-rc.d</code> directly, but
instead use debhelper programs that add the required <code class="docutils literal notranslate">update-rc.d</code>
calls automatically. See <code class="docutils literal notranslate">dh_installinit</code>, <code class="docutils literal notranslate">dh_installsystemd</code>, etc.
</section>
<section id="running-init-scripts">
<h4>9.3.3.2. Running init scripts<a class="headerlink" href="#running-init-scripts" title="Permalink to this headline">¶</a></h4>
The program <code class="docutils literal notranslate">invoke-rc.d</code> is provided to make it easier for package
maintainers to properly invoke an init script, obeying runlevel and other
locally-defined constraints that might limit a package’s right to start,
stop and otherwise manage services. This program may be used by
maintainers in their packages’ scripts.
The package maintainer scripts must use <code class="docutils literal notranslate">invoke-rc.d</code> to invoke the
<code class="docutils literal notranslate">/etc/init.d/*</code> init scripts or equivalent instead of calling them
directly.
By default, <code class="docutils literal notranslate">invoke-rc.d</code> will pass any action requests (start, stop,
reload, restart…) to the <code class="docutils literal notranslate">/etc/init.d</code> script, filtering out
requests to start or restart a service out of its intended runlevels.
Most packages will simply use:
<div class="highlight-default notranslate"><div class="highlight"><pre>invoke-rc.d package action
</pre></div>
</div>
in their <code class="docutils literal notranslate">postinst</code> and <code class="docutils literal notranslate">prerm</code> scripts.
A package should register its init script services using <code class="docutils literal notranslate">update-rc.d</code>
before it tries to invoke them using <code class="docutils literal notranslate">invoke-rc.d</code>. Invocation of
unregistered services may fail.
For more information about using <code class="docutils literal notranslate">invoke-rc.d</code>, please consult its man
page, invoke-rc.d(8).
It is easiest for packages not to call <code class="docutils literal notranslate">invoke-rc.d</code> directly, but
instead use debhelper programs that add the required <code class="docutils literal notranslate">invoke-rc.d</code>
calls automatically. See <code class="docutils literal notranslate">dh_installinit</code>, <code class="docutils literal notranslate">dh_installsystemd</code>, etc.
</section>
</section>
<section id="boot-time-initialization">
<h3>9.3.4. Boot-time initialization<a class="headerlink" href="#boot-time-initialization" title="Permalink to this headline">¶</a></h3>
This section has been deleted.
</section>
<section id="example">
<h3>9.3.5. Example<a class="headerlink" href="#example" title="Permalink to this headline">¶</a></h3>
Examples on which you can base your <code class="docutils literal notranslate">systemd</code> service units are
available in the man page systemd.unit(5). An example on which
you can base your init scripts is available in the man page
init-d-script(5).
</section>
</section>
<section id="console-messages-from-init-d-scripts">
<h2>9.4. Console messages from <code class="docutils literal notranslate">init.d</code> scripts<a class="headerlink" href="#console-messages-from-init-d-scripts" title="Permalink to this headline">¶</a></h2>
This section has been deleted.
</section>
<section id="cron-jobs">
<h2>9.5. Cron jobs<a class="headerlink" href="#cron-jobs" title="Permalink to this headline">¶</a></h2>
Packages must not modify the configuration file <code class="docutils literal notranslate">/etc/crontab</code>, and
they must not modify the files in <code class="docutils literal notranslate">/var/spool/cron/crontabs</code>.
If a package wants to install a job that has to be executed via cron, it
should place a file named as specified in
<a class="reference internal" href="#s-cron-files">Cron job file names</a> into one or more of the following
directories:
<ul class="simple">
<li><code class="docutils literal notranslate">/etc/cron.hourly</code></li>
<li><code class="docutils literal notranslate">/etc/cron.daily</code></li>
<li><code class="docutils literal notranslate">/etc/cron.weekly</code></li>
<li><code class="docutils literal notranslate">/etc/cron.monthly</code></li>
</ul>
As these directory names imply, the files within them are executed on an
hourly, daily, weekly, or monthly basis, respectively. The exact times
are listed in <code class="docutils literal notranslate">/etc/crontab</code>.
All files installed in any of these directories must be scripts (e.g.,
shell scripts or Perl scripts) so that they can easily be modified by
the local system administrator. In addition, they must be treated as
configuration files.
If a certain job has to be executed at some other frequency or at a
specific time, the package should install a file in <code class="docutils literal notranslate">/etc/cron.d</code> with
a name as specified in <a class="reference internal" href="#s-cron-files">Cron job file names</a>. This file
uses the same syntax as <code class="docutils literal notranslate">/etc/crontab</code> and is processed by <code class="docutils literal notranslate">cron</code>
automatically. The file must also be treated as a configuration file.
(Note that entries in the <code class="docutils literal notranslate">/etc/cron.d</code> directory are not handled by
<code class="docutils literal notranslate">anacron</code>. Thus, you should only use this directory for jobs which may
be skipped if the system is not running.)
Unlike <code class="docutils literal notranslate">crontab</code> files described in the IEEE Std 1003.1-2008 (POSIX.1)
available from <a class="reference external" href="https://www.opengroup.org/onlinepubs/9699919799/">The Open
Group</a>, the files
in <code class="docutils literal notranslate">/etc/cron.d</code> and the file <code class="docutils literal notranslate">/etc/crontab</code> have seven fields;
namely:
<ol class="arabic simple">
<li>Minute [0,59]</li>
<li>Hour [0,23]</li>
<li>Day of the month [1,31]</li>
<li>Month of the year [1,12]</li>
<li>Day of the week ([0,6] with 0=Sunday)</li>
<li>Username</li>
<li>Command to be run</li>
</ol>
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. Lists are allowed. A list is a
set of numbers (or ranges) separated by commas. Step values can be used
in conjunction with ranges.
The scripts or <code class="docutils literal notranslate">crontab</code> entries in these directories should 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 configuration files are kept on the system in this situation.
Any <code class="docutils literal notranslate">cron</code> daemon must provide <code class="docutils literal notranslate">/usr/bin/crontab</code> and support normal
<code class="docutils literal notranslate">crontab</code> entries as specified in POSIX. The daemon must also support
names for days and months, ranges, and step values. It has to support
<code class="docutils literal notranslate">/etc/crontab</code>, and correctly execute the scripts in <code class="docutils literal notranslate">/etc/cron.d</code>.
The daemon must also correctly execute scripts in
<code class="docutils literal notranslate">/etc/cron.{hourly,daily,weekly,monthly}</code>.
<section id="cron-job-file-names">
<h3>9.5.1. Cron job file names<a class="headerlink" href="#cron-job-file-names" title="Permalink to this headline">¶</a></h3>
The file name of a cron job file should normally match the name of the
package from which it comes.
If a package supplies multiple cron job files files in the same
directory, the file names should all start with the name of the package
(possibly modified as described below) followed by a hyphen (<code class="docutils literal notranslate">-</code>) and
a suitable suffix.
A cron job file name must not include any period or plus characters
(<code class="docutils literal notranslate">.</code> or <code class="docutils literal notranslate">+</code>) characters as this will cause cron to ignore the file.
Underscores (<code class="docutils literal notranslate">_</code>) should be used instead of <code class="docutils literal notranslate">.</code> and <code class="docutils literal notranslate">+</code>
characters.
</section>
</section>
<section id="menus">
<h2>9.6. Menus<a class="headerlink" href="#menus" title="Permalink to this headline">¶</a></h2>
Packages shipping applications that comply with minimal requirements
described below for integration with desktop environments should
register these applications in the desktop menu, following the
FreeDesktop standard, using text files called desktop entries. Their
format is described in the Desktop Entry Specification at
<a class="reference external" href="https://standards.freedesktop.org/desktop-entry-spec/latest/">https://standards.freedesktop.org/desktop-entry-spec/latest/</a> and
complementary information can be found in the Desktop Menu
Specification at <a class="reference external" href="https://standards.freedesktop.org/menu-spec/latest/">https://standards.freedesktop.org/menu-spec/latest/</a>.
The desktop entry files are installed by the packages in the directory
<code class="docutils literal notranslate">/usr/share/applications</code> and the FreeDesktop menus are refreshed
using dpkg triggers. It is therefore not necessary to depend on
packages providing FreeDesktop menu systems.
Entries displayed in the FreeDesktop menu should conform to the
following minima for relevance and visual integration.
<ul class="simple">
<li>Unless hidden by default, the desktop entry must point to a PNG or
SVG icon with a transparent background, providing at least the 22×22
size, and preferably up to 64×64. The icon should be neutral enough
to integrate well with the default icon themes. It is encouraged to
ship the icon in the default hicolor icon theme directories, or to
use an existing icon from the hicolor theme.</li>
<li>If the menu entry is not useful in the general case as a standalone
application, the desktop entry should set the <code class="docutils literal notranslate">NoDisplay</code> key to
true, so that it can be configured to be displayed only by those who
need it.</li>
<li>In doubt, the package maintainer should coordinate with the
maintainers of menu implementations through the debian-desktop
mailing list in order to avoid problems with categories or bad
interactions with other icons. Especially for packages which are part
of installation tasks, the contents of the
<code class="docutils literal notranslate">NotShowIn</code>/<code class="docutils literal notranslate">OnlyShowIn</code> keys should be validated by the
maintainers of the relevant environments.</li>
</ul>
Since the FreeDesktop menu is a cross-distribution standard, the desktop
entries written for Debian should be forwarded upstream, where they will
benefit to other users and are more likely to receive extra
contributions such as translations.
If a package installs a FreeDesktop desktop entry, it must not also
install a Debian menu entry.
</section>
<section id="multimedia-handlers">
<h2>9.7. Multimedia handlers<a class="headerlink" href="#multimedia-handlers" title="Permalink to this headline">¶</a></h2>
Media types (formerly known as MIME types, Multipurpose Internet Mail
Extensions, RFCs 2045-2049) is a mechanism for encoding files and data
streams and providing meta-information about them, in particular their
type and format (e.g. <code class="docutils literal notranslate">image/png</code>, <code class="docutils literal notranslate">text/html</code>, <code class="docutils literal notranslate">audio/ogg</code>).
Registration of media type handlers allows programs like mail user
agents and web browsers to invoke these handlers to view, edit or
display media types they don’t support directly.
There are two overlapping systems to associate media types to programs
which can handle them. The mailcap system is found on a large number
of Unix systems. The FreeDesktop system is aimed at Desktop
environments. In Debian, FreeDesktop entries are automatically
translated in mailcap entries, therefore packages already using desktop
entries should not use the mailcap system directly.
<section id="registration-of-media-type-handlers-with-desktop-entries">
<h3>9.7.1. Registration of media type handlers with desktop entries<a class="headerlink" href="#registration-of-media-type-handlers-with-desktop-entries" title="Permalink to this headline">¶</a></h3>
Packages shipping an application able to view, edit or point to files of
a given media type, or open links with a given URI scheme, should list
it in the <code class="docutils literal notranslate">MimeType</code> key of the application’s <a class="reference external" href="#s-menus">desktop
entry</a>. For URI schemes, the relevant MIME types are
<code class="docutils literal notranslate">x-scheme-handler/*</code> (e.g. <code class="docutils literal notranslate">x-scheme-handler/https</code>).
</section>
<section id="registration-of-media-type-handlers-with-mailcap-entries">
<h3>9.7.2. Registration of media type handlers with mailcap entries<a class="headerlink" href="#registration-of-media-type-handlers-with-mailcap-entries" title="Permalink to this headline">¶</a></h3>
Packages that are not using desktop entries for registration should
install a file in mailcap(5) format (RFC 1524) in the directory
<code class="docutils literal notranslate">/usr/lib/mime/packages/</code>. The file name should be the binary package’s
name.
The mime-support package provides the <code class="docutils literal notranslate">update-mime</code> program, which
integrates these registrations in the <code class="docutils literal notranslate">/etc/mailcap</code> file, using dpkg
triggers. <a class="footnote-reference brackets" href="#id11" id="id6">5</a>
Packages installing desktop entries should not install mailcap entries
for the same program, because the mime-support package already reads
desktop entries.
Packages using these facilities should not depend on, recommend, or
suggest <code class="docutils literal notranslate">mime-support</code>.
</section>
<section id="providing-media-types-to-files">
<h3>9.7.3. Providing media types to files<a class="headerlink" href="#providing-media-types-to-files" title="Permalink to this headline">¶</a></h3>
The media type of a file is discovered by inspecting the file’s extension
or its magic(5) pattern, and interrogating a database
associating them with media types.
To support new associations between media types and files, their
characteristic file extensions and magic patterns should be registered
to the IANA (Internet Assigned Numbers Authority). See
<a class="reference external" href="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</a> and RFC 6838 for details.
This information will then propagate to the systems discovering file
media types in Debian, provided by the shared-mime-info, mime-support
and file packages. If registration and propagation can not be waited
for, support can be asked to the maintainers of the packages mentioned
above.
For files that are produced and read by a single application, it is also
possible to declare this association to the Shared MIME Info system by
installing in the directory <code class="docutils literal notranslate">/usr/share/mime/packages</code> a file in the
XML format specified at
<a class="reference external" href="https://standards.freedesktop.org/shared-mime-info-spec/latest/">https://standards.freedesktop.org/shared-mime-info-spec/latest/</a>.
</section>
</section>
<section id="keyboard-configuration">
<h2>9.8. Keyboard configuration<a class="headerlink" href="#keyboard-configuration" title="Permalink to this headline">¶</a></h2>
To achieve a consistent keyboard configuration so that all applications
interpret a keyboard event the same way, all programs in the Debian
distribution must be configured to comply with the following guidelines.
The following keys must have the specified interpretations:
<dl class="simple">
<dt><code class="docutils literal notranslate">&lt;--</code></dt><dd>delete the character to the left of the cursor
</dd>
<dt><code class="docutils literal notranslate">Delete</code></dt><dd>delete the character to the right of the cursor
</dd>
<dt><code class="docutils literal notranslate">Control+H</code></dt><dd>emacs: the help prefix
</dd>
</dl>
The interpretation of any keyboard events should be independent of the
terminal that is used, be it a virtual console, an X terminal emulator,
an rlogin/telnet session, etc.
The following list explains how the different programs should be set up
to achieve this:
<ul class="simple">
<li><code class="docutils literal notranslate">&lt;--</code> generates <code class="docutils literal notranslate">KB_BackSpace</code> in X.</li>
<li><code class="docutils literal notranslate">Delete</code> generates <code class="docutils literal notranslate">KB_Delete</code> in X.</li>
<li>X translations are set up to make <code class="docutils literal notranslate">KB_Backspace</code> generate ASCII
DEL, and to make <code class="docutils literal notranslate">KB_Delete</code> generate <code class="docutils literal notranslate">ESC [ 3 ~</code> (this is the vt220 escape code for the “delete
character” key). This must be done by loading the X resources using
<code class="docutils literal notranslate">xrdb</code> on all local X displays, not using the application defaults,
so that the translation resources used correspond to the <code class="docutils literal notranslate">xmodmap</code>
settings.</li>
<li>The Linux console is configured to make <code class="docutils literal notranslate">&lt;--</code> generate DEL, and
<code class="docutils literal notranslate">Delete</code> generate <code class="docutils literal notranslate">ESC [ 3 ~</code>.</li>
<li>X applications are configured so that <code class="docutils literal notranslate">&lt;</code> deletes left, and
<code class="docutils literal notranslate">Delete</code> deletes right. Motif applications already work like this.</li>
<li>Terminals should have <code class="docutils literal notranslate">stty erase ^?</code> .</li>
<li>The <code class="docutils literal notranslate">xterm</code> terminfo entry should have <code class="docutils literal notranslate">ESC [ 3 ~</code> for <code class="docutils literal notranslate">kdch1</code>,
just as for <code class="docutils literal notranslate">TERM=linux</code> and <code class="docutils literal notranslate">TERM=vt220</code>.</li>
<li>Emacs is programmed to map <code class="docutils literal notranslate">KB_Backspace</code> or the <code class="docutils literal notranslate">stty erase</code>
character to <code class="docutils literal notranslate">delete-backward-char</code>, and <code class="docutils literal notranslate">KB_Delete</code> or <code class="docutils literal notranslate">kdch1</code>
to <code class="docutils literal notranslate">delete-forward-char</code>, and <code class="docutils literal notranslate">^H</code> to <code class="docutils literal notranslate">help</code> as always.</li>
<li>Other applications use the <code class="docutils literal notranslate">stty erase</code> character and <code class="docutils literal notranslate">kdch1</code> for
the two delete keys, with ASCII DEL being “delete previous character”
and <code class="docutils literal notranslate">kdch1</code> being “delete character under cursor”.</li>
</ul>
This will solve the problem except for the following cases:
<ul class="simple">
<li>Some terminals have a <code class="docutils literal notranslate">&lt;--</code> key that cannot be made to produce
anything except <code class="docutils literal notranslate">^H</code>. On these terminals Emacs help will be
unavailable on <code class="docutils literal notranslate">^H</code> (assuming that the <code class="docutils literal notranslate">stty erase</code> character
takes precedence in Emacs, and has been set correctly). <code class="docutils literal notranslate">M-x help</code> or <code class="docutils literal notranslate">F1</code> (if available) can be used instead.</li>
<li>Some operating systems use <code class="docutils literal notranslate">^H</code> for <code class="docutils literal notranslate">stty erase</code>. However, modern
telnet versions and all rlogin versions propagate <code class="docutils literal notranslate">stty</code> settings,
and almost all UNIX versions honour <code class="docutils literal notranslate">stty erase</code>. Where the
<code class="docutils literal notranslate">stty</code> settings are not propagated correctly, things can be made to
work by using <code class="docutils literal notranslate">stty</code> manually.</li>
<li>Some systems (including previous Debian versions) use <code class="docutils literal notranslate">xmodmap</code> to
arrange for both <code class="docutils literal notranslate">&lt;--</code> and <code class="docutils literal notranslate">Delete</code> to generate <code class="docutils literal notranslate">KB_Delete</code>. We
can change the behavior of their X clients using the same X resources
that we use to do it for our own clients, or configure our clients
using their resources when things are the other way around. On
displays configured like this <code class="docutils literal notranslate">Delete</code> will not work, but <code class="docutils literal notranslate">&lt;--</code>
will.</li>
<li>Some operating systems have different <code class="docutils literal notranslate">kdch1</code> settings in their
<code class="docutils literal notranslate">terminfo</code> database for <code class="docutils literal notranslate">xterm</code> and others. On these systems the
<code class="docutils literal notranslate">Delete</code> key will not work correctly when you log in from a system
conforming to our policy, but <code class="docutils literal notranslate">&lt;--</code> will.</li>
</ul>
</section>
<section id="environment-variables">
<h2>9.9. Environment variables<a class="headerlink" href="#environment-variables" title="Permalink to this headline">¶</a></h2>
Programs installed on the system PATH (<code class="docutils literal notranslate">/bin</code>, <code class="docutils literal notranslate">/usr/bin</code>,
<code class="docutils literal notranslate">/sbin</code>, <code class="docutils literal notranslate">/usr/sbin</code>, or similar directories) must not depend on
custom environment variable settings to get reasonable defaults. This is
because such environment variables would have to be set in a system-wide
configuration file such as a file in <code class="docutils literal notranslate">/etc/profile.d</code>, which is not
supported by all shells.
If a program usually depends on environment variables for its
configuration, the program should be changed to fall back to a
reasonable default configuration if these environment variables are not
present. If this cannot be done easily (e.g., if the source code of a
non-free program is not available), the program must be replaced by a
small “wrapper” shell script that sets the environment variables if they
are not already defined, and calls the original program.
Here is an example of a wrapper script for this purpose:
<div class="highlight-default notranslate"><div class="highlight"><pre>#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo &quot;$@&quot;
</pre></div>
</div>
</section>
<section id="registering-documents-using-doc-base">
<h2>9.10. Registering Documents using doc-base<a class="headerlink" href="#registering-documents-using-doc-base" title="Permalink to this headline">¶</a></h2>
The doc-base package implements a mechanism for handling and
presenting documentation. Debian packages that provides online
documentation (other than just manual pages) may register these
documents with doc-base by installing a doc-base control file in
<code class="docutils literal notranslate">/usr/share/doc-base/</code>.
Please refer to the documentation that comes with the doc-base package
for information and details.
</section>
<section id="alternate-init-systems">
<h2>9.11. Alternate init systems<a class="headerlink" href="#alternate-init-systems" title="Permalink to this headline">¶</a></h2>
This section has been deleted.
<section id="event-based-boot-with-upstart">
<h3>9.11.1. Event-based boot with upstart<a class="headerlink" href="#event-based-boot-with-upstart" title="Permalink to this headline">¶</a></h3>
The <code class="docutils literal notranslate">upstart</code> event-based boot system is no longer maintained in
Debian, so this section has been removed.
<dl class="footnote brackets">
<dt class="label" id="id7"><a class="fn-backref" href="#id1">1</a></dt>
<dd>This is necessary in order to reserve the directories for use in
cross-installation of library packages from other architectures, as
part of <code class="docutils literal notranslate">multiarch</code>.
</dd>
<dt class="label" id="id8"><a class="fn-backref" href="#id2">2</a></dt>
<dd>This is necessary for architecture-dependent headers file to coexist
in a <code class="docutils literal notranslate">multiarch</code> setup.
</dd>
<dt class="label" id="id9"><a class="fn-backref" href="#id3">3</a></dt>
<dd>These directories are used to store translators and as a set of
standard names for mount points, respectively.
</dd>
<dt class="label" id="id10"><a class="fn-backref" href="#id5">4</a></dt>
<dd><code class="docutils literal notranslate">/lib/lsb/init-functions</code>, which assists in writing LSB-compliant
init scripts, may fail if <code class="docutils literal notranslate">set -e</code> is in effect and echoing status messages to the
console fails, for example.
</dd>
<dt class="label" id="id11"><a class="fn-backref" href="#id6">5</a></dt>
<dd>Creating, modifying or removing a file in
<code class="docutils literal notranslate">/usr/lib/mime/packages/</code> using maintainer scripts will not
activate the trigger. In that case, it can be done by calling
<code class="docutils literal notranslate">dpkg-trigger --no-await /usr/lib/mime/packages</code> from the
maintainer script after creating, modifying, or removing the file.
</dd>
</dl>
</section>
</section>
<section id="signaling-that-a-reboot-is-required">
<h2>9.12. Signaling that a reboot is required<a class="headerlink" href="#signaling-that-a-reboot-is-required" title="Permalink to this headline">¶</a></h2>
Programs can signal that a reboot is required by <code class="docutils literal notranslate">touch</code>ing
<code class="docutils literal notranslate">/run/reboot-required</code>. It is conventional to add the name of the
package(s) requiring the reboot to
<code class="docutils literal notranslate">/run/reboot-required.pkgs</code>. Programs should not add a package name
to <code class="docutils literal notranslate">/run/reboot-required.pkgs</code> if it is already present there.
The <code class="docutils literal notranslate">/run/reboot-required</code> mechanism is used when a reboot is
needed to fully apply the changes introduced by package
installation or upgrade. Typically it is the <code class="docutils literal notranslate">postinst</code>
maintainer script that touches <code class="docutils literal notranslate">/run/reboot-required</code>, at the end
of a successful configuration of the package.
There are no guarantees provided by the <code class="docutils literal notranslate">/run/reboot-required</code>
convention as to when or whether the requested reboot will occur.
</section>
</section>

<div class="clearer"></div>
 </div>
 </div>
 </div>
 <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
 <div class="sphinxsidebarwrapper">
 <h3><a href="index.html">Table of Contents</a></h3>
 <ul>
<li><a class="reference internal" href="#">9. The Operating System</a><ul>
<li><a class="reference internal" href="#file-system-hierarchy">9.1. File system hierarchy</a><ul>
<li><a class="reference internal" href="#file-system-structure">9.1.1. File System Structure</a></li>
<li><a class="reference internal" href="#site-specific-programs">9.1.2. Site-specific programs</a></li>
<li><a class="reference internal" href="#the-system-wide-mail-directory">9.1.3. The system-wide mail directory</a></li>
<li><a class="reference internal" href="#run-and-run-lock">9.1.4. <code class="docutils literal notranslate">/run</code> and <code class="docutils literal notranslate">/run/lock</code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#users-and-groups">9.2. Users and groups</a><ul>
<li><a class="reference internal" href="#introduction">9.2.1. Introduction</a></li>
<li><a class="reference internal" href="#uid-and-gid-classes">9.2.2. UID and GID classes</a></li>
<li><a class="reference internal" href="#non-existent-home-directories">9.2.3. Non-existent home directories</a></li>
</ul>
</li>
<li><a class="reference internal" href="#starting-system-services">9.3. Starting system services</a><ul>
<li><a class="reference internal" href="#s-services-intro">9.3.1. Introduction</a></li>
<li><a class="reference internal" href="#writing-the-scripts">9.3.2. Writing the scripts</a></li>
<li><a class="reference internal" href="#interfacing-with-init-systems">9.3.3. Interfacing with init systems</a><ul>
<li><a class="reference internal" href="#managing-the-links">9.3.3.1. Managing the links</a></li>
<li><a class="reference internal" href="#running-init-scripts">9.3.3.2. Running init scripts</a></li>
</ul>
</li>
<li><a class="reference internal" href="#boot-time-initialization">9.3.4. Boot-time initialization</a></li>
<li><a class="reference internal" href="#example">9.3.5. Example</a></li>
</ul>
</li>
<li><a class="reference internal" href="#console-messages-from-init-d-scripts">9.4. Console messages from <code class="docutils literal notranslate">init.d</code> scripts</a></li>
<li><a class="reference internal" href="#cron-jobs">9.5. Cron jobs</a><ul>
<li><a class="reference internal" href="#cron-job-file-names">9.5.1. Cron job file names</a></li>
</ul>
</li>
<li><a class="reference internal" href="#menus">9.6. Menus</a></li>
<li><a class="reference internal" href="#multimedia-handlers">9.7. Multimedia handlers</a><ul>
<li><a class="reference internal" href="#registration-of-media-type-handlers-with-desktop-entries">9.7.1. Registration of media type handlers with desktop entries</a></li>
<li><a class="reference internal" href="#registration-of-media-type-handlers-with-mailcap-entries">9.7.2. Registration of media type handlers with mailcap entries</a></li>
<li><a class="reference internal" href="#providing-media-types-to-files">9.7.3. Providing media types to files</a></li>
</ul>
</li>
<li><a class="reference internal" href="#keyboard-configuration">9.8. Keyboard configuration</a></li>
<li><a class="reference internal" href="#environment-variables">9.9. Environment variables</a></li>
<li><a class="reference internal" href="#registering-documents-using-doc-base">9.10. Registering Documents using doc-base</a></li>
<li><a class="reference internal" href="#alternate-init-systems">9.11. Alternate init systems</a><ul>
<li><a class="reference internal" href="#event-based-boot-with-upstart">9.11.1. Event-based boot with upstart</a></li>
</ul>
</li>
<li><a class="reference internal" href="#signaling-that-a-reboot-is-required">9.12. Signaling that a reboot is required</a></li>
</ul>
</li>
</ul>

<h4>Previous topic</h4>
 <a href="ch-sharedlibs.html"
 title="previous chapter">8. Shared libraries</a>
 <h4>Next topic</h4>
 <a href="ch-files.html"
 title="next chapter">10. Files</a>
 <div role="note" aria-label="source link">
 <h3>This Page</h3>
 <ul class="this-page-menu">
 <li><a href="_sources/ch-opersys.rst.txt"
 rel="nofollow">Show Source</a></li>
 </ul>
 </div>
<div id="searchbox" style="display: none" role="search">
 <h3 id="searchlabel">Quick search</h3>
 <div class="searchformwrapper">
 <form class="search" action="search.html" method="get">
 <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
 <input type="submit" value="Go" />
 </form>
 </div>
</div>
<script>$('#searchbox').show(0);</script>
 </div>
 </div>
 <div class="clearer"></div>
 </div>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 >index</a></li>
 <li class="right" >
 <a href="ch-files.html" title="10. Files"
 >next</a> |</li>
 <li class="right" >
 <a href="ch-sharedlibs.html" title="8. Shared libraries"
 >previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">9. The Operating System</a></li> 
 </ul>
 </div>
 <div class="footer" role="contentinfo">
 Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.2.0.
 </div>
 </body>
</html>

${this.title}

Code Editor : ch-opersys.html