Add text talking about processes, daemons, and how to send them signals.
This commit is contained in:
Nik Clayton
parent
2fdac55c46
commit
7231511d66
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=10101
1 changed files with 290 additions and 1 deletions
|
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/basics/chapter.sgml,v 1.32 2001/07/25 20:41:24 chern Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/basics/chapter.sgml,v 1.33 2001/07/30 17:18:49 murray Exp $
|
||||
-->
|
||||
|
||||
<chapter id="basics">
|
||||
|
|
@ -192,6 +192,295 @@
|
|||
contains.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="basics-processes">
|
||||
<title>Processes</title>
|
||||
|
||||
<para>FreeBSD is a multi-tasking operating system. This means that it
|
||||
seems as though more than one program is running at once. Each program
|
||||
running at any one time is called a <firstterm>process</firstterm>.
|
||||
Every command you run will start at least one new process, and there are
|
||||
a number of system processes that run all the time, keeping the system
|
||||
functional.</para>
|
||||
|
||||
<para>Each process is uniquely identified by a number called a
|
||||
<firstterm>process ID</firstterm>, or <firstterm>PID</firstterm>, and,
|
||||
like files, each process also has one owner and group. The owner and
|
||||
group information is used to determine what files and devices the
|
||||
process can open, using the file permissions discussed earlier. Most
|
||||
processes also have a parent process. The parent process is the process
|
||||
that started them. For example, if you are typing commands to the shell
|
||||
then the shell is a process, and any commands you run are also
|
||||
processes. Each process you run in this way will have your shell as its
|
||||
parent process. The exception to this is a special process called
|
||||
<command>init</command>. <command>init</command> is always the first
|
||||
process, so its PID is always 1. <command>init</command> is started
|
||||
automatically by the kernel when FreeBSD starts.</para>
|
||||
|
||||
<para>Two commands are particularly useful to see the processes on the
|
||||
system, &man.ps.1; and &man.top.1;. The &man.ps.1; command is used to
|
||||
show a static list of the currently running processes, and can show
|
||||
their PID, how much memory they are using, the command line they were
|
||||
started with, and so on. The &man.top.1; command displays all the
|
||||
running processes, and updates the display every few seconds, so that
|
||||
you can interactively see what your computer is doing.</para>
|
||||
|
||||
<para>By default, &man.ps.1; only shows you the commands that are running
|
||||
and are owned by you. For example;</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ps</userinput>
|
||||
PID TT STAT TIME COMMAND
|
||||
298 p0 Ss 0:01.10 tcsh
|
||||
7078 p0 S 2:40.88 xemacs mdoc.xsl (xemacs-21.1.14)
|
||||
37393 p0 I 0:03.11 xemacs freebsd.dsl (xemacs-21.1.14)
|
||||
48630 p0 S 2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
|
||||
48730 p0 IW 0:00.00 (dns helper) (navigator-linux-)
|
||||
72210 p0 R+ 0:00.00 ps
|
||||
390 p1 Is 0:01.14 tcsh
|
||||
7059 p2 Is+ 1:36.18 /usr/local/bin/mutt -y
|
||||
6688 p3 IWs 0:00.00 tcsh
|
||||
10735 p4 IWs 0:00.00 tcsh
|
||||
20256 p5 IWs 0:00.00 tcsh
|
||||
262 v0 IWs 0:00.00 -tcsh (tcsh)
|
||||
270 v0 IW+ 0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16
|
||||
280 v0 IW+ 0:00.00 xinit /home/nik/.xinitrc -- -bpp 16
|
||||
284 v0 IW 0:00.00 /bin/sh /home/nik/.xinitrc
|
||||
285 v0 S 0:38.45 /usr/X11R6/bin/sawfish</screen>
|
||||
|
||||
<para>As you can see in this example, the output from &man.ps.1; is
|
||||
organized in to a number of columns. <literal>PID</literal> is the
|
||||
process ID discussed earlier. PIDs are assigned starting from 1, go up
|
||||
to 65536, and wrap around back to the beginning when you run out.
|
||||
<literal>TT</literal> shows the tty the program is running on, and can
|
||||
safely be ignore for the moment. <literal>STAT</literal> shows the
|
||||
program's state, and again, can be safely ignored.
|
||||
<literal>TIME</literal> is the amount of time the program has been
|
||||
running on the CPU—this is not necessarily the elapsed time since
|
||||
you started the program, as some programs spend a lot of time waiting
|
||||
for things to happen before they need to spend time on the CPU.
|
||||
Finally, <literal>COMMAND</literal> is the command line that was used to
|
||||
run the program.</para>
|
||||
|
||||
<para>&man.ps.1; supports a number of different options to change the
|
||||
information that is displayed. One of the most useful sets is
|
||||
<literal>auxww</literal>. <option>a</option> displays information
|
||||
about all the running processes, not just your own. <option>u</option>
|
||||
displays the username of the process' owner, as well as memory usage.
|
||||
<option>x</option> displays information about daemon processes, and
|
||||
<option>ww</option> causes &man.ps.1; to display the full command line,
|
||||
rather than truncating it once it gets too long to fit on the
|
||||
screen.</para>
|
||||
|
||||
<para>The output from &man.top.1; is similar. A sample session looks like
|
||||
this;</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>top</userinput>
|
||||
last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10
|
||||
47 processes: 1 running, 46 sleeping
|
||||
CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle
|
||||
Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free
|
||||
Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
||||
|
||||
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
|
||||
72257 nik 28 0 1960K 1044K RUN 0:00 14.86% 1.42% top
|
||||
7078 nik 2 0 15280K 10960K select 2:54 0.88% 0.88% xemacs-21.1.14
|
||||
281 nik 2 0 18636K 7112K select 5:36 0.73% 0.73% XF86_SVGA
|
||||
296 nik 2 0 3240K 1644K select 0:12 0.05% 0.05% xterm
|
||||
48630 nik 2 0 29816K 9148K select 3:18 0.00% 0.00% navigator-linu
|
||||
175 root 2 0 924K 252K select 1:41 0.00% 0.00% syslogd
|
||||
7059 nik 2 0 7260K 4644K poll 1:38 0.00% 0.00% mutt
|
||||
...</screen>
|
||||
|
||||
<para>The output is split in to two sections. The header (the first five
|
||||
lines) shows the PID of the last process to run, the system load averages
|
||||
(which are a measure of how busy the system is), the system uptime (time
|
||||
since the last reboot) and the current time. The other figures in the
|
||||
header relate to how many processes are running (47 in this case), how
|
||||
much memory and swap space has been taken up, and how much time the
|
||||
system is spending in different CPU states.</para>
|
||||
|
||||
<para>Below that are a series of columns containing similar information
|
||||
to the output from &man.ps.1;. As before you can see the PID, the
|
||||
username, the amount of CPU time taken, and the command that was run.
|
||||
&man.top.1; also defaults to showing you the amount of memory space
|
||||
taken by the process. This is split in to two columns, one for total
|
||||
size, and one for resident size—total size is how much memory the
|
||||
application has needed, and the resident size is how much it is actually
|
||||
using at the moment. In this example you can see that Netscape has
|
||||
needed almost 30MB of RAM, and is currently only needing 9MB.</para>
|
||||
|
||||
<para>&man.top.1; automatically updates this display every two seconds;
|
||||
this can be changed with the <option>s</option> option.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title>Daemons, signals, and killing processes</title>
|
||||
|
||||
<para>When you run an editor it is easy to control the editor, tell it to
|
||||
load files, and so on. You can do this because the editor provides
|
||||
facilities to do so, and because the editor is attached to a
|
||||
<firstterm>terminal</firstterm>. Some programs are not designed to be
|
||||
run with continuous user input, and so they disconnect from the terminal
|
||||
at the first opportunity. For example, a web server spends all day
|
||||
responding to web requests, it normally does not need any input from
|
||||
you. Programs that transport e-mail from site to site are another
|
||||
example of this class of application.</para>
|
||||
|
||||
<para>We call these programs <firstterm>daemons</firstterm>. Daemons were
|
||||
characters in Greek mythology; neither good or evil, they were little
|
||||
attendant spirits that, by and large, did useful things for mankind.
|
||||
Much like the web servers and mail servers of today do useful things.
|
||||
This is why the BSD mascot has, for a long time, been the cheerful
|
||||
looking daemon with sneakers and a pitchfork.</para>
|
||||
|
||||
<para>There is a convention to name programs that normally run as daemons
|
||||
with a trailing <quote>d</quote>. <application>BIND</application> is the
|
||||
Berkeley Internet Name Daemon (and the program you can is called
|
||||
<command>named</command>), the <application>Apache</application> web
|
||||
server program is called <command>httpd</command>, the line printer
|
||||
spooling daemon is <command>lpd</command> and so on. This is a
|
||||
convention, not a hard and fast rule; for example, the main mail daemon
|
||||
for the <application>Sendmail</application> application is called
|
||||
<command>sendmail</command>, and not <command>maild</command>, as you
|
||||
might imagine.</para>
|
||||
|
||||
<para>Sometimes you will need to communicate with a daemon process. These
|
||||
commmunications are called <firstterm>signals</firstterm>, and you can
|
||||
communicate with daemons (or with any running process) by sending it a
|
||||
signal. There are a number if different signals that you can
|
||||
send—some of them have a specific meaning, others are interpreted
|
||||
by the application, and the application's documentation will tell you
|
||||
how that application interprets signals. You can only send a signal to
|
||||
a process that you own. If you try and send a signal to someone else's
|
||||
process it will be ignored. The exception to this is the
|
||||
<username>root</username> user, who can send signals to everyone's
|
||||
processes.</para>
|
||||
|
||||
<para>FreeBSD will also send applications signals in some cases. If an
|
||||
application is badly written, and tries to access memory that it is not
|
||||
supposed to, FreeBSD sends the process the <firstterm>Segmentation
|
||||
Violation</firstterm> signal (<literal>SIGSEGV</literal>). If an
|
||||
application has used the &man.alarm.3; system call to be alerted after a
|
||||
period of time has elapsed then it will be sent the Alarm signal
|
||||
(<literal>SIGALRM</literal>), and so on.</para>
|
||||
|
||||
<para>Two signals can be used to stop a process,
|
||||
<literal>SIGTERM</literal> and <literal>SIGKILL</literal>.
|
||||
<literal>SIGTERM</literal> is the polite way to kill a process; the
|
||||
process can <emphasis>catch</emphasis> the signal, realise that you want
|
||||
it to shut down, close any log files it may have open, and generally
|
||||
finish whatever it is doing at the time before shutting down. In some
|
||||
cases a process may even ignore <literal>SIGTERM</literal> if it is in
|
||||
the middle of some task that can not be interrupted.</para>
|
||||
|
||||
<para><literal>SIGKILL</literal> can not be ignored by a process. This is
|
||||
the <quote>I don't care what you are doing, stop right now</quote>
|
||||
signal. If you send <literal>SIGKILL</literal> to a process then
|
||||
FreeBSD will stop that process there and then<footnote>
|
||||
<para>Not quite true—there are a few things that can not be
|
||||
interrupted. For example, if the process is trying to read from a
|
||||
file that is on another computer on the network, and the other
|
||||
computer has gone away for some reason (been turned off, or the
|
||||
network has a fault), then the process is said to be
|
||||
<quote>uninterruptible</quote>. Eventually the process will time
|
||||
out, typically after two minutes. As soon as this time out occurs
|
||||
the process will be killed.</para>
|
||||
</footnote>.</para>
|
||||
|
||||
<para>The other signals you might want to use are
|
||||
<literal>SIGHUP</literal>, <literal>SIGUSR1</literal>, and
|
||||
<literal>SIGUSR2</literal>. These are general purpose signals, and
|
||||
different applications will do different things when they are
|
||||
sent.</para>
|
||||
|
||||
<para>Suppose that you have changed your web server's configuration
|
||||
file—you would like to tell the web server to re-read its
|
||||
configuration. You could stop and restart <command>httpd</command>, but
|
||||
this would result in a brief outage period on your webserver, which may
|
||||
be undesirable. Most daemons are written to respond to the
|
||||
<literal>SIGHUP</literal> signal by re-reading their configuration
|
||||
file. So instead of killing and restarting <command>httpd</command> you
|
||||
would send it the <literal>SIGHUP</literal> signal. Because there is no
|
||||
standard way to respond to these signals, different daemons will have
|
||||
different behaviour, so be sure and read the documentation for the
|
||||
daemon in question.</para>
|
||||
|
||||
<para>Signals are sent using the &man.kill.1; command, as this example
|
||||
shows.</para>
|
||||
|
||||
<procedure>
|
||||
<title>Sending a signal to a process</title>
|
||||
|
||||
<para>This example shows how to send a signal to &man.inetd.8;. The
|
||||
&man.inetd.8; configuration file is
|
||||
<filename>/etc/inetd.conf</filename>, and &man.inetd.8; will re-read
|
||||
this configuration file when it is sent
|
||||
<literal>SIGHUP</literal>.</para>
|
||||
|
||||
<step>
|
||||
<para>Find the process ID of the process you want to send the signal
|
||||
to. Do this using &man.ps.1; and &man.grep.1;. The &man.grep.1;
|
||||
command is used to search through output, looking for the string you
|
||||
specify. This command is run as a normal user, and &man.inetd.8; is
|
||||
run as <username>root</username>, so the <option>ax</option> options
|
||||
must be given to &man.ps.1;.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ps -ax | grep inetd</userinput>
|
||||
198 ?? IWs 0:00.00 inetd -wW</screen>
|
||||
|
||||
<para>So the &man.inetd.8; PID is 198. In some cases the
|
||||
<literal>grep inetd</literal> command might also occur in this
|
||||
output. This is because of the way &man.ps.1; has to find the list
|
||||
of running processes.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>Use &man.kill.1; to send the signal. Because &man.inetd.8; is
|
||||
being run by <username>root</username> you must use &man.su.1; to
|
||||
become <username>root</username> first.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>su</userinput>
|
||||
<prompt>Password:</prompt>
|
||||
&prompt.root; <userinput>/bin/kill -s HUP 198</userinput></screen>
|
||||
|
||||
<para>As is common with Unix commands, &man.kill.1; will not print any
|
||||
output if it is successfully. If you try and send a signal to a
|
||||
process that you do not own then you will see <errorname>kill:
|
||||
<replaceable>PID</replaceable>: Operation not
|
||||
permitted</errorname>. If you mistype the PID you will either
|
||||
send the signal to the wrong process, which could be bad, or, if
|
||||
you are lucky, you will have sent the signal to a PID that is not
|
||||
currently in use, and you will see <errorname>kill:
|
||||
<replaceable>PID</replaceable>: No such process</errorname>.</para>
|
||||
|
||||
<note>
|
||||
<title>Why use <command>/bin/kill</command>?</title>
|
||||
|
||||
<para>Many shells provide the <command>kill</command> command as a
|
||||
built in command; that is, the shell will send the signal
|
||||
directly, rather than running <filename>/bin/kill</filename>.
|
||||
This can be very useful, but different shells have a different
|
||||
syntax for specifying the name of the signal to send. Rather than
|
||||
try to learn all of them, it can be simpler just to use the
|
||||
<command>/bin/kill <replaceable>...</replaceable></command>
|
||||
command directly.</para>
|
||||
</note>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
<para>Sending other signals is very similar, just substitute
|
||||
<literal>TERM</literal> or <literal>KILL</literal> in the command line
|
||||
as necessary.</para>
|
||||
|
||||
<important>
|
||||
<para>Killing random process on the system can be a bad idea. In
|
||||
particular, &man.init.8;, process ID 1, is very special. Running
|
||||
<command>/bin/kill -s KILL 1</command> is a quick way to shutdown your
|
||||
system. <emphasis>Always</emphasis> double check the arguments you
|
||||
run &man.kill.1; with <emphasis>before</emphasis> you press
|
||||
<keycap>RETURN</keycap>.</para>
|
||||
</important>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="shells">
|
||||
<title>Shells</title>
|
||||
<indexterm><primary>shells</primary></indexterm>
|
||||
|
|
|
|||
Loading…
Reference in a new issue