[Chapter 1] 1.14 The Kernel and Daemons
Author: Jerry Peek, Tim O'Reilly & Mike Loukides
Date: 1998-08-04T21:31:12Z

#

| Chapter 1 Introduction |

## 1.14 The Kernel and Daemons

If you have arrived at UNIX via DOS or some other personal computer operating system, you will notice some big differences. UNIX is, was, and always will be a multiuser operating system. It is a multiuser operating system even when you're the only person using it. It is a multiuser operating system even when it is running on a PC with a single keyboard. And this fact has important ramifications for everything that you do.

Why does this make a difference? Well, for one thing, you're never the only one using the system, even when you think you are. Don't bother to look under your desk to see if there's an extra terminal hidden down there. There isn't. But UNIX is always doing things "behind your back," running programs of its own, whether or not you are aware of it. The most important of these programs, the kernel, is the heart of the UNIX operating system itself. The kernel assigns memory to each of the programs that are running, partitions time fairly so that each program can get its job done, handles all I/O (input/output) operations, and so on. Another important group of programs, called daemons, are the system's "helpers." They run from time to time performing small but important tasks like handling mail, running network communications, feeding data to your printer, keeping track of the time, and so on.

You can use UNIX for a long time without being aware of the kernel or any of the daemons. If you suddenly see a "panic" message on your terminal and your system stops in its tracks (crashes), you've just had a run-in with the kernel. Something has gotten the kernel confused, and it has decided to give up rather than risk doing something foolish. And there's not much you can do to remedy a panic; the problem usually isn't your fault. But you should know where they're coming from. Similarly, daemons may occasionally bombard you with messages. And when you give the ps command (see the following list), there may be some names that you don't recognize. These are probably the names of daemons that happen to be doing something benevolent at the moment. Right now, we won't worry about them. But you should know that they are there.

Not only are you sharing the computer with the kernel and some mysterious daemons, you're also sharing it with yourself. I am currently using a Sun 3 workstation. If I give the command ps (38.5), which lists all the programs I am running, I get the following report:

>     PID TT STAT  TIME COMMAND
>      1449 co IW    0:01 sunview
>      1453 co S     0:27 clock -Wp 497 32 -WP 704 0 -Wi -Wh 1
>      1451 p0 IW    0:04 shelltool
>      1452 p0 IW    0:00 -bin/csh (csh)
>      1454 p1 R     2:52 shelltool
>      1455 p1 S     0:01 -bin/csh (csh)
>      2217 p1 R     0:00 ps
>      1504 p2 S     1:54 shelltool
>      1505 p2 IW    0:01 -bin/csh (csh)
>      1884 p2 S     1:32 emacs princip3.otl

I may think that I'm only running the editor Emacs, but the computer is actually doing a lot more for me. I'm also running sunview, which keeps track of Sun's display, and I'm running a program that displays a little clock in one corner of my screen. I'm running several "command tools," which are windows (or areas of the screen) that act like separate terminals. Each command tool has a shell (csh), which is a command interpreter that deciphers everything I type at the keyboard. And I'm running the ps command. And, waiting patiently somewhere, my lonely Emacs editor is waiting for me to type some more.

If you are running the X window system (1.31) or if you're using a computer with the System V layers facility, you will see something different. But we guarantee that you're running at least two programs, and quite likely many more. If you want to see everything that's running, including the daemons, type the command `ps -aux` (for BSD) or `ps -el` (for many other flavors of UNIX). You'll be impressed.

Because there is so much going on at once, you have to get used to a different way of thinking about UNIX. The UNIX kernel is a traffic cop that mediates different demands for time, for memory, for disks, and so on. Not only does the kernel need to run your programs, but it also needs to run the daemons, any programs that other users might want to start, or any programs that you may have scheduled to run automatically (40.1). When it runs a program, the kernel allocates a small slice of time - up to a second - and lets the program run until that slice is used up, or the program decides to take a rest of its own accord (this is called "sleeping"). At this point, whether or not the program is finished, the kernel finds some other program to run. The UNIX kernel never takes a vacation. It is always watching over the system.

Once you understand that the kernel is a manager that schedules many different kinds of activity, you understand a lot about how UNIX works. For example, if you have used any computer system previously, you know that it's a bad idea to turn the computer off while it is writing something on the disk. You will probably destroy the disk, and could conceivably damage the disk drive. The same is true for UNIX-but with an important complication. Any of the programs that are running can start doing something to the disk at any time. One of the daemons makes a point of accessing the disk drive every 30 seconds or so, just to stay in touch. Therefore, you can't just turn a UNIX computer off. You might do all sorts of damage to the system's files - and not just your own, but conceivably files belonging to many other users. To turn a UNIX system off, you must first run a program called shutdown, which kicks everyone off the system and makes sure that a daemon won't try to play with a disk drive when you aren't looking. Then you run a program named sync, which makes sure that the disks have finished doing everything. Only then is it safe to pull the switch. When you start up a UNIX system, it automatically runs a program called fsck, which stands for "filesystem check"-its job is to find out if you shut down the system correctly and fix any damage that might have happened if you didn't.

In this book, we will avoid administrative issues like shutdown, sync, and fsck. But they provide good examples of how UNIX differs from simpler operating systems. If you understand why these programs are needed, you are on your way to becoming a power user.

- ML

1.13 Why Fundamentals Are Important |  | 1.15 Filenames