Like all Unices, Debian Linux boots up by executing the program
The configuration file for
init (which is
specifies that the first script to be executed should
/etc/init.d/boot. This script checks and mounts file systems,
loads modules, starts the network services
(by calling the script
sets the clock, performs other initialization, and then runs all of the
scripts (except those with a '.' in the filename) in
The latter script sets the default keyboard, recovers lost editor files,
and configures the serial ports.
After completing the boot process,
init executes all start
scripts in a directory specified by the default runlevel (this runlevel
is given by the entry for
System V compatible Unices, Linux has 6 runlevels:
0 (halt the system), 1 (single-user mode),
2 through 5 (various multi-user modes), and 6 (reboot the system).
Debian Linux systems come with id=2, which indicates that the default
runlevel will be '2' when the multi-user
state is entered, and the scripts in
/etc/rc2.d will be run.
In fact, the scripts in any of the directories,
are just symbolic links back to scripts in
the names of the files in each of the
are selected to indicate the way the scripts in
will be run. Specifically, before entering any
runlevel, all the scripts beginning with 'K' are run; these scripts kill
services. Then all the scripts beginning with 'S' are run; these scripts
start services. The two-digit number following the 'K' or 'S' indicates
the order in which the script is run. Lower numbered scripts are executed
This approach works because the scripts in
take an argument which can be either 'start', 'stop', or 'restart',
and will then do the task indicated by the argument.
For example, with the argument 'restart' the command
/etc/init.d/sendmail restart restarts the sendmail daemon.
These scripts can be used even after a system
has been booted to control various processes.
rc.localto customize the boot process; what facilities are provided?
Suppose a system needs to execute script
foo on start-up,
or on entry to a particular (System V) runlevel. Then the system
foointo the directory
update-rc.dwith appropriate arguments, to set up links between the (command-line-specified) directories rc?.d and
/etc/init.d/foo. Here, '?' is a number from 0 through 6 and corresponds to each of the System V runlevels.
update-rc.d will set up links between files in
the directories rc?.d and the script in
Each link will begin with a 'S' or a 'K', followed by a number, followed
by the name of the script. Scripts beginning with 'S' in
/etc/rcN.d/ are executed when runlevel
N is entered.
Scripts beginning with a 'K' are executed when leaving runlevel
One might, for example, cause the script
foo to execute at bootup,
by putting it in
/etc/init.d/ and installing the links with
update-rc.d foo defaults 19. The argument 'defaults' refers
to the default runlevels, which are 2 through 5. The argument '19' ensures
foo is called before any scripts containing numbers 20
or larger. the appropriate time.
Some users wish to create, for example, a new server by installing a
group of Debian packages and a locally generated package consisting of
configuration files. This is not generally a good idea, because
won't know about those configuration files if they're in a different package,
and may write conflicting configurations when one of the
initial "group" of packages is upgraded.
Instead, create a local package that modifies the config files of the
"group" of Debian packages of interest. Then
dpkg and the rest of the package management system will see
that the files have been modified by the local "sysadmin"
and will not try to overwrite them when those packages are upgraded.
Suppose a sysadmin or local user wishes to use a program "login-local" rather than the program "login" provided by the
login(or any package that provides
loginis installed or updated.
dpkg-override --divert /bin/login.debian /bin/loginin order to cause all future installations of the Debian
loginpackages to write the file
cp login-local /bin/loginto move your own locally-built program into place.
/usr/doc/debian/package-developer/diversions.txt.gzwhich is installed as part of the
You can do this in either of two ways:
dselect, and select the option "Update list of available packages". Then execute the command
dpkg --avail foo.deb, where foo.deb is the name of your locally-built Debian archive file.
dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > Packages.newwhere:
indices/override.main.gzfor the Debian packages in the "main" distribution.
Packages.new, tell the package management system about it by using the command
dpkg --update-avail Packages.new.
There are several cases where two packages provide two different versions of a program, both of which provide the same core functionality. Users might prefer one over another out of habit, or because the user interface of one package is somehow more pleasing than the interface of another. Other users on the same system might make a different choice.
Debian uses a "virtual" package system to allow system administrators to choose (or let users choose) their favorite tools when there are two or more that provide the same basic functionality, yet satisfy package dependency requirements without specifying a particular package.
For example, there might exist two different versions of newsreaders on
a system. The news server package might 'recommend' that there exist
some news reader on the system, but the choice of
trn is left up to the individual user. This is satisfied by
having both the
trn packages provide the
news-reader. Which program is
invoked is determined by a link pointing from a file with the virtual
/etc/alternatives/news-reader to the selected file,
A single link is insufficient to support full use of an alternate
program; normally, manual pages, and possibly other supporting files
must be selected as well. The Perl script
update-alternatives provides a way of ensuring that all the
files associated with a specified package are selected as a system