diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml index b2e81b5cd7..661d608bd7 100644 --- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml @@ -1,7 +1,7 @@ @@ -192,6 +192,295 @@ contains. + + Processes + + 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 process. + 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. + + Each process is uniquely identified by a number called a + process ID, or PID, 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 + init. init is always the first + process, so its PID is always 1. init is started + automatically by the kernel when FreeBSD starts. + + 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. + + By default, &man.ps.1; only shows you the commands that are running + and are owned by you. For example; + + &prompt.user; ps + 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 + + As you can see in this example, the output from &man.ps.1; is + organized in to a number of columns. PID 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. + TT shows the tty the program is running on, and can + safely be ignore for the moment. STAT shows the + program's state, and again, can be safely ignored. + TIME 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, COMMAND is the command line that was used to + run the program. + + &man.ps.1; supports a number of different options to change the + information that is displayed. One of the most useful sets is + auxww. displays information + about all the running processes, not just your own. + displays the username of the process' owner, as well as memory usage. + displays information about daemon processes, and + causes &man.ps.1; to display the full command line, + rather than truncating it once it gets too long to fit on the + screen. + + The output from &man.top.1; is similar. A sample session looks like + this; + + &prompt.user; top +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 +... + + 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. + + 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. + + &man.top.1; automatically updates this display every two seconds; + this can be changed with the option. + + + + Daemons, signals, and killing processes + + 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 + terminal. 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. + + We call these programs daemons. 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. + + There is a convention to name programs that normally run as daemons + with a trailing d. BIND is the + Berkeley Internet Name Daemon (and the program you can is called + named), the Apache web + server program is called httpd, the line printer + spooling daemon is lpd and so on. This is a + convention, not a hard and fast rule; for example, the main mail daemon + for the Sendmail application is called + sendmail, and not maild, as you + might imagine. + + Sometimes you will need to communicate with a daemon process. These + commmunications are called signals, 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 + root user, who can send signals to everyone's + processes. + + 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 Segmentation + Violation signal (SIGSEGV). 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 + (SIGALRM), and so on. + + Two signals can be used to stop a process, + SIGTERM and SIGKILL. + SIGTERM is the polite way to kill a process; the + process can catch 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 SIGTERM if it is in + the middle of some task that can not be interrupted. + + SIGKILL can not be ignored by a process. This is + the I don't care what you are doing, stop right now + signal. If you send SIGKILL to a process then + FreeBSD will stop that process there and then + 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 + uninterruptible. Eventually the process will time + out, typically after two minutes. As soon as this time out occurs + the process will be killed. + . + + The other signals you might want to use are + SIGHUP, SIGUSR1, and + SIGUSR2. These are general purpose signals, and + different applications will do different things when they are + sent. + + 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 httpd, but + this would result in a brief outage period on your webserver, which may + be undesirable. Most daemons are written to respond to the + SIGHUP signal by re-reading their configuration + file. So instead of killing and restarting httpd you + would send it the SIGHUP 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. + + Signals are sent using the &man.kill.1; command, as this example + shows. + + + Sending a signal to a process + + This example shows how to send a signal to &man.inetd.8;. The + &man.inetd.8; configuration file is + /etc/inetd.conf, and &man.inetd.8; will re-read + this configuration file when it is sent + SIGHUP. + + + 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 root, so the options + must be given to &man.ps.1;. + + &prompt.user; ps -ax | grep inetd + 198 ?? IWs 0:00.00 inetd -wW + + So the &man.inetd.8; PID is 198. In some cases the + grep inetd command might also occur in this + output. This is because of the way &man.ps.1; has to find the list + of running processes. + + + + Use &man.kill.1; to send the signal. Because &man.inetd.8; is + being run by root you must use &man.su.1; to + become root first. + + &prompt.user; su +Password: +&prompt.root; /bin/kill -s HUP 198 + + 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 kill: + PID: Operation not + permitted. 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 kill: + PID: No such process. + + + Why use <command>/bin/kill</command>? + + Many shells provide the kill command as a + built in command; that is, the shell will send the signal + directly, rather than running /bin/kill. + 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 + /bin/kill ... + command directly. + + + + + Sending other signals is very similar, just substitute + TERM or KILL in the command line + as necessary. + + + Killing random process on the system can be a bad idea. In + particular, &man.init.8;, process ID 1, is very special. Running + /bin/kill -s KILL 1 is a quick way to shutdown your + system. Always double check the arguments you + run &man.kill.1; with before you press + RETURN. + + + Shells shells