File: //usr/share/doc/debian-policy/policy.html/ch-opersys.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />
<title>9. The Operating System — 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> »</li>
<li class="nav-item nav-item-this"><a href=""><span class="section-number">9. </span>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><span class="section-number">9. </span>The Operating System<a class="headerlink" href="#the-operating-system" title="Permalink to this headline">¶</a></h1>
<section id="file-system-hierarchy">
<span id="s9-1"></span><h2><span class="section-number">9.1. </span>File system hierarchy<a class="headerlink" href="#file-system-hierarchy" title="Permalink to this headline">¶</a></h2>
<section id="file-system-structure">
<span id="s-fhs"></span><h3><span class="section-number">9.1.1. </span>File System Structure<a class="headerlink" href="#file-system-structure" title="Permalink to this headline">¶</a></h3>
<p>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:</p>
<ol class="arabic">
<li><p>The FHS requirement that architecture-independent
application-specific static files be located in <code class="docutils literal notranslate"><span class="pre">/usr/share</span></code> is
relaxed to a suggestion. In particular, a subdirectory of
<code class="docutils literal notranslate"><span class="pre">/usr/lib</span></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"><span class="pre">/usr/share</span></code>.</p></li>
<li><p>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"><span class="pre">.</span></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.</p></li>
<li><p>Only the dynamic linker and libc are allowed to install files
in <code class="docutils literal notranslate"><span class="pre">/lib64</span></code>.</p></li>
<li><p>The requirement for object files, internal binaries, and libraries,
including <code class="docutils literal notranslate"><span class="pre">libc.so.*</span></code>, to be located directly under <code class="docutils literal notranslate"><span class="pre">/lib{,32}</span></code>
and <code class="docutils literal notranslate"><span class="pre">/usr/lib{,32}</span></code> is amended, permitting files to instead be
installed to <code class="docutils literal notranslate"><span class="pre">/lib/triplet</span></code> and <code class="docutils literal notranslate"><span class="pre">/usr/lib/triplet</span></code>, where
<code class="docutils literal notranslate"><span class="pre">triplet</span></code> is the value returned by <code class="docutils literal notranslate"><span class="pre">dpkg-architecture</span> <span class="pre">-qDEB_HOST_MULTIARCH</span></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"><span class="pre">Architecture:</span>  <span class="pre">amd64</span></code> package containing 32-bit x86
libraries must not install these libraries to
<code class="docutils literal notranslate"><span class="pre">/usr/lib/i386-linux-gnu</span></code>. <a class="footnote-reference brackets" href="#id7" id="id1">1</a></p>
<p>Packages must not install files in <code class="docutils literal notranslate"><span class="pre">/usr/lib64</span></code> or in a subdirectory
of it.</p>
<p>The requirement for C and C++ headers files to be accessible through
the search path <code class="docutils literal notranslate"><span class="pre">/usr/include/</span></code> is amended, permitting files to be
accessible through the search path <code class="docutils literal notranslate"><span class="pre">/usr/include/triplet</span></code> where
<code class="docutils literal notranslate"><span class="pre">triplet</span></code> is as above. <a class="footnote-reference brackets" href="#id8" id="id2">2</a></p>
<p>Applications may also use a single subdirectory under
<code class="docutils literal notranslate"><span class="pre">/usr/lib/triplet</span></code>.</p>
<p>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.</p>
</li>
<li><p>The requirement that <code class="docutils literal notranslate"><span class="pre">/usr/local/share/man</span></code> be “synonymous” with
<code class="docutils literal notranslate"><span class="pre">/usr/local/man</span></code> is relaxed to a recommendation</p></li>
<li><p>The requirement that window managers with a single configuration file
call it <code class="docutils literal notranslate"><span class="pre">system.*wmrc</span></code> is removed, as is the restriction that the
window manager subdirectory be named identically to the window
manager name itself.</p></li>
<li><p>The requirement that boot manager configuration files live in
<code class="docutils literal notranslate"><span class="pre">/etc</span></code>, or at least are symlinked there, is relaxed to a
recommendation.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">/var/run</span></code> is required to be a symbolic link to <code class="docutils literal notranslate"><span class="pre">/run</span></code>,
and <code class="docutils literal notranslate"><span class="pre">/var/lock</span></code> is required to be a symbolic link to <code class="docutils literal notranslate"><span class="pre">/run/lock</span></code>.</p></li>
<li><p>The <code class="docutils literal notranslate"><span class="pre">/var/www</span></code> directory is additionally allowed.</p></li>
<li><p>The requirement for <code class="docutils literal notranslate"><span class="pre">/usr/local/share/color</span></code> to exist if
<code class="docutils literal notranslate"><span class="pre">/usr/share/color</span></code> exists is relaxed to a recommendation.</p></li>
<li><p>The requirement for <code class="docutils literal notranslate"><span class="pre">/usr/local/libqual</span></code> to exist if <code class="docutils literal notranslate"><span class="pre">/libqual</span></code>
or <code class="docutils literal notranslate"><span class="pre">/usr/libqual</span></code> exists (where <code class="docutils literal notranslate"><span class="pre">libqual</span></code> is a variant of
<code class="docutils literal notranslate"><span class="pre">lib</span></code> such as <code class="docutils literal notranslate"><span class="pre">lib32</span></code> or <code class="docutils literal notranslate"><span class="pre">lib64</span></code>) is removed.</p></li>
<li><p>On GNU/Hurd systems, the following additional directories are
allowed in the root filesystem: <code class="docutils literal notranslate"><span class="pre">/hurd</span></code> and <code class="docutils literal notranslate"><span class="pre">/servers</span></code>. <a class="footnote-reference brackets" href="#id9" id="id3">3</a></p></li>
<li><p>As an exception to the requirement for there to be no subdirectories
in <code class="docutils literal notranslate"><span class="pre">/usr/bin</span></code>, the <code class="docutils literal notranslate"><span class="pre">mh</span></code> mail-handling suite may create
<code class="docutils literal notranslate"><span class="pre">/usr/bin/mh/</span></code>, as was allowed in FHS version 2.3. Other
subdirectories are not allowed.</p></li>
</ol>
<p>The version of this document referred here can be found in the
<code class="docutils literal notranslate"><span class="pre">debian-policy</span></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"><span class="pre">debian-devel</span></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).</p>
</section>
<section id="site-specific-programs">
<span id="s9-1-2"></span><h3><span class="section-number">9.1.2. </span>Site-specific programs<a class="headerlink" href="#site-specific-programs" title="Permalink to this headline">¶</a></h3>
<p>As mandated by the FHS, packages must not place any files in
<code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>, either by putting them in the file system archive to be
unpacked by <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> or by manipulating them in their maintainer
scripts.</p>
<p>However, the package may create empty directories below <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>
so that the system administrator knows where to place site-specific
files. These are not directories <em>in</em> <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>, but are children
of directories in <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>. These directories
(<code class="docutils literal notranslate"><span class="pre">/usr/local/*/dir/</span></code>) should be removed on package removal if they are
empty.</p>
<p>Note that this applies only to directories <em>below</em> <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>, not
<em>in</em> <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>. Packages must not create sub-directories in the
directory <code class="docutils literal notranslate"><span class="pre">/usr/local</span></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.</p>
<p>If <code class="docutils literal notranslate"><span class="pre">/etc/staff-group-for-usr-local</span></code> does not exist, <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code>
and all subdirectories created by packages should have permissions
0755 and be owned by <code class="docutils literal notranslate"><span class="pre">root:root</span></code>. If
<code class="docutils literal notranslate"><span class="pre">/etc/staff-group-for-usr-local</span></code> exists, <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code> and
subdirectories should have permissions 2775 (group-writable and
set-group-id) and be owned by <code class="docutils literal notranslate"><span class="pre">root:staff</span></code>.</p>
<p>Since <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code> can be mounted read-only from a remote server,
<code class="docutils literal notranslate"><span class="pre">/usr/local/*/dir/</span></code> directories must be created and removed by the
<code class="docutils literal notranslate"><span class="pre">postinst</span></code> and <code class="docutils literal notranslate"><span class="pre">prerm</span></code> maintainer scripts and not be included in
the <code class="docutils literal notranslate"><span class="pre">.deb</span></code> archive. These scripts must not fail if either of these
operations fail.</p>
<p>For example, the <code class="docutils literal notranslate"><span class="pre">emacsen-common</span></code> package could contain something like</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/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>
<p>in its <code class="docutils literal notranslate"><span class="pre">postinst</span></code> script, and</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">rmdir</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">local</span><span class="o">/</span><span class="n">share</span><span class="o">/</span><span class="n">emacs</span><span class="o">/</span><span class="n">site</span><span class="o">-</span><span class="n">lisp</span> <span class="mi">2</span><span class="o">>/</span><span class="n">dev</span><span class="o">/</span><span class="n">null</span> <span class="o">||</span> <span class="n">true</span>
<span class="n">rmdir</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">local</span><span class="o">/</span><span class="n">share</span><span class="o">/</span><span class="n">emacs</span> <span class="mi">2</span><span class="o">>/</span><span class="n">dev</span><span class="o">/</span><span class="n">null</span> <span class="o">||</span> <span class="n">true</span>
</pre></div>
</div>
<p>in the <code class="docutils literal notranslate"><span class="pre">prerm</span></code> script. (Note that this form is used to ensure that if
the script is interrupted, the directory <code class="docutils literal notranslate"><span class="pre">/usr/local/share/emacs</span></code> will
still be removed.)</p>
<p>If you do create a directory in <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code> for local additions to a
package, you should ensure that settings in <code class="docutils literal notranslate"><span class="pre">/usr/local</span></code> take
precedence over the equivalents in <code class="docutils literal notranslate"><span class="pre">/usr</span></code>.</p>
<p>However, because <code class="docutils literal notranslate"><span class="pre">/usr/local</span></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"><span class="pre">/usr/local</span></code> for normal operation.</p>
</section>
<section id="the-system-wide-mail-directory">
<span id="s9-1-3"></span><h3><span class="section-number">9.1.3. </span>The system-wide mail directory<a class="headerlink" href="#the-system-wide-mail-directory" title="Permalink to this headline">¶</a></h3>
<p>The system-wide mail directory is <code class="docutils literal notranslate"><span class="pre">/var/mail</span></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"><span class="pre">/var/spool/mail</span></code> is deprecated,
even though the spool may still be physically located there.</p>
</section>
<section id="run-and-run-lock">
<span id="s-fhs-run"></span><h3><span class="section-number">9.1.4. </span><code class="docutils literal notranslate"><span class="pre">/run</span></code> and <code class="docutils literal notranslate"><span class="pre">/run/lock</span></code><a class="headerlink" href="#run-and-run-lock" title="Permalink to this headline">¶</a></h3>
<p>The directory <code class="docutils literal notranslate"><span class="pre">/run</span></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"><span class="pre">/run</span></code> other than <code class="docutils literal notranslate"><span class="pre">/run/lock</span></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"><span class="std std-ref">Writing the scripts</span></a> for more
information.</p>
<p>Packages must not include files or directories under <code class="docutils literal notranslate"><span class="pre">/run</span></code>, or under
the older <code class="docutils literal notranslate"><span class="pre">/var/run</span></code> and <code class="docutils literal notranslate"><span class="pre">/var/lock</span></code> paths. The latter paths will
normally be symlinks or other redirections to <code class="docutils literal notranslate"><span class="pre">/run</span></code> for backwards
compatibility.</p>
</section>
</section>
<section id="users-and-groups">
<span id="s9-2"></span><h2><span class="section-number">9.2. </span>Users and groups<a class="headerlink" href="#users-and-groups" title="Permalink to this headline">¶</a></h2>
<section id="introduction">
<span id="s9-2-1"></span><h3><span class="section-number">9.2.1. </span>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h3>
<p>The Debian system can be configured to use either plain or shadow
passwords.</p>
<p>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.</p>
<p>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.</p>
<p>Packages other than <code class="docutils literal notranslate"><span class="pre">base-passwd</span></code> must not modify <code class="docutils literal notranslate"><span class="pre">/etc/passwd</span></code>,
<code class="docutils literal notranslate"><span class="pre">/etc/shadow</span></code>, <code class="docutils literal notranslate"><span class="pre">/etc/group</span></code> or <code class="docutils literal notranslate"><span class="pre">/etc/gshadow</span></code>.</p>
</section>
<section id="uid-and-gid-classes">
<span id="s9-2-2"></span><h3><span class="section-number">9.2.2. </span>UID and GID classes<a class="headerlink" href="#uid-and-gid-classes" title="Permalink to this headline">¶</a></h3>
<p>The UID and GID numbers are divided into classes as follows:</p>
<dl>
<dt>0-99:</dt><dd><p>Globally allocated by the Debian project, the same on every Debian
system. These ids will appear in the <code class="docutils literal notranslate"><span class="pre">passwd</span></code> and <code class="docutils literal notranslate"><span class="pre">group</span></code> files
of all Debian systems, new ids in this range being added
automatically as the <code class="docutils literal notranslate"><span class="pre">base-passwd</span></code> package is updated.</p>
<p>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"><span class="pre">base-passwd</span></code>
maintainer for ids.</p>
</dd>
<dt>100-999:</dt><dd><p>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"><span class="pre">adduser</span> <span class="pre">--system</span></code> to
create the group and/or user. <code class="docutils literal notranslate"><span class="pre">adduser</span></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"><span class="pre">adduser.conf</span></code>.</p>
</dd>
<dt>1000-59999:</dt><dd><p>Dynamically allocated user accounts. By default <code class="docutils literal notranslate"><span class="pre">adduser</span></code> will
choose UIDs and GIDs for user accounts in this range, though
<code class="docutils literal notranslate"><span class="pre">adduser.conf</span></code> may be used to modify this behavior.</p>
</dd>
<dt>60000-64999:</dt><dd><p>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.</p>
<p>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"><span class="pre">/etc/passwd</span></code> or <code class="docutils literal notranslate"><span class="pre">/etc/group</span></code> (using <code class="docutils literal notranslate"><span class="pre">adduser</span></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.</p>
</dd>
<dt>65000-65533:</dt><dd><p>Reserved.</p>
</dd>
<dt>65534:</dt><dd><p>User <code class="docutils literal notranslate"><span class="pre">nobody</span></code>. The corresponding gid refers to the group
<code class="docutils literal notranslate"><span class="pre">nogroup</span></code>.</p>
</dd>
<dt>65535:</dt><dd><p>This value <em>must not</em> be used, because it was the error return
sentinel value when <code class="docutils literal notranslate"><span class="pre">uid_t</span></code> was 16 bits.</p>
</dd>
<dt>65536-4294967293:</dt><dd><p>Dynamically allocated user accounts. By default <code class="docutils literal notranslate"><span class="pre">adduser</span></code> will not
allocate UIDs and GIDs in this range, to ease compatibility with
legacy systems where <code class="docutils literal notranslate"><span class="pre">uid_t</span></code> is still 16 bits.</p>
</dd>
<dt>4294967294:</dt><dd><p><code class="docutils literal notranslate"><span class="pre">(uid_t)(-2)</span> <span class="pre">==</span> <span class="pre">(gid_t)(-2)</span></code> <em>must not</em> be used, because it is
used as the anonymous, unauthenticated user by some NFS
implementations.</p>
</dd>
<dt>4294967295:</dt><dd><p><code class="docutils literal notranslate"><span class="pre">(uid_t)(-1)</span> <span class="pre">==</span> <span class="pre">(gid_t)(-1)</span></code> <em>must not</em> be used, because it is the
error return sentinel value.</p>
</dd>
</dl>
</section>
<section id="non-existent-home-directories">
<span id="s-nonexistent"></span><h3><span class="section-number">9.2.3. </span>Non-existent home directories<a class="headerlink" href="#non-existent-home-directories" title="Permalink to this headline">¶</a></h3>
<p>The canonical non-existent home directory is <code class="docutils literal notranslate"><span class="pre">/nonexistent</span></code>. Users
who should not have a home directory should have their home directory
set to this value.</p>
<p>The Debian autobuilders set HOME to <code class="docutils literal notranslate"><span class="pre">/nonexistent</span></code> so that packages
which try to write to a home directory will fail to build.</p>
</section>
</section>
<section id="starting-system-services">
<span id="s-services"></span><h2><span class="section-number">9.3. </span>Starting system services<a class="headerlink" href="#starting-system-services" title="Permalink to this headline">¶</a></h2>
<section id="s-services-intro">
<span id="id4"></span><h3><span class="section-number">9.3.1. </span>Introduction<a class="headerlink" href="#s-services-intro" title="Permalink to this headline">¶</a></h3>
<p>Packages that include system services should include <code class="docutils literal notranslate"><span class="pre">systemd</span></code> service
units to start or stop those services. See <em class="manpage">systemd.service(5)</em>
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"><span class="pre">.service</span></code> extension.</p>
<p>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.</p>
<p>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"><span class="pre">systemd</span></code> service unit so that <code class="docutils literal notranslate"><span class="pre">systemd</span></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.</p>
<p>If a service unit is not present, <code class="docutils literal notranslate"><span class="pre">systemd</span></code> uses dependency information
contained within the init scripts and symlinks in <code class="docutils literal notranslate"><span class="pre">/etc/rcn.d</span></code> to decide
which scripts to run and in which order. The <code class="docutils literal notranslate"><span class="pre">sysv-rc</span></code> runlevel system
for <code class="docutils literal notranslate"><span class="pre">sysvinit</span></code> uses the same symlinks in <code class="docutils literal notranslate"><span class="pre">/etc/rcn.d</span></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"><span class="pre">README.runlevels</span></code> file shipped with
<code class="docutils literal notranslate"><span class="pre">sysv-rc</span></code> for implementation details. Other alternatives might exist.</p>
<p>The sections below describe how to write those scripts and configure those
symlinks.</p>
</section>
<section id="writing-the-scripts">
<span id="s-writing-init"></span><h3><span class="section-number">9.3.2. </span>Writing the scripts<a class="headerlink" href="#writing-the-scripts" title="Permalink to this headline">¶</a></h3>
<p>Init scripts are placed in <code class="docutils literal notranslate"><span class="pre">/etc/init.d</span></code>. In the common case that a
package starts a single service, they should be named
<code class="docutils literal notranslate"><span class="pre">/etc/init.d/package</span></code>. They should accept one argument, saying what to
do:</p>
<dl class="simple">
<dt><code class="docutils literal notranslate"><span class="pre">start</span></code></dt><dd><p>start the service,</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">stop</span></code></dt><dd><p>stop the service,</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">restart</span></code></dt><dd><p>stop and restart the service if it’s already running, otherwise
start the service</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">try-restart</span></code></dt><dd><p>restart the service if it’s already running, otherwise just report
success.</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">reload</span></code></dt><dd><p>cause the configuration of the service to be reloaded without
actually stopping and restarting the service,</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">force-reload</span></code></dt><dd><p>cause the configuration to be reloaded if the service supports this,
otherwise restart the service.</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">status</span></code></dt><dd><p>report the current status of the service</p>
</dd>
</dl>
<p>The <code class="docutils literal notranslate"><span class="pre">start</span></code>, <code class="docutils literal notranslate"><span class="pre">stop</span></code>, <code class="docutils literal notranslate"><span class="pre">restart</span></code>, and <code class="docutils literal notranslate"><span class="pre">force-reload</span></code> options should
be supported by all init scripts. Supporting <code class="docutils literal notranslate"><span class="pre">status</span></code> is encouraged.
The <code class="docutils literal notranslate"><span class="pre">reload</span></code> and <code class="docutils literal notranslate"><span class="pre">try-restart</span></code> options are optional.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">init.d</span></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"><span class="pre">start</span></code> when the service is already running, or with
<code class="docutils literal notranslate"><span class="pre">stop</span></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"><span class="pre">start-stop-daemon</span></code> with the <code class="docutils literal notranslate"><span class="pre">--oknodo</span></code> option.</p>
<p>Be careful of using <code class="docutils literal notranslate"><span class="pre">set</span> <span class="pre">-e</span></code> in <code class="docutils literal notranslate"><span class="pre">init.d</span></code> scripts. Writing correct
<code class="docutils literal notranslate"><span class="pre">init.d</span></code> scripts requires accepting various error exit statuses when
daemons are already running or already stopped without aborting the
<code class="docutils literal notranslate"><span class="pre">init.d</span></code> script, and common <code class="docutils literal notranslate"><span class="pre">init.d</span></code> function libraries are not safe
to call with <code class="docutils literal notranslate"><span class="pre">set</span> <span class="pre">-e</span></code> in effect. <a class="footnote-reference brackets" href="#id10" id="id5">4</a> For <code class="docutils literal notranslate"><span class="pre">init.d</span></code> scripts, it’s
often easier to not use <code class="docutils literal notranslate"><span class="pre">set</span> <span class="pre">-e</span></code> and instead check the result of each
command separately.</p>
<p>If a service reloads its configuration automatically (as in the case of
<code class="docutils literal notranslate"><span class="pre">cron</span></code>, for example), the <code class="docutils literal notranslate"><span class="pre">reload</span></code> option of the <code class="docutils literal notranslate"><span class="pre">init.d</span></code> script
should behave as if the configuration has been reloaded successfully.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">/etc/init.d</span></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"><span class="pre">conffile</span></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"><span class="std std-ref">Configuration files</span></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.</p>
<p>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"><span class="pre">dpkg</span></code> is
executed with the <code class="docutils literal notranslate"><span class="pre">--purge</span></code> option will configuration files be
removed. In particular, as the <code class="docutils literal notranslate"><span class="pre">/etc/init.d/package</span></code> script itself is
usually a <code class="docutils literal notranslate"><span class="pre">conffile</span></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"><span class="pre">test</span></code>
statement at the top of the script, like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">test</span> <span class="o">-</span><span class="n">f</span> <span class="n">program</span><span class="o">-</span><span class="n">executed</span><span class="o">-</span><span class="n">later</span><span class="o">-</span><span class="ow">in</span><span class="o">-</span><span class="n">script</span> <span class="o">||</span> <span class="n">exit</span> <span class="mi">0</span>
</pre></div>
</div>
<p>Often there are some variables in the <code class="docutils literal notranslate"><span class="pre">init.d</span></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"><span class="pre">conffile</span></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"><span class="pre">conffile</span></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"><span class="pre">/etc/default</span></code>, which
typically will have the same base name as the <code class="docutils literal notranslate"><span class="pre">init.d</span></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"><span class="pre">sh</span></code> format. It
must either be a <code class="docutils literal notranslate"><span class="pre">conffile</span></code> or a configuration file maintained by the
package maintainer scripts. See <a class="reference internal" href="ch-files.html#s-config-files"><span class="std std-ref">Configuration files</span></a> for
more details.</p>
<p>To ensure that vital configurable values are always available, the
<code class="docutils literal notranslate"><span class="pre">init.d</span></code> script should set default values for each of the shell
variables it uses, either before sourcing the <code class="docutils literal notranslate"><span class="pre">/etc/default/</span></code> file or
afterwards using something like the <code class="docutils literal notranslate"><span class="pre">:</span> <span class="pre">${VAR:=default}</span></code> syntax. Also,
the <code class="docutils literal notranslate"><span class="pre">init.d</span></code> script must behave sensibly and not fail if the
<code class="docutils literal notranslate"><span class="pre">/etc/default</span></code> file is deleted.</p>
<p>Files and directories under <code class="docutils literal notranslate"><span class="pre">/run</span></code>, including ones referred to via the
compatibility paths <code class="docutils literal notranslate"><span class="pre">/var/run</span></code> and <code class="docutils literal notranslate"><span class="pre">/var/lock</span></code>, are normally stored
on a temporary filesystem and are normally not persistent across a
reboot. The <code class="docutils literal notranslate"><span class="pre">init.d</span></code> scripts must handle this correctly. This will
typically mean creating any required subdirectories dynamically when the
<code class="docutils literal notranslate"><span class="pre">init.d</span></code> script is run. See <a class="reference internal" href="#s-fhs-run"><span class="std std-ref">/run and /run/lock</span></a> for more
information.</p>
</section>
<section id="interfacing-with-init-systems">
<span id="s9-3-3"></span><h3><span class="section-number">9.3.3. </span>Interfacing with init systems<a class="headerlink" href="#interfacing-with-init-systems" title="Permalink to this headline">¶</a></h3>
<p>Maintainer scripts for packages including init scripts must use
<code class="docutils literal notranslate"><span class="pre">update-rc.d</span></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"><span class="pre">invoke-rc.d</span></code> as described below to invoke init scripts for requests
such as starting and stopping service.</p>
<p>Directly managing the <code class="docutils literal notranslate"><span class="pre">/etc/rc?.d</span></code> links and directly invoking the
<code class="docutils literal notranslate"><span class="pre">/etc/init.d/</span></code> init scripts should be done only by packages providing
the init script subsystem (such as <code class="docutils literal notranslate"><span class="pre">init-system-helpers</span></code>).</p>
<section id="managing-the-links">
<span id="s9-3-3-1"></span><h4><span class="section-number">9.3.3.1. </span>Managing the links<a class="headerlink" href="#managing-the-links" title="Permalink to this headline">¶</a></h4>
<p>The program <code class="docutils literal notranslate"><span class="pre">update-rc.d</span></code> is provided for package maintainers to
arrange for the proper creation and removal of <code class="docutils literal notranslate"><span class="pre">/etc/rcn.d</span></code> symbolic
links, or their functional equivalent if another method is being used.
It is intended for use in package maintainer scripts.</p>
<p>You must not include any <code class="docutils literal notranslate"><span class="pre">/etc/rcn.d</span></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"><span class="pre">update-rc.d</span></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"><span class="pre">/etc/rcn.d</span></code> directories
themselves in the archive either. (Only the <code class="docutils literal notranslate"><span class="pre">init-system-helpers</span></code>
package is permitted to do so.)</p>
<p>To get the default behavior for your package, put in your <code class="docutils literal notranslate"><span class="pre">postinst</span></code>
script:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">update</span><span class="o">-</span><span class="n">rc</span><span class="o">.</span><span class="n">d</span> <span class="n">package</span> <span class="n">defaults</span>
</pre></div>
</div>
<p>and in your <code class="docutils literal notranslate"><span class="pre">postrm</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">[</span> <span class="s2">"$1"</span> <span class="o">=</span> <span class="n">purge</span> <span class="p">];</span> <span class="n">then</span>
<span class="n">update</span><span class="o">-</span><span class="n">rc</span><span class="o">.</span><span class="n">d</span> <span class="n">package</span> <span class="n">remove</span>
<span class="n">fi</span>
</pre></div>
</div>
<p>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"><span class="pre">update-rc.d</span> <span class="pre">package</span> <span class="pre">disable</span></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"><span class="pre">postinst</span></code> script:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">update</span><span class="o">-</span><span class="n">rc</span><span class="o">.</span><span class="n">d</span> <span class="n">package</span> <span class="n">defaults</span><span class="o">-</span><span class="n">disabled</span>
</pre></div>
</div>
<p>and add a dependency on <code class="docutils literal notranslate"><span class="pre">init-system-helpers</span> <span class="pre">(>=</span> <span class="pre">1.50)</span></code>, which
introduced the <code class="docutils literal notranslate"><span class="pre">defaults-disabled</span></code> option. Then the local
administrator can enable autostarting the daemon using the command
<code class="docutils literal notranslate"><span class="pre">update-rc.d</span> <span class="pre">package</span> <span class="pre">enable</span></code>.</p>
<p>An older practice, which should not be used, was to include a line
like <code class="docutils literal notranslate"><span class="pre">DISABLED=yes</span></code> in the package’s <code class="docutils literal notranslate"><span class="pre">/etc/default</span></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"><span class="pre">DISABLED=no</span></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"><span class="pre">service</span> <span class="pre"><package></span> <span class="pre">start</span></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.</p>
<p>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"><span class="pre">update-rc.d</span></code>.</p>
<p>For more information about using <code class="docutils literal notranslate"><span class="pre">update-rc.d</span></code>, please consult its man
page, <em class="manpage">update-rc.d(8)</em>.</p>
<p>It is easiest for packages not to call <code class="docutils literal notranslate"><span class="pre">update-rc.d</span></code> directly, but
instead use debhelper programs that add the required <code class="docutils literal notranslate"><span class="pre">update-rc.d</span></code>
calls automatically. See <code class="docutils literal notranslate"><span class="pre">dh_installinit</span></code>, <code class="docutils literal notranslate"><span class="pre">dh_installsystemd</span></code>, etc.</p>
</section>
<section id="running-init-scripts">
<span id="s9-3-3-2"></span><h4><span class="section-number">9.3.3.2. </span>Running init scripts<a class="headerlink" href="#running-init-scripts" title="Permalink to this headline">¶</a></h4>
<p>The program <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></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.</p>
<p>The package maintainer scripts must use <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code> to invoke the
<code class="docutils literal notranslate"><span class="pre">/etc/init.d/*</span></code> init scripts or equivalent instead of calling them
directly.</p>
<p>By default, <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code> will pass any action requests (start, stop,
reload, restart…) to the <code class="docutils literal notranslate"><span class="pre">/etc/init.d</span></code> script, filtering out
requests to start or restart a service out of its intended runlevels.</p>
<p>Most packages will simply use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">invoke</span><span class="o">-</span><span class="n">rc</span><span class="o">.</span><span class="n">d</span> <span class="n">package</span> <span class="n">action</span>
</pre></div>
</div>
<p>in their <code class="docutils literal notranslate"><span class="pre">postinst</span></code> and <code class="docutils literal notranslate"><span class="pre">prerm</span></code> scripts.</p>
<p>A package should register its init script services using <code class="docutils literal notranslate"><span class="pre">update-rc.d</span></code>
before it tries to invoke them using <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code>. Invocation of
unregistered services may fail.</p>
<p>For more information about using <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code>, please consult its man
page, <em class="manpage">invoke-rc.d(8)</em>.</p>
<p>It is easiest for packages not to call <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code> directly, but
instead use debhelper programs that add the required <code class="docutils literal notranslate"><span class="pre">invoke-rc.d</span></code>
calls automatically. See <code class="docutils literal notranslate"><span class="pre">dh_installinit</span></code>, <code class="docutils literal notranslate"><span class="pre">dh_installsystemd</span></code>, etc.</p>
</section>
</section>
<section id="boot-time-initialization">
<span id="s9-3-4"></span><h3><span class="section-number">9.3.4. </span>Boot-time initialization<a class="headerlink" href="#boot-time-initialization" title="Permalink to this headline">¶</a></h3>
<p>This section has been deleted.</p>
</section>
<section id="example">
<span id="s9-3-5"></span><h3><span class="section-number">9.3.5. </span>Example<a class="headerlink" href="#example" title="Permalink to this headline">¶</a></h3>
<p>Examples on which you can base your <code class="docutils literal notranslate"><span class="pre">systemd</span></code> service units are
available in the man page <em class="manpage">systemd.unit(5)</em>. An example on which
you can base your init scripts is available in the man page
<em class="manpage">init-d-script(5)</em>.</p>
</section>
</section>
<section id="console-messages-from-init-d-scripts">
<span id="s9-4"></span><h2><span class="section-number">9.4. </span>Console messages from <code class="docutils literal notranslate"><span class="pre">init.d</span></code> scripts<a class="headerlink" href="#console-messages-from-init-d-scripts" title="Permalink to this headline">¶</a></h2>
<p>This section has been deleted.</p>
</section>
<section id="cron-jobs">
<span id="s-cron-jobs"></span><h2><span class="section-number">9.5. </span>Cron jobs<a class="headerlink" href="#cron-jobs" title="Permalink to this headline">¶</a></h2>
<p>Packages must not modify the configuration file <code class="docutils literal notranslate"><span class="pre">/etc/crontab</span></code>, and
they must not modify the files in <code class="docutils literal notranslate"><span class="pre">/var/spool/cron/crontabs</span></code>.</p>
<p>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"><span class="std std-ref">Cron job file names</span></a> into one or more of the following
directories:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">/etc/cron.hourly</span></code></p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">/etc/cron.daily</span></code></p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">/etc/cron.weekly</span></code></p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">/etc/cron.monthly</span></code></p></li>
</ul>
<p>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"><span class="pre">/etc/crontab</span></code>.</p>
<p>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.</p>
<p>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"><span class="pre">/etc/cron.d</span></code> with
a name as specified in <a class="reference internal" href="#s-cron-files"><span class="std std-ref">Cron job file names</span></a>. This file
uses the same syntax as <code class="docutils literal notranslate"><span class="pre">/etc/crontab</span></code> and is processed by <code class="docutils literal notranslate"><span class="pre">cron</span></code>
automatically. The file must also be treated as a configuration file.
(Note that entries in the <code class="docutils literal notranslate"><span class="pre">/etc/cron.d</span></code> directory are not handled by
<code class="docutils literal notranslate"><span class="pre">anacron</span></code>. Thus, you should only use this directory for jobs which may
be skipped if the system is not running.)</p>
<p>Unlike <code class="docutils literal notranslate"><span class="pre">crontab</span></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"><span class="pre">/etc/cron.d</span></code> and the file <code class="docutils literal notranslate"><span class="pre">/etc/crontab</span></code> have seven fields;
namely:</p>
<ol class="arabic simple">
<li><p>Minute [0,59]</p></li>
<li><p>Hour [0,23]</p></li>
<li><p>Day of the month [1,31]</p></li>
<li><p>Month of the year [1,12]</p></li>
<li><p>Day of the week ([0,6] with 0=Sunday)</p></li>
<li><p>Username</p></li>
<li><p>Command to be run</p></li>
</ol>
<p>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.</p>
<p>The scripts or <code class="docutils literal notranslate"><span class="pre">crontab</span></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.</p>
<p>Any <code class="docutils literal notranslate"><span class="pre">cron</span></code> daemon must provide <code class="docutils literal notranslate"><span class="pre">/usr/bin/crontab</span></code> and support normal
<code class="docutils literal notranslate"><span class="pre">crontab</span></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"><span class="pre">/etc/crontab</span></code>, and correctly execute the scripts in <code class="docutils literal notranslate"><span class="pre">/etc/cron.d</span></code>.
The daemon must also correctly execute scripts in
<code class="docutils literal notranslate"><span class="pre">/etc/cron.{hourly,daily,weekly,monthly}</span></code>.</p>
<section id="cron-job-file-names">
<span id="s-cron-files"></span><h3><span class="section-number">9.5.1. </span>Cron job file names<a class="headerlink" href="#cron-job-file-names" title="Permalink to this headline">¶</a></h3>
<p>The file name of a cron job file should normally match the name of the
package from which it comes.</p>
<p>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"><span class="pre">-</span></code>) and
a suitable suffix.</p>
<p>A cron job file name must not include any period or plus characters
(<code class="docutils literal notranslate"><span class="pre">.</span></code> or <code class="docutils literal notranslate"><span class="pre">+</span></code>) characters as this will cause cron to ignore the file.
Underscores (<code class="docutils literal notranslate"><span class="pre">_</span></code>) should be used instead of <code class="docutils literal notranslate"><span class="pre">.</span></code> and <code class="docutils literal notranslate"><span class="pre">+</span></code>
characters.</p>
</section>
</section>
<section id="menus">
<span id="s-menus"></span><h2><span class="section-number">9.6. </span>Menus<a class="headerlink" href="#menus" title="Permalink to this headline">¶</a></h2>
<p>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
<em>FreeDesktop</em> standard, using text files called <em>desktop entries</em>. Their
format is described in the <em>Desktop Entry Specification</em> 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 <em>Desktop Menu
Specification</em> at <a class="reference external" href="https://standards.freedesktop.org/menu-spec/latest/">https://standards.freedesktop.org/menu-spec/latest/</a>.</p>
<p>The desktop entry files are installed by the packages in the directory
<code class="docutils literal notranslate"><span class="pre">/usr/share/applications</span></code> and the FreeDesktop menus are refreshed
using <em>dpkg triggers</em>. It is therefore not necessary to depend on
packages providing FreeDesktop menu systems.</p>
<p>Entries displayed in the FreeDesktop menu should conform to the
following minima for relevance and visual integration.</p>
<ul class="simple">
<li><p>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 <em>hicolor</em> icon theme directories, or to
use an existing icon from the <em>hicolor</em> theme.</p></li>
<li><p>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"><span class="pre">NoDisplay</span></code> key to
true, so that it can be configured to be displayed only by those who
need it.</p></li>
<li><p>In doubt, the package maintainer should coordinate with the
maintainers of menu implementations through the <em>debian-desktop</em>
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"><span class="pre">NotShowIn</span></code>/<code class="docutils literal notranslate"><span class="pre">OnlyShowIn</span></code> keys should be validated by the
maintainers of the relevant environments.</p></li>
</ul>
<p>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.</p>
<p>If a package installs a FreeDesktop desktop entry, it must not also
install a Debian menu entry.</p>
</section>
<section id="multimedia-handlers">
<span id="s-mime"></span><h2><span class="section-number">9.7. </span>Multimedia handlers<a class="headerlink" href="#multimedia-handlers" title="Permalink to this headline">¶</a></h2>
<p>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"><span class="pre">image/png</span></code>, <code class="docutils literal notranslate"><span class="pre">text/html</span></code>, <code class="docutils literal notranslate"><span class="pre">audio/ogg</span></code>).</p>
<p>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.</p>
<p>There are two overlapping systems to associate media types to programs
which can handle them. The <em>mailcap</em> system is found on a large number
of Unix systems. The <em>FreeDesktop</em> 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.</p>
<section id="registration-of-media-type-handlers-with-desktop-entries">
<span id="s-media-types-freedesktop"></span><h3><span class="section-number">9.7.1. </span>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>
<p>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"><span class="pre">MimeType</span></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"><span class="pre">x-scheme-handler/*</span></code> (e.g. <code class="docutils literal notranslate"><span class="pre">x-scheme-handler/https</span></code>).</p>
</section>
<section id="registration-of-media-type-handlers-with-mailcap-entries">
<span id="s-mailcap"></span><h3><span class="section-number">9.7.2. </span>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>
<p>Packages that are not using desktop entries for registration should
install a file in <em class="manpage">mailcap(5)</em> format (RFC 1524) in the directory
<code class="docutils literal notranslate"><span class="pre">/usr/lib/mime/packages/</span></code>. The file name should be the binary package’s
name.</p>
<p>The mime-support package provides the <code class="docutils literal notranslate"><span class="pre">update-mime</span></code> program, which
integrates these registrations in the <code class="docutils literal notranslate"><span class="pre">/etc/mailcap</span></code> file, using dpkg
triggers. <a class="footnote-reference brackets" href="#id11" id="id6">5</a></p>
<p>Packages installing desktop entries should not install mailcap entries
for the same program, because the mime-support package already reads
desktop entries.</p>
<p>Packages using these facilities <em>should not</em> depend on, recommend, or
suggest <code class="docutils literal notranslate"><span class="pre">mime-support</span></code>.</p>
</section>
<section id="providing-media-types-to-files">
<span id="s-file-media-type"></span><h3><span class="section-number">9.7.3. </span>Providing media types to files<a class="headerlink" href="#providing-media-types-to-files" title="Permalink to this headline">¶</a></h3>
<p>The media type of a file is discovered by inspecting the file’s extension
or its <em class="manpage">magic(5)</em> pattern, and interrogating a database
associating them with media types.</p>
<p>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.</p>
<p>For files that are produced and read by a single application, it is also
possible to declare this association to the <em>Shared MIME Info</em> system by
installing in the directory <code class="docutils literal notranslate"><span class="pre">/usr/share/mime/packages</span></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>.</p>
</section>
</section>
<section id="keyboard-configuration">
<span id="s9-8"></span><h2><span class="section-number">9.8. </span>Keyboard configuration<a class="headerlink" href="#keyboard-configuration" title="Permalink to this headline">¶</a></h2>
<p>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.</p>
<p>The following keys must have the specified interpretations:</p>
<dl class="simple">
<dt><code class="docutils literal notranslate"><span class="pre"><--</span></code></dt><dd><p>delete the character to the left of the cursor</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">Delete</span></code></dt><dd><p>delete the character to the right of the cursor</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">Control+H</span></code></dt><dd><p>emacs: the help prefix</p>
</dd>
</dl>
<p>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.</p>
<p>The following list explains how the different programs should be set up
to achieve this:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre"><--</span></code> generates <code class="docutils literal notranslate"><span class="pre">KB_BackSpace</span></code> in X.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">Delete</span></code> generates <code class="docutils literal notranslate"><span class="pre">KB_Delete</span></code> in X.</p></li>
<li><p>X translations are set up to make <code class="docutils literal notranslate"><span class="pre">KB_Backspace</span></code> generate ASCII
DEL, and to make <code class="docutils literal notranslate"><span class="pre">KB_Delete</span></code> generate <code class="docutils literal notranslate"><span class="pre">ESC</span> <span class="pre">[</span> <span class="pre">3</span> <span class="pre">~</span></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"><span class="pre">xrdb</span></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"><span class="pre">xmodmap</span></code>
settings.</p></li>
<li><p>The Linux console is configured to make <code class="docutils literal notranslate"><span class="pre"><--</span></code> generate DEL, and
<code class="docutils literal notranslate"><span class="pre">Delete</span></code> generate <code class="docutils literal notranslate"><span class="pre">ESC</span> <span class="pre">[</span> <span class="pre">3</span> <span class="pre">~</span></code>.</p></li>
<li><p>X applications are configured so that <code class="docutils literal notranslate"><span class="pre"><</span></code> deletes left, and
<code class="docutils literal notranslate"><span class="pre">Delete</span></code> deletes right. Motif applications already work like this.</p></li>
<li><p>Terminals should have <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span> <span class="pre">^?</span></code> .</p></li>
<li><p>The <code class="docutils literal notranslate"><span class="pre">xterm</span></code> terminfo entry should have <code class="docutils literal notranslate"><span class="pre">ESC</span> <span class="pre">[</span> <span class="pre">3</span> <span class="pre">~</span></code> for <code class="docutils literal notranslate"><span class="pre">kdch1</span></code>,
just as for <code class="docutils literal notranslate"><span class="pre">TERM=linux</span></code> and <code class="docutils literal notranslate"><span class="pre">TERM=vt220</span></code>.</p></li>
<li><p>Emacs is programmed to map <code class="docutils literal notranslate"><span class="pre">KB_Backspace</span></code> or the <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span></code>
character to <code class="docutils literal notranslate"><span class="pre">delete-backward-char</span></code>, and <code class="docutils literal notranslate"><span class="pre">KB_Delete</span></code> or <code class="docutils literal notranslate"><span class="pre">kdch1</span></code>
to <code class="docutils literal notranslate"><span class="pre">delete-forward-char</span></code>, and <code class="docutils literal notranslate"><span class="pre">^H</span></code> to <code class="docutils literal notranslate"><span class="pre">help</span></code> as always.</p></li>
<li><p>Other applications use the <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span></code> character and <code class="docutils literal notranslate"><span class="pre">kdch1</span></code> for
the two delete keys, with ASCII DEL being “delete previous character”
and <code class="docutils literal notranslate"><span class="pre">kdch1</span></code> being “delete character under cursor”.</p></li>
</ul>
<p>This will solve the problem except for the following cases:</p>
<ul class="simple">
<li><p>Some terminals have a <code class="docutils literal notranslate"><span class="pre"><--</span></code> key that cannot be made to produce
anything except <code class="docutils literal notranslate"><span class="pre">^H</span></code>. On these terminals Emacs help will be
unavailable on <code class="docutils literal notranslate"><span class="pre">^H</span></code> (assuming that the <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span></code> character
takes precedence in Emacs, and has been set correctly). <code class="docutils literal notranslate"><span class="pre">M-x</span> <span class="pre">help</span></code> or <code class="docutils literal notranslate"><span class="pre">F1</span></code> (if available) can be used instead.</p></li>
<li><p>Some operating systems use <code class="docutils literal notranslate"><span class="pre">^H</span></code> for <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span></code>. However, modern
telnet versions and all rlogin versions propagate <code class="docutils literal notranslate"><span class="pre">stty</span></code> settings,
and almost all UNIX versions honour <code class="docutils literal notranslate"><span class="pre">stty</span> <span class="pre">erase</span></code>. Where the
<code class="docutils literal notranslate"><span class="pre">stty</span></code> settings are not propagated correctly, things can be made to
work by using <code class="docutils literal notranslate"><span class="pre">stty</span></code> manually.</p></li>
<li><p>Some systems (including previous Debian versions) use <code class="docutils literal notranslate"><span class="pre">xmodmap</span></code> to
arrange for both <code class="docutils literal notranslate"><span class="pre"><--</span></code> and <code class="docutils literal notranslate"><span class="pre">Delete</span></code> to generate <code class="docutils literal notranslate"><span class="pre">KB_Delete</span></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"><span class="pre">Delete</span></code> will not work, but <code class="docutils literal notranslate"><span class="pre"><--</span></code>
will.</p></li>
<li><p>Some operating systems have different <code class="docutils literal notranslate"><span class="pre">kdch1</span></code> settings in their
<code class="docutils literal notranslate"><span class="pre">terminfo</span></code> database for <code class="docutils literal notranslate"><span class="pre">xterm</span></code> and others. On these systems the
<code class="docutils literal notranslate"><span class="pre">Delete</span></code> key will not work correctly when you log in from a system
conforming to our policy, but <code class="docutils literal notranslate"><span class="pre"><--</span></code> will.</p></li>
</ul>
</section>
<section id="environment-variables">
<span id="s9-9"></span><h2><span class="section-number">9.9. </span>Environment variables<a class="headerlink" href="#environment-variables" title="Permalink to this headline">¶</a></h2>
<p>Programs installed on the system PATH (<code class="docutils literal notranslate"><span class="pre">/bin</span></code>, <code class="docutils literal notranslate"><span class="pre">/usr/bin</span></code>,
<code class="docutils literal notranslate"><span class="pre">/sbin</span></code>, <code class="docutils literal notranslate"><span class="pre">/usr/sbin</span></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"><span class="pre">/etc/profile.d</span></code>, which is not
supported by all shells.</p>
<p>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.</p>
<p>Here is an example of a wrapper script for this purpose:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
</pre></div>
</div>
</section>
<section id="registering-documents-using-doc-base">
<span id="s-doc-base"></span><h2><span class="section-number">9.10. </span>Registering Documents using doc-base<a class="headerlink" href="#registering-documents-using-doc-base" title="Permalink to this headline">¶</a></h2>
<p>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"><span class="pre">/usr/share/doc-base/</span></code>.</p>
<p>Please refer to the documentation that comes with the doc-base package
for information and details.</p>
</section>
<section id="alternate-init-systems">
<span id="s-alternateinit"></span><h2><span class="section-number">9.11. </span>Alternate init systems<a class="headerlink" href="#alternate-init-systems" title="Permalink to this headline">¶</a></h2>
<p>This section has been deleted.</p>
<section id="event-based-boot-with-upstart">
<span id="s-upstart"></span><h3><span class="section-number">9.11.1. </span>Event-based boot with upstart<a class="headerlink" href="#event-based-boot-with-upstart" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">upstart</span></code> event-based boot system is no longer maintained in
Debian, so this section has been removed.</p>
<dl class="footnote brackets">
<dt class="label" id="id7"><span class="brackets"><a class="fn-backref" href="#id1">1</a></span></dt>
<dd><p>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"><span class="pre">multiarch</span></code>.</p>
</dd>
<dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="#id2">2</a></span></dt>
<dd><p>This is necessary for architecture-dependent headers file to coexist
in a <code class="docutils literal notranslate"><span class="pre">multiarch</span></code> setup.</p>
</dd>
<dt class="label" id="id9"><span class="brackets"><a class="fn-backref" href="#id3">3</a></span></dt>
<dd><p>These directories are used to store translators and as a set of
standard names for mount points, respectively.</p>
</dd>
<dt class="label" id="id10"><span class="brackets"><a class="fn-backref" href="#id5">4</a></span></dt>
<dd><p><code class="docutils literal notranslate"><span class="pre">/lib/lsb/init-functions</span></code>, which assists in writing LSB-compliant
init scripts, may fail if <code class="docutils literal notranslate"><span class="pre">set</span> <span class="pre">-e</span></code> is in effect and echoing status messages to the
console fails, for example.</p>
</dd>
<dt class="label" id="id11"><span class="brackets"><a class="fn-backref" href="#id6">5</a></span></dt>
<dd><p>Creating, modifying or removing a file in
<code class="docutils literal notranslate"><span class="pre">/usr/lib/mime/packages/</span></code> using maintainer scripts will not
activate the trigger. In that case, it can be done by calling
<code class="docutils literal notranslate"><span class="pre">dpkg-trigger</span> <span class="pre">--no-await</span> <span class="pre">/usr/lib/mime/packages</span></code> from the
maintainer script after creating, modifying, or removing the file.</p>
</dd>
</dl>
</section>
</section>
<section id="signaling-that-a-reboot-is-required">
<span id="s-signalingreboot"></span><span id="index-0"></span><h2><span class="section-number">9.12. </span>Signaling that a reboot is required<a class="headerlink" href="#signaling-that-a-reboot-is-required" title="Permalink to this headline">¶</a></h2>
<p id="index-1">Programs can signal that a reboot is required by <code class="docutils literal notranslate"><span class="pre">touch</span></code>ing
<code class="docutils literal notranslate"><span class="pre">/run/reboot-required</span></code>. It is conventional to add the name of the
package(s) requiring the reboot to
<code class="docutils literal notranslate"><span class="pre">/run/reboot-required.pkgs</span></code>. Programs should not add a package name
to <code class="docutils literal notranslate"><span class="pre">/run/reboot-required.pkgs</span></code> if it is already present there.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">/run/reboot-required</span></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"><span class="pre">postinst</span></code>
maintainer script that touches <code class="docutils literal notranslate"><span class="pre">/run/reboot-required</span></code>, at the end
of a successful configuration of the package.</p>
<p>There are no guarantees provided by the <code class="docutils literal notranslate"><span class="pre">/run/reboot-required</span></code>
convention as to when or whether the requested reboot will occur.</p>
</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"><span class="pre">/run</span></code> and <code class="docutils literal notranslate"><span class="pre">/run/lock</span></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"><span class="pre">init.d</span></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>
<p class="topless"><a href="ch-sharedlibs.html"
title="previous chapter"><span class="section-number">8. </span>Shared libraries</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="ch-files.html"
title="next chapter"><span class="section-number">10. </span>Files</a></p>
<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> »</li>
<li class="nav-item nav-item-this"><a href=""><span class="section-number">9. </span>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>