LPI Linux Certification in a Nutshell (20 page)

free

free [
options
]

Display amount of free and used memory in the
system.

Display current memory usage in megabytes and display a total
line:

$
free –tm
total       used       free     shared    buffers     cached
Mem:          2023       1874        149          0         77       1089
-/+ buffers/cache:        707       1316
Swap:         4031        351       3680
Total:        6055       2225       3830

This tells me that I have 2,023 megabytes of system memory (2
gigabytes) and 4,031 megabytes (about 4 gigabytes) of swap space.
I’m currently using 1,874 megabytes of memory, leaving 149
free.

uptime

uptime

uptime
gives a one-line display
of the following information: the current time, how long the system
has been running, how many users are currently logged on, and the
system load averages for the past 1, 5, and 15 minutes.

$
uptime
13:17:57 up 214 days,  2:52,  4 users,  load average: 0.09, 0.03, 0.01

Load average on a Linux system is defined as the number of
blocking processes in the run queue averaged over a certain time
period. A blocking process is a process that is waiting on a
resource to continue, usually the CPU, disk I/O, or network. Many
processes waiting in the run queue will drive up the load average of
your system. It’s not uncommon to see a load average over 1; that
just means for the designated time interval (1, 5 or 15 minutes)
there was an average of at least one process waiting on resources in
the run queue. This is usually indicative of a busy system and might
not necessarily mean anything is amiss. However, high load averages
will negatively affect system performance, so it’s always a good
idea to be aware of what is causing them. Here is the uptime output
of a relatively busy web server:

$
uptime
1:20pm  up 3 days 15:49,  1 user,  load average: 1.47, 1.10, 0.83

kill

kill [-s
sigspec
|
-sigspec
] [
pids
]
kill -l [
signum
]

In the first form,
kill
is used
with an optional
sigspec
. This is a
signal value, specified as either an integer or the signal name
(such as
SIGHUP
, or simply
HUP
). The
sigspec
is
case-insensitive but is usually specified with uppercase letters.
The
bash
built-in
kill
is
case-insensitive, both when using the
-s
sigspec
and the
-sigspec
forms, but the standalone
kill
is only case-insensitive in the
-s
sigspec
form. For
this reason, it is best to use uppercase signal names. You may use
-s
sigspec
or simply
-
sigspec
to
make up the signal value or name. If a
sigspec
is not given, then
SIGTERM
(signal 15, “exit gracefully”) is
assumed. The
sigspec
is followed by one
or more PIDS to which the signal is to be sent. In the second form
with the
-l
option,
kill
lists the valid signal names. If
signum
(an integer) is present, only the signal name for that number will
be displayed.

This command displays the signal name
SIGTERM
, the name of signal 15, and the default
when
kill
is used to signal processes:

$
kill -l 15
TERM

All of the following commands will send
SIGTERM
to the processes with PIDs 1000 and
1001:

$
kill 1000 1001
$
kill -15 1000 1001
$
kill -SIGTERM 1000 1001
$
kill -sigterm 1000 1001
$
kill -TERM 1000 1001
$
kill -s 15 1000 1001
$
kill -s SIGTERM 1000 1001

If those two processes are playing nicely on your system,
they’ll comply with the
SIGTERM
signal and
terminate when they’re ready (after they clean up whatever they’re
doing). Not all processes will comply, however. A process may be
hung in such a way that it cannot respond, or it may have
signal handling
code written to
trap the signal you’re trying to send. To force a process to die,
use the strongest
kill
:

$
kill -9 1000 1001s
$
kill -KILL 1000 1001

These equivalent commands send the
KILL
signal to the process, which the process cannot ignore. The process
will terminate immediately without closing files or performing any
other cleanup. Because this may leave the program’s data in an
inconsistent state, using the
KILL
signal
should be a last resort. When a process is blocked waiting for I/O,
such as trying to write to an unavailable NFS server or waiting for
a tape device to complete rewinding, the
KILL
signal may not work. See
below.

The
httpd
daemon will respond to the
HUP
signal by rereading its configuration
files. If you’ve made changes and want
httpd
to
reconfigure itself, send it the
HUP
signal:

$
kill -HUP 'cat /var/run/httpd.pid'

Many other daemons respond to
SIGHUP
this
way.

The back quotes are replaced by the shell with the contents of
the file
httpd.pid
, which
httpd
creates when it starts.

Other programs allow you to send signals to processes without
indicating their PID.
killall
will send a signal to all
processes that match a given name, and
killproc
will send a signal to
all process that match a full pathname.

bg

bg [
jobspec
]

Place
jobspec
in the
background, as if it had been started with
&
. If
jobspec
is not present, then the shell’s
notion of the
current job
is used, as indicated
by the plus sign (
+
) in output
from the
jobs
command. Using this command on a
job that is stopped will allow it to run in the
background
.

fg

fg [
jobspec
]

This command places the specified job in the
foreground, making it the current job. If
jobspec
is not present, the shell’s
notion of the current job is used.

jobs

jobs [
options
] [
jobspecs
]

List the active jobs. The optional
jobspecs
argument restricts output to
information about those jobs.

nohup

nohup [
options
] [
command
] [
args...
]

Run a command immune to hangups, with output to a non-TTY
terminal.

Run the command
/opt/bin/myscript.sh
in the background,
with standard output and standard error redirected to
nohup.out
:

$
nohup /opt/bin/myscript.sh &
[1] 12611

One of the parameters used by the kernel to assign process
priority is supplied by the user and is called a
nice number
. The
nice
command
^[
1
]
is used to assign a priority number to the process. It is
so named because it normally causes programs to execute with lower
priority levels than their default. Thus, the process is being “nice” to
other processes on the system by yielding CPU time. With this scheme,
more “niceness” implies a lower priority, and less niceness implies a
higher priority.

By default, user processes are created with a
nice
number
of zero. Positive numbers lower the priority relative
to other processes, and negative numbers raise it. For example, if you
have a long-running utility and don’t want to impact interactive
performance, a positive nice number will lower the job’s priority and
improve interactive performance.

Nice numbers range from –20 to +19. Any user can start a process
with a positive nice number, but only the superuser (
root
) can lower a process’s nice number and
thus raise its priority. Remember, the lower the nice number, the higher
the priority to the CPU.

nice

nice [-n
adjustment
] [
command
]
nice [-
adjustment
] [
command
]

The
nice
command alters another process’s
nice number at start time. For normal users,
adjustment
is an integer from 1 to 19. If
you’re the superuser, the
adjustment
range is from –20 to 19. If an
adjustment
number is not specified, the process’s nice number defaults to 10.
The
command
consists
of any command that you might enter on the command line, including
all options, arguments, redirections, and the background character
&
.

If both
adjustment
and
command
are omitted,
nice
displays the current scheduling priority,
which is inherited.

The following command starts a program in the background with
reduced priority, using the default nice number of 10:

$
nice somecmd -opt1 -opt2 arg1 arg2 &

As superuser, you can start programs with elevated priority.
These equivalent commands start the
vi
editor with a higher priority,
which may be necessary for administrative purposes if the system is
exceptionally slow:

#
nice --10 vi /etc/hosts.deny
#
nice -n -10 vi /etc/hosts.deny

Note the
double dash (
--10
)
in the first form. The first dash indicates that an option follows,
whereas the second dash indicates a negative number.

Be careful when using
nice
on interactive
programs such as editors, word processors, or browsers. Assigning a
program a positive nice number will most likely result in sluggish
performance. Remember, the higher the positive number, the lower the
resulting priority level.

For that reason, you should try not to assign positive nice
numbers to foreground jobs on your terminal. If the system gets
busy, your terminal could hang awaiting CPU time, which has been
sacrificed by
nice
.

The
nice
command works to change the nice
number for new processes only at the time that they’re started. To
modify a running program, use the
renice
command.