[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
The location of all files and directories must comply with the Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions noted below, and except where doing so would violate other terms of Debian Policy. The following exceptions to the FHS apply:
The FHS requirement that architecture-independent application-specific static
files be located in /usr/share is relaxed to a suggestion. In
particular, a subdirectory of /usr/lib 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
/usr/share.
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 '.' 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.
The requirement for amd64 to use /lib64 for 64 bit binaries is
removed.
The requirement for object files, internal binaries, and libraries, including
libc.so.*, to be located directly under /lib{,32} and
/usr/lib{,32} is amended, permitting files to instead be installed
to /lib/triplet and
/usr/lib/triplet, where triplet
is the value returned by dpkg-architecture -qDEB_HOST_MULTIARCH
for the architecture of the package. Packages may not install files
to any triplet path other than the one matching the architecture of
that package; for instance, an Architecture: amd64 package
containing 32-bit x86 libraries may not install these libraries to
/usr/lib/i386-linux-gnu. [78]
The requirement for C and C++ headers files to be accessible through the search
path /usr/include/ is amended, permitting files to be accessible
through the search path /usr/include/triplet where
triplet is as above. [79]
Applications may also use a single subdirectory under
/usr/lib/triplet.
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.
The requirement that /usr/local/share/man be
"synonymous" with /usr/local/man is relaxed to a
recommendation
The requirement that windowmanagers with a single configuration file call it
system.*wmrc is removed, as is the restriction that the window
manager subdirectory be named identically to the window manager name itself.
The requirement that boot manager configuration files live in
/etc, or at least are symlinked there, is relaxed to a
recommendation.
The additional directory /run in the root file system is allowed.
/run replaces /var/run, and the subdirectory
/run/lock replaces /var/lock, with the
/var directories replaced by symlinks for backwards compatibility.
/run and /run/lock must follow all of the
requirements in the FHS for /var/run and /var/lock,
respectively, such as file naming conventions, file format requirements, or the
requirement that files be cleared during the boot process. Files and
directories residing in /run should be stored on a temporary file
system.
Packages must not assume the /run directory exists or is usable
without a dependency on initscripts (>= 2.88dsf-13.3) until the
stable release of Debian supports /run.
The /sys directory in the root filesystem is additionally allowed.
[80]
The /var/www directory is additionally allowed.
The requirement for /usr/local/lib<qual> to exist if
/lib<qual> or /usr/lib<qual> exists
(where lib<qual> is a variant of lib such as
lib32 or lib64) is removed.
On GNU/Hurd systems, the following additional directories are allowed in the
root filesystem: /hurd and /servers.[81]
The version of this document referred here can be found in the
debian-policy package or on FHS (Debian
copy) alongside this manual (or, if you have the
debian-policy installed, you can try FHS (local copy)).
The latest version, which may be a more recent version, may be found on
FHS (upstream).
Specific questions about following the standard may be asked on the
debian-devel mailing list, or referred to the FHS mailing list
(see the FHS web site
for more information).
As mandated by the FHS, packages must not place any files in
/usr/local, either by putting them in the file system archive to
be unpacked by dpkg or by manipulating them in their maintainer
scripts.
However, the package may create empty directories below /usr/local
so that the system administrator knows where to place site-specific files.
These are not directories in /usr/local, but are children
of directories in /usr/local. These directories
(/usr/local/*/dir/) should be removed on package removal if they
are empty.
Note that this applies only to directories below
/usr/local, not in /usr/local. Packages
must not create sub-directories in the directory /usr/local
itself, except those listed in FHS, section 4.5. However, you may create
directories below them as you wish. You must not remove any of the directories
listed in 4.5, even if you created them.
Since /usr/local can be mounted read-only from a remote server,
these directories must be created and removed by the postinst and
prerm maintainer scripts and not be included in the
.deb archive. These scripts must not fail if either of these
operations fail.
For example, the emacsen-common package could contain something like
if [ ! -e /usr/local/share/emacs ]; then
if mkdir /usr/local/share/emacs 2>/dev/null; then
if chown root:staff /usr/local/share/emacs; then
chmod 2775 /usr/local/share/emacs || true
fi
fi
fi
in its postinst script, and
rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
rmdir /usr/local/share/emacs 2>/dev/null || true
in the prerm script. (Note that this form is used to ensure that
if the script is interrupted, the directory /usr/local/share/emacs
will still be removed.)
If you do create a directory in /usr/local for local additions to
a package, you should ensure that settings in /usr/local take
precedence over the equivalents in /usr.
However, because /usr/local 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 /usr/local for normal operation.
The /usr/local directory itself and all the subdirectories created
by the package should (by default) have permissions 2775 (group-writable and
set-group-id) and be owned by root:staff.
The system-wide mail directory is /var/mail. This directory is
part of the base system and should not be owned by any particular mail agents.
The use of the old location /var/spool/mail is deprecated, even
though the spool may still be physically located there.
/run and /run/lock
The directory /run 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 /run other than /run/lock
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 Writing the scripts, Section 9.3.7.1
for more information.
Packages must not include files or directories under /run, or
under the older /var/run and /var/lock paths. The
latter paths will normally be symlinks or other redirections to
/run for backwards compatibility.
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.
Packages other than base-passwd must not modify
/etc/passwd, /etc/shadow, /etc/group or
/etc/gshadow.
The UID and GID numbers are divided into classes as follows:
Globally allocated by the Debian project, the same on every Debian system.
These ids will appear in the passwd and group files
of all Debian systems, new ids in this range being added automatically as the
base-passwd package is updated.
Packages which need a single statically allocated uid or gid should use one of these; their maintainers should ask the base-passwd maintainer for ids.
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 adduser --system to create the group
and/or user. adduser will check for the existence of the user or
group, and if necessary choose an unused id based on the ranges specified in
adduser.conf.
Dynamically allocated user accounts. By default adduser will
choose UIDs and GIDs for user accounts in this range, though
adduser.conf may be used to modify this behavior.
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 /etc/passwd or /etc/group (using
adduser 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.
Reserved.
User nobody. The corresponding gid refers to the group nogroup.
(uid_t)(-1) == (gid_t)(-1) must not be used, because it is the error return sentinel value.
The default init system in Debian with Linux kernels is systemd, run when
systemd-sysv is installed. A number of other init systems are
available in Debian, including in particular System V init, run when
sysvinit-core is installed (and also the default for non-Linux
kernels). Both of these packages provide the init metapackage.
Packages must integrate with the default init system and may integrate with others as well.
To integrate with systemd, packages provide so-called unit files (described at
systemd unit files, Section 9.3.1) or
init.d scripts.
To integrate with upstart, packages provide so-called job files (described at
upstart job files, Section 9.3.3) or
init.d scripts.
To integrate with System V init, packages provide init.d scripts
(described at init.d scripts, Section
9.3.7).
Integration with other init systems in Debian, most of which do not use
init.d scripts, is not covered here; and Debian Policy has no
interface or usage contracts for those init systems.
These files provide init-system-specific information about how and when to run services, about boot-time and shutdown-time "milestones" or "targets", and about tasks that run as part of the boot-up or shutdown procedures. [82]
The least common denominator of these are the init.d scripts.
systemd places restrictions upon them, forbidding some of the more esoteric
possible mechanisms that System V init historically allowed. However, a script
that is compliant with this Policy should be usable with systemd. [83]
Packages should use the same names for files across different init systems.
However, this is not always possible. For example, an init.d
script can start and manage several services, whereas one would have individual
systemd unit files for each of the individual services (and possibly more unit
files for sockets if the services are socket-activated). Similarly, packages
may be constrained by what upstream does. It is recommended that packages
adopt the same names, though; not the least because this enables a package to
take advantage of the fact that a systemd unit file that shares a name with a
init.d script will be used in preference to that script. [84]
The /usr/lib/systemd/system directory contains (package-supplied)
systemd unit files that define systemd-managed services, sockets, mount points,
automount entries, and other items. Administrators do not make local
modifications to these files.
Instead, local modifications made by administrators take the form of files in
the /etc/systemd/system directory, which override package-supplied
units entirely, and files in *.conf subdirectories of that
directory, which override parts of the package-supplied units. (See
systemd.unit(8).) Conversely, packages must not make modifications
to these files.
A limited exception to this rule is that packages are permitted to make
once-off conversions, during an upgrade, from information in a
/etc/defaults/package file to systemd unit override
snippets in /etc/systemd/system/*/*.conf files. [85]
The requirements of /run and
/run/lock, Section 9.1.4 apply to unit files under
/run/systemd of course.
For details of unit files please consult the man pages
systemd.unit(8), systemd.exec(8),
systemd.service(8), systemd.socket(8), and
systemd.target(8).
The Type= setting in a service unit file describes the readiness
notification mechanism employed by the daemon. [86] fork()ing at startup and then
exit()ing the main process is one such readiness protocol, denoted
by Type=forking. Unit files should not use this unless the daemon
is genuinely using this as a readiness signal and main process
exit() is genuinely a readiness notification. Most daemons are
not in fact signalling readiness with this. Rather, they are operating in a
convenience mode used when daemons are run from an /etc/rc script.
No Debian init system uses the /etc/rc mechanism. Such daemons
should be run with whatever configuration options or command-line options
instruct them not to gratuitously fork(); and the service unit
files should use a more appropriate Type= setting that denotes the
readiness protocol that they actually employ, if any.
Service unit files must not (directly or indirectly) run commands to mask, unmask, enable, disable, start, or stop either themselves or other services in their Exec...= settings. Such actions must rather be properly expressed with dependency descriptions.
Services also must not (directly or indirectly) invoke other
init.d scripts in their Exec...= settings, as this
can cause incorrect init system operation. (See systemd and upstart and rc, Section
9.3.6.1 for one way that this can cause service control commands to be
indirectly executed.) If an init.d script provides additional
verbs, that functionality must be factored out of the script and placed
elsewhere before it can be used by a service unit file.
Unit files must not install to specific run level (runlevels and /etc/inittab, Section 9.3.4)
targets, because their meanings are the province of local administrators; but
must instead use the standard targets such as multi-user.target
and graphical.target.
Restart=always should be avoided for socket-activated services, as it prevents them from being able to deactivate when idle. For such services, prefer Restart=on-failure or Restart=on-abort.
Sockets and their associated services can be started and stopped independently. When upgrading a package, it is important to account for this in maintainer scripts, and if appropriate stop both. Otherwise, a client connecting to the socket could cause systemd to on-demand activate the service right at the point of the maintainer script where the service is deactivated for upgrading and in an intermediate state where it is not correctly configured for running.
The same consideration applies to D-Bus activated services.
Please note that the update-rc.d and invoke-rc.d in
the sysv-rc package (See systemd and upstart and rc, Section
9.3.6.1.) only operate upon service units and not on the associated socket
units.
Service units should, whereever the daemons do not require privileged access, run services as an unprivileged user and group. Optimally, that user should not own any files and directories to which the daemon does not strictly need ownership access.[87] Maintainer scripts should of course add and delete any such users and groups that are specific to the package, at package installation and removal.
Packages can ship additional items for systemd, including
tmpfiles.d files, sysctl.d files, and
binfmt.d files amonst others. Packages must not ship any such
files under /etc, nor may they make any modifications to such
files under /etc. The files in that subtree are the province of
the local system administrator. All such files must be shipped in the
appropriate subdirectories of /usr/lib.
These or work-alike mechanisms may not be available with other init systems.
However, Policy does not exclude packages from using, and depending upon, a
(hypothetical example) upstart-tmpfilesd for achieving the same
ends when integrated with the upstart init system.
The /etc/init directory contains job files used by the the
upstart init system.
Dependency-based boot managers for init.d scripts, such as
startpar, may avoid running a given script entirely when an
equivalent upstart job is present, to avoid unnecessary forking of no-op init
scripts. In this case, the boot manager should integrate with upstart to
detect when the upstart job in question is started or stopped to know when the
dependency has been satisfied.
Other interactions between init.d scripts and upstart are
described at init.d scripts, Section
9.3.7.
/etc/inittab
System V init's configuration file is /etc/inittab, which
describes a set of "runlevels" and the default runlevel that the
system boots into. systemd has a mechanism that emulates System V init
runlevels, but no init system other than Systemm V init uses or supplies the
/etc/inittab file itself. In order to operate correctly with the
(Linux) default and indeed all but one of the init systems, packages must not
use /etc/inittab.
Maintainer scripts may not assume that a distinct current run level can be determined; because this is not necessarily the case with the default init system. In general, maintainer scripts should avoid any mention of run levels at all. [88]
rc.boot and rc.local
Two Debian bootstrap mechanisms have their roots in non-System-V bootstrap
mechanisms, the /etc/rc.local file and the
/etc/rc.boot directory. The latter was a place where scripts to
be run at boot-up could be placed. [89] It is entirely deprecated and packages must not use it. No
Debian init system now supports this mechanism.
Packages must not use the former; as the name suggests it is for local
administrator bootstrap tasks. Both systemd and System V init
will run an rc.local file if it exists and is executable as a
program. [90]
System V init implements changing between run levels through one
of several rc programs which in turn invoke init.d
scripts (described in init.d scripts,
Section 9.3.7). Packages that wish to provide the System V rc
interface to the System V init system must provide the following
programs:
/etc/init.d/rcS, a program that runs startup elements of the rc
system.
/etc/init.d/rc, a program that init invokes to
enter/leave each run level.
/usr/sbin/invoke-rc.d, a program used by maintainer scripts to
start, stop, enable, and disable scripts, subject to local policy overrides.
(See Starting and stopping scripts with
invoke-rc.d, Section 9.3.6.3.)
/usr/sbin/update-rc.d a program that is used to set/change what
scripts run as each run level is entered and left, and in what order. (See Enabling and disabling scripts with
update-rc.d, Section 9.3.6.2.)
All init systems must provide the latter two, either themselves or through cooperation with an rc package. Only System V init itself also requires the former two from rc packages.
There are three different rc packages in Debian,
sysv-rc, file-rc, and openrc. These
record what scripts are enabled in each runlevel in differing ways. Please
refer to their documentation for the details. systemd has a fourth mechanism
that is largely compatible with sysv-rc, but which has several
differences, such as masking and the overriding priority that is given to
service units.
In general, therefore, maintainer scripts must not assume that the symbolic
link mechanisms (described in previous editions of the Debian Policy Manual)
take effect or even exist at all. Maintainer scripts scripts such as
postinst, prerm and postrm. must use
only the supplied update-rc.d and invoke-rc.d
programs for interacting with the init.d script system.
Only the rc packages themselves, and their various adjunct packages, have any
business (in maintainer scripts) with the /etc/rcn.d
directories (of openrc and sysv-rc) or the
/etc/runlevel.conf file (of file-rc).
In Debian 8, systemd and upstart do not provide their own
invoke-rc.d and update-rc.d. The commands in the
sysv-rc package have been augmented to detect the running init
system and take the appropriate actions for enabling, disabling, starting, and
stopping services. These augmentations do not exist in the
invoke-rc.d and update-rc.d in the
file-rc and openrc packages.
Administrators are encouraged to prefer the service command to
invoking init.d scripts directly, because it attempts to minimize
(even though it cannot totally eradicate) the amount of login session state,
including settings that can potentially break service operations, that leaks
from the administrator's shell running the service command to the
daemon process(es) started by the init.d script. Better still is
to use the systemctl or initctl commands, of course.
init.d scripts for which an equivalent upstart job is available
must query the output of the command initctl version for the
string upstart and avoid running in favor of the native upstart
job, using a test such as this:
if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
then
exit 1
fi
Avoiding running in favour of a native systemd unit is slightly simpler. If an
init.d script sources /lib/lsb/init-functions, the
script will automatically redirect invocations to systemctl.
update-rc.d
The program update-rc.d is provided (by each init/rc system) for
package maintainers to arrange for enabling and disabling the running of
init.d scripts. This may be used by maintainers in their
packages' postinst and postrm scripts. Maintainer
scripts must not attempt to enable and disable scripts directly.
By default update-rc.d will enable services in the multi-user
state, meaning that they will be started in that state and stopped in the halt,
rescue, poweroff, and reboot states.
To get the default behavior for your package, put
update-rc.d package defaults
in your postinst script and put
if [ "$1" = purge ]; then
update-rc.d package remove
fi
in your postrm.
For more information about using update-rc.d, please consult its
man page update-rc.d(8).
invoke-rc.d
The program invoke-rc.d is provided for properly invoking an
init.d script, obeying runlevels, masks, and other
init-system-defined and locally-defined constraints that might limit a
package's right to start, stop and otherwise manage services. Maintainer
scripts must use this program and must not attempt to enable and disable
scripts directly.
For compatibility with the default init system, maintainer scripts must not run
invoke-rc.d with any action requests other than the conventional
start, stop, reload, force-reload, and restart.
Instead of using:
/etc/init.d/<package> <action>
in a package's postinst and prerm scripts packages
must have something like:
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d package <action>
else
/etc/init.d/package <action>
fi
A package should register its init.d services using
update-rc.d before it tries to invoke them using
invoke-rc.d. Invocation of unregistered services may fail on some
init systems.
For more information about using invoke-rc.d, please consult its
man page invoke-rc.d(8).
init.d scripts
The /etc/init.d directory contains scripts that are executed
directly by systemd and upstart, and indirectly by System V init by way of one
of several rc systems (described in System V
rc, Section 9.3.6).
Packages that include daemons for system services may place scripts in
/etc/init.d to start or stop services at boot time or during a
change of runlevel. These scripts should be named
/etc/init.d/package, and they should accept one
argument, saying what to do:
start the service,
stop the service,
stop and restart the service if it's already running, otherwise start the service
cause the configuration of the service to be reloaded without actually stopping and restarting the service,
cause the configuration to be reloaded if the service supports this, otherwise restart the service.
The start, stop, restart, and
force-reload options should be supported by all scripts in
/etc/init.d, the reload option is optional.
An example on which you can base your /etc/init.d scripts is found
in /etc/init.d/skeleton.
The init.d scripts must ensure that they will behave sensibly
(i.e., returning success and not starting multiple copies of a service) if
invoked with start when the service is already running, or with
stop when it isn't, and that they don't kill unfortunately-named
user processes. The best way to achieve this is to switch from an
init.d script to a service unit (systemd
unit files, Section 9.3.1) or a job file (upstart
job files, Section 9.3.3) of course. Whilst remaining an
init.d script however, the best usually for achieving this is to
use start-stop-daemon with the --oknodo option.
Be careful of using set -e in init.d scripts.
Writing correct init.d scripts requires accepting various error
exit statuses when daemons are already running or already stopped without
aborting the init.d script, and common init.d
function libraries are not safe to call with set -e in effect[91]. For init.d
scripts, it's often easier to not use set -e and instead check the
result of each command separately.
If a service reloads its configuration automatically (as in the case of
cron, for example), the reload option of the
init.d script should behave as if the configuration has been
reloaded successfully.
The /etc/init.d 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 conffiles, or, (if they do not exist in the .deb)
by managing them correctly in the maintainer scripts (see Configuration files, Section 10.7).
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 dpkg is executed with the
--purge option will configuration files be removed. In
particular, as the /etc/init.d/package script itself is
usually a conffile, it will remain on the system if the package is
removed but not purged. Therefore, you should include a test
statement at the top of the script, like this:
test -f program-executed-later-in-script || exit 0
Often there are some variables in the init.d 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
conffiles, modifying them requires that the administrator merge in
their changes each time the package is upgraded and the conffile
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 /etc/default, which typically will have the
same base name as the init.d script. This extra file should be
sourced by the script when the script runs. It must contain only variable
settings and comments in SUSv3 sh format. It may either be a
conffile or a configuration file maintained by the package
maintainer scripts. See Configuration
files, Section 10.7 for more details.
To ensure that vital configurable values are always available, the
init.d script should set default values for each of the shell
variables it uses, either before sourcing the /etc/default/ file
or afterwards using something like the : ${VAR:=default} syntax.
Also, the init.d script must behave sensibly and not fail if the
/etc/default file is deleted.
Files and directories under /run, including ones referred to via
the compatibility paths /var/run and /var/lock, are
normally stored on a temporary filesystem and are normally not persistent
across a reboot. The init.d scripts must handle this correctly.
This will typically mean creating any required subdirectories dynamically when
the init.d script is run. See /run and /run/lock, Section
9.1.4 for more information.
init.d scripts
This section describes the formats to be used for messages written to standard
output by the /etc/init.d scripts. The intent is to improve the
consistency of Debian's startup and shutdown look and feel. For this reason,
please look very carefully at the details. We want the messages to have the
same format in terms of wording, spaces, punctuation and case of letters.
Here is a list of overall rules that should be used for messages generated by
/etc/init.d scripts.
The message should fit in one line (fewer than 80 characters), start with a capital letter and end with a period (.) and line feed ("\n").
If the script is performing some time consuming task in the background (not merely starting or stopping a program, for instance), an ellipsis (three dots: ...) should be output to the screen, with no leading or tailing whitespace or line feeds.
The messages should appear as if the computer is telling the user what it is doing (politely :-), but should not mention "it" directly. For example, instead of:
I'm starting network daemons: nfsd mountd.
the message should say
Starting network daemons: nfsd mountd.
init.d script should use the following standard message formats for the situations enumerated below.
When daemons are started
If the script starts one or more daemons, the output should look like this (a single line, no leading spaces):
Starting description: daemon-1 ... daemon-n.
The description should describe the subsystem the daemon or set of daemons are part of, while daemon-1 up to daemon-n denote each daemon's name (typically the file name of the program).
For example, the output of /etc/init.d/lpd would look like:
Starting printer spooler: lpd.
This can be achieved by saying
echo -n "Starting printer spooler: lpd"
start-stop-daemon --start --quiet --exec /usr/sbin/lpd
echo "."
in the script. If there are more than one daemon to start, the output should look like this:
echo -n "Starting remote file system services:"
echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
echo -n " mountd"; start-stop-daemon --start --quiet mountd
echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
echo "."
This makes it possible for the user to see what is happening and when the final daemon has been started. Care should be taken in the placement of white spaces: in the example above the system administrators can easily comment out a line if they don't want to start a specific daemon, while the displayed message still looks good.
When a system parameter is being set
If you have to set up different system parameters during the system boot, you should use this format:
Setting parameter to "value".
You can use a statement such as the following to get the quotes right:
echo "Setting DNS domainname to \"$domainname\"."
Note that the same symbol (") is used for the left and right quotation marks. A grave accent (`) is not a quote character; neither is an apostrophe (').
When a daemon is stopped or restarted
When you stop or restart a daemon, you should issue a message identical to the startup message, except that Starting is replaced with Stopping or Restarting respectively.
For example, stopping the printer daemon will look like this:
Stopping printer spooler: lpd.
When something is executed
There are several examples where you have to run a program at system startup or
shutdown to perform a specific task, for example, setting the system's clock
using netdate or killing all processes when the system shuts down.
Your message should look like this:
Doing something very useful...done.
You should print the done. immediately after the job has been completed, so that the user is informed why they have to wait. You can get this behavior by saying
echo -n "Doing something very useful..."
do_something
echo "done."
in your script.
When the configuration is reloaded
When a daemon is forced to reload its configuration files you should use the following format:
Reloading description configuration...done.
where description is the same as in the daemon starting message.
Packages must not modify the configuration file /etc/crontab, and
they must not modify the files in /var/spool/cron/crontabs.
If a package wants to install a job that has to be executed via cron, it should place a file named as specified in Cron job file names, Section 9.4.1 into one or more of the following directories:
/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
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 /etc/crontab.
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 /etc/cron.d with a name
as specified in Cron job file names, Section 9.4.1.
This file uses the same syntax as /etc/crontab and is processed by
cron automatically. The file must also be treated as a
configuration file. (Note that entries in the /etc/cron.d
directory are not handled by anacron. Thus, you should only use
this directory for jobs which may be skipped if the system is not running.)
Unlike crontab files described in the IEEE Std 1003.1-2008
(POSIX.1) available from The Open
Group, the files in /etc/cron.d and the file
/etc/crontab have seven fields; namely:
Minute [0,59]
Hour [0,23]
Day of the month [1,31]
Month of the year [1,12]
Day of the week ([0,6] with 0=Sunday)
Username
Command to be run
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 crontab 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 cron daemon must provide /usr/bin/crontab and
support normal crontab entries as specified in POSIX. The daemon
must also support names for days and months, ranges, and step values. It has
to support /etc/crontab, and correctly execute the scripts in
/etc/cron.d. The daemon must also correctly execute scripts in
/etc/cron.{hourly,daily,weekly,monthly}.
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 (-) and a suitable suffix.
A cron job file name must not include any period or plus characters (. or +) characters as this will cause cron to ignore the file. Underscores (_) should be used instead of . and + characters.
The Debian menu package provides a standard interface between
packages providing applications and menu programs (either X window
managers or text-based menu programs such as pdmenu).
All packages that provide applications that need not be passed any special command line arguments for normal operation should register a menu entry for those applications, so that users of the menu package will automatically get menu entries in their window managers, as well in shells like pdmenu.
Menu entries should follow the current menu policy.
The menu policy can be found in the menu-policy files in the
debian-policy package. It is also available from the Debian web
mirrors at /doc/packaging-manuals/menu-policy/.
Please also refer to the Debian Menu System documentation that comes
with the menu package for information about how to register your
applications.
MIME (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 (e.g. audio or video) and format (e.g. PNG, HTML, MP3).
Registration of MIME type handlers allows programs like mail user agents and web browsers to invoke these handlers to view, edit or display MIME types they don't support directly.
Packages which provide programs to view/show/play, compose, edit or print MIME
types should register them as such by placing a file in mailcap(5)
format (RFC 1524) in the directory /usr/lib/mime/packages/. The
file name should be the binary package's name.
The mime-support package provides the update-mime
program, which integrates these registrations in the /etc/mailcap
file, using dpkg triggers[92].
Packages using this facility should not depend on, recommend, or
suggest mime-support.
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:
delete the character to the left of the cursor
delete the character to the right of the cursor
emacs: the help prefix
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:
<-- generates KB_BackSpace in X.
Delete generates KB_Delete in X.
X translations are set up to make KB_Backspace generate ASCII DEL,
and to make KB_Delete generate ESC [ 3 ~ (this is the
vt220 escape code for the "delete character" key). This must be done
by loading the X resources using xrdb on all local X displays, not
using the application defaults, so that the translation resources used
correspond to the xmodmap settings.
The Linux console is configured to make <-- generate DEL, and Delete generate ESC [ 3 ~.
X applications are configured so that < deletes left, and Delete deletes right. Motif applications already work like this.
Terminals should have stty erase ^? .
The xterm terminfo entry should have ESC [ 3 ~ for kdch1, just as for TERM=linux and TERM=vt220.
Emacs is programmed to map KB_Backspace or the stty erase character to delete-backward-char, and KB_Delete or kdch1 to delete-forward-char, and ^H to help as always.
Other applications use the stty erase character and kdch1 for the two delete keys, with ASCII DEL being "delete previous character" and kdch1 being "delete character under cursor".
This will solve the problem except for the following cases:
Some terminals have a <-- key that cannot be made to produce anything except ^H. On these terminals Emacs help will be unavailable on ^H (assuming that the stty erase character takes precedence in Emacs, and has been set correctly). M-x help or F1 (if available) can be used instead.
Some operating systems use ^H for stty erase. However, modern telnet versions and all rlogin versions propagate stty settings, and almost all UNIX versions honour stty erase. Where the stty settings are not propagated correctly, things can be made to work by using stty manually.
Some systems (including previous Debian versions) use xmodmap to
arrange for both <-- and Delete to generate
KB_Delete. 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 Delete will not work, but
<-- will.
Some operating systems have different kdch1 settings in their terminfo database for xterm and others. On these systems the Delete key will not work correctly when you log in from a system conforming to our policy, but <-- will.
A program must not depend on environment variables to get reasonable defaults.
(That's because these environment variables would have to be set in a
system-wide configuration file like /etc/profile, 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 which 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:
#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
Furthermore, as /etc/profile is a configuration file of the
base-files package, other packages must not put any environment
variables or other commands into that file.
The doc-base package implements a flexible mechanism for handling
and presenting documentation. The recommended practice is for every Debian
package that provides online documentation (other than just manual pages) to
register these documents with doc-base by installing a
doc-base control file in /usr/share/doc-base/.
Please refer to the documentation that comes with the doc-base
package for information and details.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
Debian Policy Manual
version 3.9.7.0, 2014-11-21