Package Managers, Libraries, and Processes
- 102.3 – Manage shared libraries
- 102.4 – Use Debian package management
- 102.5 – Use RPM and Yum package management
- 103.5 – Create, monitor, and kill processes
- 103.6 – Modify process execution priorities
Two major package management tools exist for Linux:
- RPM Package Manager (RPM)
- Debian package manager
Their package files, file databases, and details of operation differ — making them incompatible with one another.
Any one program may rely on several other programs or libraries to operate, and these other programs or libraries may also rely on even more programs or libraries as well.
The Linux kernel is the foundation that all programs rely on.
Linux package management tools help to keep track of installed software, and help to install or upgrade new software.
Packages are collections of files which can be installed on a computer.
Typically a package is a single file that expands to many more files upon installation.
Each package contains additional information about itself that is useful for package management systems.
Installed File Database
Package systems maintain a database of installed files.
The database includes information about every file installed via the package system, the name of the package to which each of those files belongs, and associated additional information.
Packaging systems also maintain dependency information — a list of requirements packages have for each other.
Package systems maintain checksums and assorted ancillary information about files; which is used to verify the validity of installed software.
These checksums are intended to help spot:
- Disk errors
- Accidental overwriting of files
- Other non-sinister problems
Note: Because intruders could install altered software through a package system, checksums are of limited use for detecting intrusions.
Upgrades and Uninstallation
By tracking files and dependencies, package systems can easily upgrade or uninstall packages.
Binary Package Creation
The RPM and Debian package systems both provide tools to help create binary packages from source code.
This has advantages over compiling software from source, because you can use a package management system to track dependencies, attend to individual files, etc.
Note: If the developers of a package didn’t provide explicit support for a peculiar CPU you are using, this feature can be used to install software on it.
The most popular package manager for Linux is the RPM Package Manager (RPM).
Red Hat developed RPM for its own distribution, but released the software under the General Public License (GPL) so that others are free to use it in their own Linux distributions.
Red Hat is largely comprised of three distributions:
- Fedora – The testbed for new developments.
- Red Hat Enterprise Linux (RHEL) – The for-pay enterprise distribution with support.
- CentOS (Community Enterprise OS) – The free version of RHEL essentially.
Mandriva (formerly Mandrake) and Yellow Dog are based on Red Hat, so they use RPMs.
SUSE uses RPMs as well, but is not as similar to Red Hat.
RPM supports any CPU architecture.
For the most part, source RPMs are transportable across architectures — the same source RPM can be used to build packages for x86, AMD64, PowerPC, ARM, SPARC, etc.
Some programs are composed of architecture-independent scripts and need no recompilation to run on other CPUs.
The naming convention for RPM packages is as follows:
packagename is the name of the package.
a.b.c is the version number. It’s not required to be three numbers separated by dots, but that’s the most common form.
x is the build number / release number. This number represents minor changes made by the package maintainer, not by the program author. These changes may represent altered startup scripts or configuration files, changed file locations, added documentation, or patches appended to the original program to fix bugs or to make the program more compatible with the target Linux distribution.
arch is a code for the package’s architecture. The
i386 architecture code represents a file compiled for any x86 CPU from 80386 onward. Pentium and newer may use
i686. PowerPC uses
ppc. x86-64 platforms use
x86_64. Scripts, documentation, and other CPU-independent packages generally use the
noarch architecture code.
Note: The information in the filename of an RPM package is retained within the package. This can be helpfulif you must rename an RPM package and need to know it’s original filename details.
Compatibility issues between RPM packages and certain RPM distributions can crop up from time to time for the following reasons:
- Distributions may use different versions of the RPM utilities.
- An RPM package designed for one distribution may have dependencies that are unmet in another distribution.
- An RPM package may be built to depend on a package of a particular name (such as samba-client depending on samba-common) and the distribution in use has named the package differently (ex. samba-com). Note: This objection can be overridden by using the
--nodepsswitch but the package may not work once installed.
- Even when a dependency appears to be met, different distributions may include slightly different files in their packages.
RPM meta-packagers, such as the “Yellow Dog Updater, Modified” (YUM), can simplify locating and installing packages designed for your distribution.
rpm Command Set
The main RPM utility program:
rpm [operation] [options] [package-files|package-names]
||Installs a package.
Note: System must not contain a package of the same name.
||Installs a new package or upgrades an existing one.|
||Upgrades a packages only if an earlier version already exists.|
||Queries a package — finds whether a package is installed, what files it contains, etc.|
||Verifies a package — checks that its files are present and unchanged since installation.|
||Uninstalls a package.|
|| Builds a binary package, given source code and configuration files.
Note: Moved to the
|| Builds a binary package, given a source RPM file.
Note: Moved to the
||Rebuilds the RPM database to fix errors.|
|Option||Compatible w/ Operations||Description|
||Modifies the Linux system with a root directory at
||Forces installation of a package even when it means overwriting existing files or packages.|
||Displays hash marks (
||Used in conjunction with
Prevents dependency checks.
Checks for dependencies, conflicts, and other problems without installing the package.
||Sets the installation directory to
||Queries or verifies all packages.|
||Queries or verifies the package that owns
||Queries the uninstalled RPM
||Displays package information, including the package maintainer, a short description, etc.|
||Displays the packages and files on which this package depends.|
||Lists the files contained in the package.|
rpm command can be used with one or more packages, separated by spaces.
Installing multiple packages with a single command is recommended — as it ensure dependent packages are installed first.
Some operations require a filename, while others require a package name:
-i, -U, -F, and the
rebuildoperations require package filenames.
-erequire a package name.
-pcan be used to modify
-qto use a package filename.
-U operation is recommended — as it enables the installation of a package without having to manually uninstall the old one first:
# rpm -Uvh samba-4.1.9-4.fc20.x86_64.rpm
-qi operations can be combined to verify that a package is installed; and displays information such as when and where the binary package was built.
Extracting Data from RPMs
RPM files are actually modified
rpm2cpio program can be used to convert .rpm files to .cpio files:
$ rpm2cpio samba-4.1.9-4.fc20.src.rpm > samba-4.1.9-4.fc20.src.cpio
cpio program can be used to extract .cpio archived files:
$ cpio -i --make-directories < samba-4.1.9-4.fc20.src.cpio
-i option is for extraction, and the
--make-directories option is used to create directories.
An alternative option is to pipe the two commands together without creating an intermediary file:
$ rpm2cpio samba-4.1.9-4.fc20.src.rpm | cpio -i --make-directories
When extracting binary packages, the output is likely to be a series of subdirectories that mimic the layout of the Linux root directory (i.e.
When extracting a source package, the output is likely to be a source code tarball, a .spec file (which holds information that RPM uses to build the package), and some patch files.
Another option for extracting data from RPMs is
alien. It can convert an RPM into a Debian package or a tarball.
Yum is one of several meta-packagers — which allows the installation of packages and its dependencies easily using a single command line:
yum [options] [command] [package...]
Yum does this by searching repositories — Internet sites that host RPM files for a particular distribution.
Yum originated from the Yellow Dog Linux distribution, and was later adopted by Red Hat distributions (RHEL, CentOS, Fedora, etc.) and other RPM-based distributions.
Note: Not all RPM-based distributions use Yum. SUSE and Mandriva both use their own meta-packager. Debian-based distributions typically use the Advanced Package Tools (APT).
|install||Installs one or more packages by package name, and also installs dependencies of the specified packages.|
|update||Updates the specified packages to the latest version.
If no packages are specified, yum updates every installed package.
||Checks to see if any updates are available. If they are,
|Deletes a package from the system; similar to
|list||Displays information about a package, such as the installed version and whether an update is available.|
|Displays information about packages that provide a specified program or feature.|
|search||Searches package names, summaries, packagers, and descriptions for a specified keyword.|
|info||Displays information about a package, similar to
||Cleans up the Yum cache directory.
Running this command from time to time is advisable, lest downloaded packages chew up too much disk space.
||Enters the Yum shell mode, which allows multiple Yum commands to be entered one after another.|
||Displays packages matching the specified dependency.|
||Installs the specified local RPM files, using your Yum repositories to resolve dependencies.|
||Updates the system using the specified local RPM files, using your Yum repositories to resolve dependencies.|
||Displays dependencies of the specified package.|
Yum is only as good as its repositories, and cannot install software that’s not stored in those repositories.
To download a package without installing it, the
yumdownloader command can be used.
GUI frontends do exist for Yum, such as
RPM and Yum Configuration Files
The main RPM configuration file is
This file should not be edited directly, instead a
/etc/rpmrc (to make global changes) or a
~/.rpmrc (to make per-user changes) file should be created.
These files set a variety of options, mostly related to the CPU optimizations used when compiling source packages. For example, to optimize code for a particular CPU model, the appropriate compiler options can be provided with the
optflags: athlon -O2 -g -march=i686
Note: The previous line tells RPM to pass the
-O2 -g -march-i686 options to the compiler whenever it’s building for the
rmprc files include a series of
buildarchtranslate lines that cause
rpm for older version of RPM) to use one set of optimizations for a whole family of CPUs. For x86 systems, these lines typically look like:
buildarchtranslate: athlon: i386
buildarchtranslate: i686: i386
buildarchtranslate: i586: i386
buildarchtranslate: i486: i386
buildarchtranslate: i386: i386
These lines tell RPM to translate the
i386 CPU codes to use the
i386 optimizations. This effectively defeats the purpose of any CPU-specific optimizations created on the
optflags line, but it guarantees that the RPMs built will be maximally portable. To change this, the line for CPU type must be altered (which can be found with
uname -p). For example, to prevent this on an Athlon-based system, enter the following line:
buildarchtranslate: athlon: athlon
The previous line will give a slight performance boost on Athlon systems, but at the cost of reducing portability.
Yum is configured via the
/etc/yum.conf file, with additional configuration files in the
yum.conf file holds basic options, such as the directory where Yum downloads RPMs and where Yum stores its logs.
/etc/yum.repos.d/ directory can hold several files, each of which describes a Yum repository.
New repositories can be downloaded as RPMs that can be installed via the
Several popular Yum repositories exist:
|Livna||Hosts multimedia tools, such as additional codes and video drivers.
|KDE Red Hat||Contains improved KDE RPMs for those that favor KDE over GNOME (GNU Network Object Model Environment).
|Fresh RPMs||Provides additional RPMs focused on multimedia applications and drivers.
Note: Many additional Yum repositories exist. A web search for “yum repository” will reveal many other repositories.
RPM Compared to Other Package Formats
When compared to Debian packages, the greatest strength of RPMs is their ubiquity. Many software packages are available in RPM form from the developer and/or their distribution maintainers.
RPMs made for one Linux distribution can often be used for another distribution, but sometimes this can lead to a mismatch of conflicting packages.
Note: To find RPMs for a specific program, RPMFind (http://rpmfind.net/) can be extremely helpful. Likewise, Fresh RPMs (http://freshrpms.net/) can be helpfulfor finding RPMs as well.
Using Debian Packages
Debian packages require knowing how to use the
Debian Distributions and Conventions
Debian, Ubuntu, Linux Mint, and Xandros use the Debian package manager. As such, most packages that work with Debian will likely work with other Debian-based systems.
Although Debian doesn’t emphasis the use of GUI configuration tools, its derivatives tend to be more GUI-centric, which makes them more appealing to Linux novices.
Like RPM, the Debian package format is neutral with respect to both OS and CPU type.
Attempts to use the Debian package system and software library on top of non-Linux kernels have been largely abandoned, with the exception of kFreeBSD (http://www.debian.org/ports/kfreebsd-gnu/).
The original Debian distribution has been ported to many different CPUs, including
Debian packages follow a similar naming convention as RPMs, but packages sometimes omit codes in the filename to specify a package’s architecture, particularly on x86 packages. For example, a filename ending in
i386.deb indicates an x86 binary,
powerpc.deb is a PowerPC binary, and
all.deb indicates a CPU-independent packages (such as documentation or scripts).
There is no code for Debian source packages because they consist of several separate files.
dpkg Command Set
Debian packages are incompatible with RPM packages, but the principles of their operation are the same.
dpkg command can be used to install a Debian package:
dpkg [options] [action] [package-files | package-name]
|Installs a package.|
|––configure||Reconfigures an installed package:
runs the post-installation script to set site-specific options.
||Removes a package but leaves its configuration files intact.|
|Removes a package (including its configuration files).|
|––get-selections||Displays currently installed packages.|
|Displays information about an installed package.|
|Displays information about an uninstalled package file.|
|Lists all installed packages whose names match
|Lists the files associated with a package.|
||Locates packages that own the files specified by
||Searches for partially installed packages and suggests what to do with them.|
|Option||Compatible w/ Actions||Description|
||Modifies the Linux system with a root directory at
||Disables packages that rely on one that is being removed.|
||Overrides defaults that would ordinarily cause
||Ignores dependency information for the specified package.|
||Checks for dependencies, conflicts, and other problems without actually installing or removing the package.|
||Installs all packages that match the package-name wildcard in the specified directory and all subdirectories.|
||Doesn’t install the package if a newer version of the same package is already installed.|
||Doesn’t install the package if the same version of the package is already installed.|
dpkg expects a package name or a package filename depending on the command. For instance,
-I both require a package filename, but other commands take the shorter package name. An example of this would be installing a Samba package:
# dpkg -i samba_4.1.6+dfsg-1ubuntu2.1404.3_amd64.deb
Before upgrading a package, the old package may need to be removed first. To do this, use the
-r option with
# dpkg -r samba
To find information about an installed package, use the
# dpkg -p samba
Debian-based systems often use a pair of somewhat higher-level utilities (
dselect) to handle package installation and removal. However,
dpkg is often more convenient when you’re manipulating just one or two packages.
dpkg can take package filenames as input, it’s the preferred method of installing a package that was downloaded from an unusual source or created by yourself.
The APT suite of tools includes a program,
apt-cache, that’s intended solely to provide information about the Debian package database (known in Debian terminology as the
Common features of
|Feature||Description and Subcommands|
|Display Package Information||Using the
Note: The information displayed is different from
|Display Package Statistics||Passing the
|Find Unmet Dependencies||Using
This subcommand returns information about unmet dependencies, which may help to track down the source of missing-file problems.
|Local All Packages||The
If a second parameter is provided with this subcommand it will display only the packages that begin with the specified string (ex.
apt-cache subcommands are intended for package maintainers and debugging serious package database problems rather than day-to-day system administration. Consult the
man page for
apt-cache for more information.
APT, and it’s
apt-get utility, is Debian’s equivalent to Yum on certain RPM-based distributions.
Debian-based systems include a file,
/etc/apt/sources.list, that specifies locations where important packages can be obtained.
Note: Do not add a site to
/etc/apt/sources.list unless it can be trusted. The
apt-get utility does automatic and semi-automatic upgrades. If unreliable or vulnerable programs exist in a network source added to the sources list, your system will become vulnerable after upgrading via
Although APT is most strongly associate with Debian systems, a port for RPM-based systems is also available (see: http://apt4rpm.sourceforge.net/).
apt-get utility works by obtaining information about available packages from the sources listed in
/etc/apt/sources.list and uses that information to upgrade or install packages:
apt-get [options] [command] [package-names]
|Option||Compatible w/ Commands||Description|
||Downloads package files but doesn’t install them.|
||Attempts to fix a system where dependencies are unsatisfied.|
||Ignores all package files that can’t be retrieved (because of network errors, missing files, etc.).|
||Omits some progress indicator information. May be doubled (for instance
||Performs a simulation of the action without actually modifying, installing, or removing files.|
||Produces a “yes” response to any yes/no prompt during the installation script.|
||Compiles a source package after retrieving it.|
||Obtains updated information about packages available from the installation sources listed in
||Upgrades all installed packages to the newest versions available, based on locally stored information about available packages.|
||Performs any changes in package status (installation, removal, etc.) left undone after running
||Installs a package by package name (not by package filename), obtaining the package from the source that contains the most up-to-date version.|
||Removes a specified package by package name.|
||Retrieves the newest available source package file by package filename, using information about available packages and installation archives listed in
||Checks the package database for consistency and broken package installations.|
||Performs housekeeping to help clear out information about retrieved files from the Debian package database.
In most cases, no options will be used with
apt-get, just a single command and possibly one or more package names. For example, keeping the system up-to-date with any new packages:
# apt-get update
# apt-get dist-upgrade
aptitude, and Synaptic
dselect program is a high-level text-mode package browser that uses the APT archives defined in
aptitude is another text-based Debian package manager; which combines the interactive features of
dselect with the command-line options of
In interactive mode,
aptitude is similar to
aptitude adds menus accessed by pressing
Searching for packages with
aptitude can be performed with
$ aptitude search samba
aptitude on command line and interactive mode:
|Update Package Lists||
||Installs packages matching
||Both options upgrade all installed packages, but
|Search for Packages||
||Searches the database for packages matching the specified name.
The result is a list of packages, one per line, with a summary code for each package’s install status, name, and description.
|Clean Up the Database||
||Displays a list of all options for
A tool that is similar to
aptitude is the GUI X-based program, Synaptic.
Debian packages often provide more-extensive initial setup options than their RPM counterparts. Frequently, the install script included in the package asks a handful of questions. These questions help the package system set up a standardized configuration that is customized for the machine.
To revert to initial standard configuration, the
dpkg-reconfigure program can be used:
# dpkg-reconfigure samba
The above command will reconfigure the
samba package, ask its initial installation questions again, and restart the Samba daemon.
Debian Packages Compared to Other Package Formats
Debian source packages aren’t single files; they are groups of files — the original source tarball, a patch file that’s used to modify the source code (including a file that controls the building of a Debian package), and an optional
.dsc file that contains a digital “signature” to help verify the authenticity of the collection.
Debian package tools combine and compile source packages to create a Debian binary package.
Whereas RPM source packages may contain multiple patch files, Debian source packages only support one single patch file.
Because all distributions that use Debian packages have derived from Debian, almost all are more compatible with one another than RPM-based distributions are to each other.
It is generally more difficult to locate Debian packages than RPMs for exotic programs. If no Debian package can be found,
alien can be used to convert an RPM to a Debian format.
Debian maintains a good collection of packages at http://www.debian.org/distrib/packages/.
Configuring Debian Package Tools
The main configuration file for
This file contains
dpkg options, but without leading dashes. For example, to force
dpkg to always do a test run instead of installation a
dpkg.cfg file could contain:
For APT, the main configuration file that is likely to be modified is
Another APT configuration file is
/etc/apt/apt.conf, which controls APT and
The format to modify the
apt.conf file is complex and modeled after the Internet Software Consortium’s (
ISC's) Dynamic Host Configuration Protocol (
DHCP) and Berkeley Internet Name Domain (
BIND) server configuration files. Options are grouped together by open and close curly braces (
Note: These lines are equivalent to setting the
--download-only option permanently.
For more information on the
apt.conf file, consult
man page; and review the sample configuration file at
Debian’s package tools rely on various files in the
/var/lib/dpkg directory tree. These files maintain lists of available packages, lists of installed packages, etc. — effectively making it the Debian installed file database. Due to this directory’s importance, careful consideration should be made before modifying its contents; and backing up this directory is recommended when performing system backups.
Converting between Package Formats
When the appropriate package for a distribution is unable to be found there are several options:
- Continue searching for the appropriate package.
- Create a package from a source tarball using standard RPM or Debian tools.
- Convert between package formats with a utility like
alien program comes with Debian and a few other distributions, but it can be installed by typing
alien on APT systems. Alternatively, it can be found on RPMFind or Debian’s package website.
This program can convert between:
- Debian packages
- RPM packages
- Stampede packages
In order to convert packages, the package management software for each package must be installed (i.e. RPM and Debian package managers must both be installed to convert between RPM and Debian packages).
alien requires both RPM and Debian package systems to be installed to convert between these formats, it doesn’t use the database features of these packages unless the
--install option is used.
alien utility doesn’t always convert all dependency information completely and correctly.
When converting from a tarball,
alien copies the files directly as they had been in the tarball, so
alien works only if the original tarball has files that should be installed off the root (
/) directory of the system.
The syntax for
alien [options] file[...]
||Converts to Debian package.
Note: This is the default option if no option is explicitly provided.
||Converts to RPM package.|
||Converts to Stampede package.|
||Converts to tarball format.|
||Installs the converted package and removes the converted file.|
As an example, to convert a Debian package called
myprogram-1.0.1-3_i386.deb to an RPM:
# alien --to-rpm myprogram-1.0.1-3_i386.deb
To install a tarball on a Debian-based system and keep a record of the files it contains in the Debian package database:
# alien --install binary-tarball.tar.gz
Note: The important thing to remember is that converting a tarball converts the files in the directory structure of the original tarball using the system’s root directory as the base. As such, it may be necessary to unpack the tarball, shuffle the files around, and then repack it to get the desired results before installing it with
Package Dependencies and Conflicts
The usual sources of problems relate to unsatisfied dependencies or conflicts between packages.
Real and Imagined Package Dependency Problems
Package dependencies and conflicts can arise for a variety of reasons:
|Missing Libraries or Support Programs||A missing support package is one of the most common dependency problems.
For example, all KDE programs rely on Qt, a widget set that provides assorted GUI tools. If Qt is not installed, no KDE packages will be able to be installed using RPM or Debian packages.
Libraries — support code that is used by many different programs — are also a common source of problems.
|Incompatible libraries or Support Programs||Even if a library or support program is installed, it may be the wrong version.
For example, if a program requires Qt 4.8 but Qt 3.3 is installed, it will not run.
Fortunately, Linux library-naming conventions allow for the installation of multiple versions of a library.
|Duplicate Files or Features||A conflict can arise when one package includes files that are already installed and belong to another package.|
|Mismatched Names||Sometimes package names between RPM and Debian distributions do not match across different distributions.
For example, if one package checks for another package by name, the first package may not install, even if the appropriate package is installed with a different name.
Workarounds for Package Dependency Problems
The options to confront an unmet package dependency or conflict include:
- Forcing the installation.
- Modifying the system to meet the dependency.
- Rebuilding the problem package from source code.
- Finding another version of the problem package.
Forcing the Installation
--nodeps parameter can be used to ignore failed dependencies using
# rpm -i package.rpm --nodeps
--force parameter can be used to force installation despite errors (such as conflicts with existing packages):
# rpm -i package.rpm --force
Note: It is not recommended to use
--force without first determining the reason for ignoring the dependency checks and errors preventing installation without these parameters.
--force-conflicts parameters can be used to overcome dependency and conflict problems on Debian-based systems.
Upgrading or Replacing the Depended-on Package
The proper way to overcome a package dependency problem is to install, upgrade, or replace the depended-on package. For example, if a program requires Qt 4.8+, the older version currently installed should be upgraded to that version.
Rebuilding the Problem Package
Rebuilding a package from source code can overcome some dependencies.
Fedora (and other developer-oriented RPM-based systems) include commands to rebuild RPM packages if the source RPM for the package is available:
# rpmbuild --rebuild packagename-version.src.rpm
The above command extracts the source code and executes whatever commands are required to build a new package (or sometimes several new packages). The output of this command should be one or more binary RPMs located in
Note: Older versions of RPM use the
rpm command instead of
Be aware that compiling a source package typically requires the appropriate development tools to be installed, such as the GNU Compiler Collection (
GCC) and other assorted development libraries.
Development Libraries (which typically include “dev” or “devel” in their names) are the parts of a library that enable programs to be written for the library.
Locating Another Version of the Problem Package
Sites like RPMFind (http://www.rpmfind.net/) and Debian’s package listing (http://www.debian.org/distrib/packages/) can be useful in tracking down alternative versions of a package.
Startup Script Problems
In the past, most Linux distributions used SysV startup scripts, but these scripts weren’t always transportable between distributions. For instance, systemd has become a more common startup option, and SysV scripts are not compatible with systemd.
Possible workarounds include:
- Modifying the included startup scripts.
- Building a new script based on another one from the distribution in use.
- Using a local startup script (such as
Note: Startup script problems affect only servers and other programs that are started automatically when the computer boots; they do not affect typical user applications or libraries.
Managing Shared Libraries
Most Linux software relies heavily on shared libraries.
Libraries are software components that can be used by many different programs.
The idea behind a library is to simplify the lives of programmers by providing commonly used program fragments. For example, one of the most important libraries is the C library (
libc), which provides many of the higher-level features associated with the C programming language.
Another common type of library is associated with GUIs. These libraries are often called widget sets because they provide onscreen widgets used by programs — buttons, scroll bars, menu bars, etc. The GIMP Tool Kit (
GTK+) and Qt are the most popular Linux widget sets, and both ship largely as libraries.
Programmers choose libraries, not users; and one library cannot be substituted for another (the main exception being minor version upgrades).
Note: Linux uses the GNU C library (
glicb) version of the C library. As of glibc 2.15, the main glibc file is usually called
/lib64/libc.so.6, but this file is sometimes a symbolic link to a file of another name, such as
Most programs use their libraries as shared libraries (aka dynamic libraries). This approach helps keep program file size down, enables sharing of the memory consumed by libraries across programs, and enables programs to take advantage of improvements in libraries by upgrading the library.
Note: Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions. In Linux, however, shared libraries usually have a
.so.<version> extension (
.so stands for shared object). Linux static libraries (used by linkers for inclusion in programs when dynamic libraries are not to be used) have
.a filename extensions.
Linux uses library-numbering schemes to permit multiple versions of a library to be installed at once.
Note: Developers who create programs using particularly odd, outdated, or otherwise exotic libraries sometimes use static libraries. This enables them to distribute their binary packages without requiring users to obtain and install their oddball libraries. Likewise, static libraries are sometimes used on small emergency systems, which don’t have enough programs installed to make the advantages of shared libraries worth pursuing.
Locating Library Files
The major administrative challenge of handling shared libraries involves enabling programs to locate those shared libraries.
Binary program files can point to libraries either by name alone (as in
libc.so.6) or by providing a complete path (as in
/lib/libc.so.6). In the first case, you must configure a library path — a set of directories where programs should search for libraries.
After making a change to the library path or complete path, you may need to use a special command to get the system to recognize the change.
Setting the Path System Wide
The first way to set the library path is to edit the
This file consists of a series of lines, each of which lists one directory in which shared library files may be found. Typically, this file lists between half a dozen and a couple dozen directories. These lines begin with the
include directive — which lists files that are to be included as if they were part of the main file. For example, Ubuntu 12.04’s
ld.so.conf file begins with:
The above line tells the system to load all of the files in
/etc/ld.so.conf.d whose name ends in
.conf as if they were part of the main
Some distributions, such as Gentoo, do something a little different but with the same goal. With these distributions, the
env-update utility reads files in
/etc/env.d to create the final form of several
/etc configuration files, including
/etc/ld.so.conf. In particular, the
LDPATH variables in these files are read, and their values make up the lines in the
ld.so.conf file. Thus, to change
ld.so.conf in Gentoo or other distributions, you should add or edit files in
/etc/env.d and type
env-update to finalize the changes.
Library package files usually install themselves in directories that are already on the path or add their paths automatically. However, if you installed a library package, or a program that creates its own libraries, in an unusual location via mechanisms other than your distribution’s main package utility, you may need to change the library path system wide.
After changing the library path, the
ldconfig command must be run to have programs use the new path.
Note: In addition to the directories specified in
/etc/ld.so.conf, Linux refers to the trusted library directories,
/usr/lib. These directories are always on the library path, even if they aren’t listed in the
Temporarily Changing the Path
LD_LIBRARY_PATH environment variable can be set to a directory (or directories) containing shared libraries:
$ export LD_LIBRARY_PATH=/usr/local/testlib:/opt/newlib
This environment variable accepts a single directory or multiple directories, separated by colons.
Directories specified in
LD_LIBRARY_PATH are added to the start of the search path, making them take precedence over other directories.
A user’s shell startup script files can be edited to permanently set the
LD_LIBRARY_PATH environment variable, if desired.
In principle, the
LD_LIBRARY_PATH environment variable could be set globally; however, using the
/etc/ld.so.conf file is the preferred method of effecting global changes to the library path.
Unlike other library path changes, this one doesn’t require that you run
ldconfig for it to take effect.
gimp: error while loading shared libraries: libXinerama.so.1:
open shared object file: No such file or directory
The above error message indicates that the system couldn’t find the
libXinerama.so.1 library file. The usual cause of such problems is that the library isn’t installed, so you should look for it using commands such as
find. If the file isn’t installed, try tracking down the package to which it should belong using a web search and install it.
If the library file is available, its directory may need to be added globally or to the
LD_LIBRARY_PATH environment variable.
Sometimes the library’s path is hard-coded in the program’s binary file (this can be checked with
ldd). When this happens, you may need to create a symbolic link from the location of the library on your system to the location that the program expects.
A similar problem can occur when the program expects a library to have one name but the library has another name on your system. For example, a program may link to
biglib.so.5.2 is installed. Since minor version number changes are usually inconsequential, creating a symbolic link should correct this problem:
# ln -s biglib.so.5.2 biglib.so.5
Note: This command must be run as root in the directory where the library resides, and
ldconfig must be run thereafter.
Library Management Commands
ldd program displays a program’s shared library dependencies — the shared libraries that a program uses.
ldconfig program updates caches and links used by the system for locating libraries — that is, it reads
/etc/ld.so.conf and implements any changes in that file and any directories it refers to.
Displaying Shared Library Dependencies
If a program won’t launch because of missing libraries, the first step is to check which libraries it uses:
$ ldd /bin/ls
Each line of output from
ldd begins with a library name. If the library name doesn’t contain a complete path,
ldd attempts to find the true library and displays the complete path following the
ldd command accepts a few options. The most notable of these is probably
-v, which displays a long list of version information following the main entry. This information may be helpfulin tracking down which version of a library a program is using, in case there are multiple versions installed on your system.
Libraries can also depend on other libraries, which means
ldd can be used on libraries as well. This can be useful if all the dependencies are met for a program but it still fails to load due to missing libraries.
Rebuilding the Library Cache
Linux (or, more precisely, the
ld-linux.so programs, which manage the loading of libraries) doesn’t read
/etc/ld.so.conf every time a program runs. Instead, the system relies on a cached list of directories and the files they contain, stored in binary format in
This list is maintained in a format that’s much more efficient than a plain-text list of files and directories. The drawback is that it must be rebuilt every time libraries are added or removed. These changes include additions or removals of both the contents of the library directories and adding or remove the directories themselves.
The tool to update the
/etc/ld.so.cache file is
Common options to modify
|Display Verbose Information||
||Displays a summary of directories and files being registered.|
|Do Not Rebuild the Cache||
||Prevents a rebuild of the library cache, but updates symbolic links to libraries.|
|Process Only Specified Directories||
||Ignores the directories specified in
|Do Not Update Links||
|Use a New Configuration File||
||Changes the configuration file from
|Use a New Cache File||
||Changes the cache file from
|Display Current Information||
Note: This option is helpfulif recovering from a badly corrupted system, or if installing a new OS.
Both RPM and Debian library packages typically run
ldconfig automatically after installing or removing packages.
When you type a command name, that program is run and a process is created for it.
Understanding the Kernel: The First Process
The Linux kernel is at the heart of every Linux system.
uname command can be run to reveal details about the kernel being run.
Common options for
||Displays the system’s node name / network hostname.|
||Displays the kernel name (typically ‘
||Displays kernel version (usually a kernel build date and time, and not an actual version number).|
||Displays the actual kernel version number.|
||Displays information about the machine (generally CPU code, such as x86_64 or i686, etc.).|
||May display information about the CPU; such as, manufacturer, model, and clock speed. In most cases it just returns ‘
||Is supposed to display hardware information but often returns just ‘
||Returns the OS name (normally ‘
|Print All Information||
||Displays all available information.|
Examining Process Lists
One of the most important tools in process management is
ps — which displays processes’ statuses:
ps command supports three option types:
||Single-character options, can be grouped together.
||Single-character options, can be grouped together.
|GNU Long Options||
||Multi-character options (strings), cannot be grouped together.
The reason for so many supported option types is because the
ps utility has historically varied a lot from one Unix OS to another, and support for almost all different implementations has been included with
ps on most major Linux distributions. This behavior can be changed by setting the
PS_PERSONALITY environment variable to
|Display All Processes||
|Display One User’s Processes||
||Display processes owned by a particular user.
|Display Extra Information||
||Expands the information provided in the
|Display Process Hierarchy||
||Groups processes and uses indentation to show the hierarchical relationship between processes.|
|Display Wide Output||
The output from the
ps command typically starts with a heading line, which displays the meaning of each column:
|Username||The name of the user running this program/process.|
|Process ID (
||A number that’s associated with the process.|
|Parent Process ID (
|TTY||The teletype (
Note: Not all processes have a TTY number; only text-mode programs do.
Positive values represent reduced priority, and
negative values represent increased priority.
Some outputs include a
|Command||The final column in most listings is the command that was used to launch the process.|
Note: To find specific processes and their PIDs:
$ ps ax | grep <command>
Processes that aren’t linked to others were either started directly by
init, or have had their parent processes killed and were “adopted” by
top: A Dynamic
top is a useful command to display task manager of sorts, which displays information such as which processes are consuming CPU time relative to one another.
top sorts entries by CPU use, and it updates the display every few seconds.
There are also GUI variants of
top, such as
||Changes the update time to
||Monitor specific processes by PID.
Note: Specify up to 20 PIDs by using this option multiple times (once for each PID).
||Display a specific number of updates then quit.|
||Batch mode. Do not use normal screen-update commands. Useful for logging CPU use to a file.|
top is running, interactive commands can be entered:
||Displays help information.|
||Kills a process after prompting for its PID.|
||Change a process’s priority (i.e.
Note: Only root may increase a process’s priority.
||Prompts for a new update rate in seconds.|
||Sort by CPU usage (default).|
||Sort by memory usage.|
Note: To look at just memory usage, use the
free command. It provides a quick reference of how much physical memory and swap memory is in use, and how much remains available.
One of the pieces of information provided by
top is the load average, which is a measure of the demand for CPU time by applications (
0.0 represents no load,
1.0 represents full load on a CPU core).
Note: Most computers these days include multiple CPUs or CPU cores. On such systems, the load average can equal the number of CPUs or cores before competition for CPU time occurs. For example, a quad-core CPU can go up to a load average of
4.0 before any contention occurs between processes demanding CPU time. Typically, one program can create up to a load of
1.0; however, multithreaded programs can create higher load averages because they can take advantage of multiple CPUs, cores, or multithreaded cores.
The three load-average estimates displayed on the top line of
top correspond to the current load average and two previous measures.
The current load average can also be found with the
uptime command, which displays load averages along with information about how long the machine has been running for.
jobs: Processes Associated with Your Session
jobs command displays minimal information about the processes associated with the current session, such as job ID numbers. These numbers are similar to PID numbers, but not the same.
Jobs are numbered starting from
1 for each session, and generally a single shell will only have a few associated jobs.
jobs command can also be used to ensure all programs have terminated prior to logging out.
pgrep: Finding Processes
pgrep command was introduced under the Solaris operating system. It performs a simple search within the process list (similar to
ps piped to
pgrep [-flvx] [-n | -o] [-d <delim>] [-P <ppidlist>] [-g <pgrplist>] [-s <sidlist>] [-u <euidlist>] [-U <uidlist>] [-G <gidlist>] [-J <projidlist>] [-t <termlist>] [-T <taskidlist>] [-c <ctidlist>] [-z <zoneidlist>] [pattern]
Processes can be searched based on username, user ID, or group ID; and can include an additional regular expression pattern:
$ pgrep -u root cron
The above command will search for processes named ‘cron’ that are run by the root user, and returns the process ID value of the processes that match.
Understanding Foreground and Background Processes
Normally, when a program is launched, it takes over the terminal, and prevents any other work from being done on that terminal (note: some programs do release the terminal).
Ctrl+z can pause the program and give control of the terminal back.
To get back to the program that was paused, use the
fg command. This brings it back to the foreground of the terminal.
If multiple processes have been paused/suspended, a job number can be provided to the
fg command to ensure it brings that specific process back to the foreground:
$ fg 2
A variant on
fg is the
bg command, which brings a job to the background and keeps it running, while restoring access to the terminal.
bg command is often usefulwhen launching GUIs from the command line — as the shell window that launched the program is tied up while the GUI is being displayed. Pressing
ctrl+z on the command line will pause the GUI program, and then entering the
bg command will unfreeze it as it gets moved to the background of the terminal.
An alternative to using
bg, is to append an ampersand (
&) to the command when launching the program:
$ nedit myfile.txt &
The above command will launch the
nedit program in the background from the start.
Managing Process Priorities
nice command can be used to launch a program with a specific priority, and the
renice command can be used to alter the priority of a running program.
nice command has the following syntax:
nice [argument] [command [command-arguments]]
There are three ways to specify a priority value to
nice -n <value>
For example, setting a positive
12 value for a fictitious
$ nice -12 fold-protein data.txt
$ nice -n 12 fold-protein data.txt
$ nice --adjustment=12 fold-protein data.txt
If the priority value is omitted from the
nice command, it will default to a value of
nice is not used at all, the default priority value is
The range of possible values for priority is
19. The greater the negative number, the higher the priority.
Only the root user can launch a program with increased priority (negative priority value), but any user can launch a program with decrease priority (positive priority value).
renice command has the following syntax:
renice <priority> [[-p] <pids>] [-g <pgrps>] [-u <users>]
renice command accepts one or more PIDs (
pids), one or more group IDs (
pgrps), or one or more usernames (
users). If using
renice changes the priority of all programs that match the specific criteria — but only root may use
renice this way. In addition, only the root user may increase a process’s priority (by lowering the priority value).
If a numeric value is provided after the priority, without
renice assumes the value is a PID.
An example of using
# renice 7 16519 -u jeff josh
The above command would change the priority to
7 for PID
16519 for the users
kill command can be used to terminate a program by sending a signal to a specific process. This signal is usually sent by the kernel, the user, or the program itself to terminate the process.
kill command will only kill processes owned by the user that runs
kill, with the exception of the root user — which may kill any users’ processes.
Linux supports many numbered signals, each associated with a specific name. They can be listed with:
kill command has the following syntax:
kill -s <signal> <pid>
-s <signal> parameter sends the specific signal to the process.
The signal can be specified as either a number, or as its corresponding name. The most commonly used signals are:
SIGHUP— terminates interactive programs and causes many daemons to reread their configuration files.
SIGKILL— exits a process without performing routine shutdown tasks.
SIGTERM— exits a process but allows it to close open files, etc.
If no signal is specified,
SIGTERM is used as a default.
An alternative option to using a signal number or name, is to use the
-signal option. When using this option, omit the
SIG portion of the signal name:
kill -signal TERM 5219
The above command would send the
15 signal to the process with a PID of
Note: Although Linux includes a
kill program, many shells, including
csh, include a built-in
kill equivalent. To be sure that the external program is buing used, type the full path to
The kernel can pass signals to programs, even if you do not use the
kill command. For example, when logging out of a session, the programs you started from that session are sent the
1 signal, causing them to terminate.
To keep a program running after logging out, it can be ran with the
$ nohup <program> <options>
nohup command causes the program to ignore the
A variant of the
kill command is the
killall [options] [--] <name> [...]
killall command kills a process based on its name rather than its PID number.
The default signal for
killall is also
An important option for the
killall command is
-i. This option will cause
killall to prompt for confirmation before sending a signal to each process it matches:
$ killall -i vi
Kill vi(13219) ? (y/n)
It is highly recommended to always use the
-i option when running
killall as the root user.
Note: Some versions of Unix provide a
killall command that works very differently from Linux’s
killall command. This alternative version kills all of the processes started by the user who runs the command. To ensure you do not use this more destructive version of the command, check the
man page for the system’s
killall command first.
Another variant on
kill is the
pkill [-signal] [-fvx] [-n | -o] [-P <ppidlist>] [-g <pgrplist>] [-s <sidlist>] [-u <euidlist>] [-U <uidlist] [-G <gidlist>] [-J <projidlist>] [-t <termlist>] [-T <taskidlist>] [-c <ctidlist>] [-z <zoneidlist>] [pattern]
pkill command can kill one or more processes based on usernames, user IDs, group IDs, and other features, in addition to a regular expression for matching.
pkill command was introduced on the Solaris operating system.
Package Manager, Library, and Process Essentials
Most distributions are built around the RPM or Debian package systems, both of which enable installation, upgrade, and removal of software using a centralized package database to avoid conflicts and other problems that are common when no central package database exists.
Yum and APT can be used to assist with keeping a system synchronized with the latest versions of software.
Shared libraries are the necessary building blocks of large programs. Sometimes they need to be configured or upgraded manually.
Processes can be paused, manipulated as foreground or background processes, have their priorities set, or even killed.
Things to know without lookup:
- Identify critical features of RPM and Debian package formats:
- RPM and Debian packages store all of the files for a given package in a single file that also includes information about what other packages the software depends on.
- RPM and Debian systems maintain a database of installed packages and their associated files and dependencies.
- Describe the tools used for managing RPMs:
rpmprogram is the main tool for installing, upgrading, and uninstalling RPMs.
- The Yum utility, and particularly its
yumcommand, enables installation of a package and all of its dependencies via the Internet rather than from local package files.
- Describe the tools used for managing Debian packages:
dpkgprogram installs or uninstalls a single package or group of packages that are specified.
apt-getutility retrieves programs from installation media or from the Internet for installation, and can automatically upgrade an entire system.
dselectprogram serves as a text-mode menu-driven interface to
- Summarize tools for extracting files and converting between package formats:
rpm2cpioprogram can convert an RPM file into a
cpioarchive, enabling non-RPM systems to access files in an RPM.<\li>
alienutility can be used to convert packages between Debian, RPM, Stampede, and also tarballs. This enables the use of packages intended for one system onto another.
- Summarize the reasons for using shared libraries:
- Shared libraries keep disk space and memory requirements manageable by placing code that’s needed by many programs in separate files from the programs that use it, enabling one copy to be used multiple times.
- Shared libraries act as basic building blocks for programmers to use in their programs, so that they do not have to reinvent code for common tasks constantly.
- Describe methods available to change the library path:
- The library path can be changed system wide by editing the
/etc/ld.so.conffile followed by the
ldconfigcommand to ensure the cache has been updated.<\li>
- For temporary or per-user changes, directories may be added to the library path by placing them in the
- The library path can be changed system wide by editing the
- Explain the difference between foreground and background processes:
- Foreground processes have control over the current terminal or text-mode window (such as
- Background processes do not have exclusive control over a terminal or text-mode window, but are still running.
- Foreground processes have control over the current terminal or text-mode window (such as
- Describe how to limit the CPU time used by a process:
- A program may be launched with the
nicecommand to set its priority from the beginning.
- A running program can have its priority changed using the
renicecommand after it has been started.
- Processes can be terminated with the
- A program may be launched with the