Package Managers, Libraries, and Processes

Exam Objectives

• 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

Package Managers

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.

Package Concepts

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

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.

Dependencies

Packaging systems also maintain dependency information — a list of requirements packages have for each other.

Checksums

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. 

Using RPM

The most popular package manager for Linux is the RPM Package Manager (RPM).

RPM Distributions

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 Conventions

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-a.b.c-x.arch.rpm

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 i586 or 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

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 --nodeps switch 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.

The rpm Command Set

The main RPM utility program:
rpm [operation] [options]  [package-files|package-names]

Common rpm operations:

Common rpm options:

The 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 rebuild operations require package filenames.
• -q, -V, and -e require a package name.
• -p can be used to modify -q to use a package filename.

Using the -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

The -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 cpio archives. 

The 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

The cpio program can be used to extract .cpio archived files:
$ cpio -i --make-directories < samba-4.1.9-4.fc20.src.cpio

Note: The -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. /, /etc, /usr, etc.).

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.

Using Yum

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).

Common yum commands:

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 yumex and kyum. 

RPM and Yum Configuration Files

The main RPM configuration file is /usr/lib/rpm/rpmrc.

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 line:
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 athlon platform.

Most default rmprc files include a series of buildarchtranslate lines that cause rpmbuild (or 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 athlon, i686, i568, i486, and 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 /etc/yum.repos.d/ directory.

The yum.conf file holds basic options, such as the directory where Yum downloads RPMs and where Yum stores its logs.

The /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 rpm command.

Several popular Yum repositories exist:

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 dpkg, dselect, and apt-get commands.

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 x86, x86-64, IA-64, ARM, PowerPC, Alpha, 680x0, MIPS, and SPARC. 

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.

The dpkg Command Set

Debian packages are incompatible with RPM packages, but the principles of their operation are the same.

The dpkg command can be used to install a Debian package:
dpkg [options] [action] [package-files | package-name]

Common dpkg actions:

Common dpkg options:

Note: dpkg expects a package name or a package filename depending on the command. For instance, --install / -i and --info / -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:
# dpkg -r samba

To find information about an installed package, use the -p option:
# dpkg -p samba

Debian-based systems often use a pair of somewhat higher-level utilities (apt-get and dselect) to handle package installation and removal. However, dpkg is often more convenient when you’re manipulating just one or two packages.

Because 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. 

Using apt-cache

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 package cache). 

Common features of apt-cache:

Several 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.

Using apt-get

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 apt-get.

Although APT is most strongly associate with Debian systems, a port for RPM-based systems is also available (see: http://apt4rpm.sourceforge.net/).

The 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]

Common apt-get options:

Common apt-get commands:

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

Using dselect, aptitude, and Synaptic

The dselect program is a high-level text-mode package browser that uses the APT archives defined in /etc/apt/sources.list.

aptitude is another text-based Debian package manager; which combines the interactive features of dselect with the command-line options of apt-get.

In interactive mode, aptitude is similar to dselect, but aptitude adds menus accessed by pressing Ctrl+T.

Searching for packages with aptitude can be performed with aptitude search:
$ aptitude search samba

Features of aptitude on command line and interactive mode:

A tool that is similar to dselect and aptitude is the GUI X-based program, Synaptic.

Reconfiguring Packages

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 dpkg is /etc/dpkg/dpkg.cfg or ~/.dpkg.cfg. 

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:
no-act

For APT, the main configuration file that is likely to be modified is /etc/apt/sources.list.

Another APT configuration file is /etc/apt/apt.conf, which controls APT and dselect options.

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 ( {} ):
APT
{
    Get
    {
        Download-Only "true";
    };
};

Note: These lines are equivalent to setting the --download-only option permanently.

For more information on the apt.conf file, consult apt.conf‘s man page; and review the sample configuration file at /usr/share/doc/apt/examples/apt.conf.

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:

1. Continue searching for the appropriate package.
2. Create a package from a source tarball using standard RPM or Debian tools.
3. Convert between package formats with a utility like alien.

The alien program comes with Debian and a few other distributions, but it can be installed by typing apt-get install 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
• Tarballs

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).

Note: Although 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.

The 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:
alien [options] file[...]

Common alien options:

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 alien.

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:

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

The --nodeps parameter can be used to ignore failed dependencies using rpm:
# rpm -i package.rpm --nodeps

The --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 --nodeps or --force without first determining the reason for ignoring the dependency checks and errors preventing installation without these parameters.

For dpkg, the --ignore-depends=<package>, --force-depends, and --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 /usr/src/<distname>/RPMS/<arch>.

Note: Older versions of RPM use the rpm command instead of rpmbuild.

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 /etc/rc.d/rc.local or /etc/rc.d/boot.local). 

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.

Library Principles

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 /lib/libc.so.6 or /lib64/libc.so.6, but this file is sometimes a symbolic link to a file of another name, such as /lib/libc-2.15.so.

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 or .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 /etc/ld.so.conf file. 

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:
include /etc/ld.so.conf.d/*.conf

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 /etc/ld.so.conf file. 

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, /lib and /usr/lib. These directories are always on the library path, even if they aren’t listed in the ld.so.conf file.

Temporarily Changing the Path

The 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. 

Correcting Problems

$ gimp
gimp: error while loading shared libraries: libXinerama.so.1:
cannot~CA
  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, but 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

The ldd program displays a program’s shared library dependencies — the shared libraries that a program uses.

The 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 => symbol.

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.so and 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 /etc/ld.so.cache.

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 ldconfig:
# ldconfig

Common options to modify ldconfig:

Both RPM and Debian library packages typically run ldconfig automatically after installing or removing packages. 

Managing Processes

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.

The uname command can be run to reveal details about the kernel being run.

Common options for uname:

Examining Process Lists

One of the most important tools in process management is ps — which displays processes’ statuses:
ps [options]

Using Usefulps Options

The ps command supports three option types:

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 posix, old, linux, bsd, sun, digital, etc.

Usefulfeatures for ps:

Interpreting ps Output

The output from the ps command typically starts with a heading line, which displays the meaning of each column:

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 init.

top: A Dynamic ps Variant

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.

By default, top sorts entries by CPU use, and it updates the display every few seconds.

There are also GUI variants of top, such as kpm and gnome-system-monitor. 

Common top options:

While top is running, interactive commands can be entered:

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

The 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.

The jobs command can also be used to ensure all programs have terminated prior to logging out. 

pgrep: Finding Processes

The pgrep command was introduced under the Solaris operating system. It performs a simple search within the process list (similar to ps piped to grep):
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.

The 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 ctrl+z then 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

The 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.

The nice command has the following syntax:
nice [argument] [command [command-arguments]]

There are three ways to specify a priority value to nice:

1. nice -<value>
2. nice -n <value>
3. nice --adjustment=<value>

For example, setting a positive 12 value for a fictitious fold-protein command:

1. $ nice -12 fold-protein data.txt
2. $ nice -n 12 fold-protein data.txt
3. $ nice --adjustment=12 fold-protein data.txt

If the priority value is omitted from the nice command, it will default to a value of 10. If nice is not used at all, the default priority value is 0.

The range of possible values for priority is -20 to 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).

The renice command has the following syntax:
renice <priority> [[-p] <pids>] [-g <pgrps>] [-u <users>]

The renice command accepts one or more PIDs (pids), one or more group IDs (pgrps), or one or more usernames (users). If using pgrps or users, 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 -p, -g, or -u, renice assumes the value is a PID.

An example of using renice:
# renice 7 16519 -u jeff josh

The above command would change the priority to 7 for PID 16519 for the users jeff and josh.

Killing Processes

The 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.

Note: The 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 -l

The kill command has the following syntax:
kill -s <signal> <pid>

The -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: 

• 1 / SIGHUP — terminates interactive programs and causes many daemons to reread their configuration files.
• 9 / SIGKILL — exits a process without performing routine shutdown tasks.
• 15 / SIGTERM — exits a process but allows it to close open files, etc.

If no signal is specified, 15 / 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 SIGTERM / 15 signal to the process with a PID of 5219.

Note: Although Linux includes a kill program, many shells, including bash and csh, include a built-in kill equivalent. To be sure that the external program is buing used, type the full path to /bin/kill.

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 SIGHUP / 1 signal, causing them to terminate.

To keep a program running after logging out, it can be ran with the nohup command:
$ nohup <program> <options>

The nohup command causes the program to ignore the SIGHUP / 1 signal.

A variant of the kill command is the killall command:
killall [options] [--] <name> [...]

The killall command kills a process based on its name rather than its PID number.

The default signal for killall is also 15 / SIGTERM.

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 command:
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]

The 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.

The 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:
  • The rpm program is the main tool for installing, upgrading, and uninstalling RPMs. 
  • The Yum utility, and particularly its yum command, 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:
  • The dpkg program installs or uninstalls a single package or group of packages that are specified.
  • The apt-get utility retrieves programs from installation media or from the Internet for installation, and can automatically upgrade an entire system.
  • The dselect program serves as a text-mode menu-driven interface to apt-get. 

• Summarize tools for extracting files and converting between package formats:
  • The rpm2cpio program can convert an RPM file into a cpio archive, enabling non-RPM systems to access files in an RPM.<\li>
  • The alien utility 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.conf file followed by the ldconfig command 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 LD_LIBRARY_PATH environment variable.

• Explain the difference between foreground and background processes:
  • Foreground processes have control over the current terminal or text-mode window (such as xterm).
  • Background processes do not have exclusive control over a terminal or text-mode window, but are still running.

• Describe how to limit the CPU time used by a process:
  • A program may be launched with the nice command to set its priority from the beginning.
  • A running program can have its priority changed using the renice command after it has been started.
  • Processes can be terminated with the kill or killall commands.