Last update: January 27, 2001

A daemon is a particular type of task running on a computer. Daemons have some unique characteristics. Rest assured however that, despite the Greek mythology origin of the word, a daemon is not particularly evil.

Tasks run on a computer are usually run interactively by people. Thus, there's someone sitting in front of a keyboard providing standard input to the task. The standard output of the task usually goes to that person's video screen.

In that sense, daemons are unusual. They run quietly in the background. They have no keyboard. They have no screen. So where do they get their input from? Where do they send their output to?

A web server is an example of a daemon process. It gets its input from the Internet and typically (although not exclusively) sends its output back there.

Consider this sequence of events:

• Mark, who is far away, is running a Netscape browser.
• He types in a URL like http://linux.ComputerAdvocacy.com   Note that Mark is talking to his Netscape client browser. He is not talking to the web server at ComputerAdvocacy.com
• Through the Internet and in compliance with a strict syntactical protocol called http the Netscape client sends a request to the httpd ie: HyperText Transport Protocol Daemon running on a machine at Computer Advocacy.
• httpd at Computer Advocacy does something in order to fulfill the request that it got from Netscape on Mark's behalf.
• A very common action is for it to send back a stream of bits and bytes that are written in HTML, HyperText Markup Language.
• Computer Advocacy says goodbye to Mark's Netscape.
• Netscape goes about the task of rendering all that HTML stuff and makes it look quite fancy on Mark's screen.

Mrs. HTTPD runs the show, but delegates a lot of responsibility to her children.
When Mark "calls", httpd answers the phone and immediately transfers the call to one of her children. These children are also named httpd. By transferring the call, she is free to answer the next call.

This is done for practical reasons. Sometimes those calls come awfully quick. The switchboard lights up. Mrs. HTTPD doesn't want to keep people on hold.

She has a number of children who are always standing by. In fact, she can create even more children should the need arise.

(As a kid, I sometimes felt that way...)
When the call is transferred, it's the child httpd that gets the request.

Often the request is to send a pre-made, pre-existing, ready-to-roll HTML file back to the requester. In fact, once upon a time, that was all that httpd could do. In such a case, httpd reads the requested file and dumps it, byte for byte, back to the browser. The browser gets those bits and bytes and renders them appropriately so that someone like Mark will be suitably impressed.

Sometimes the request isn't for an existing "static" file. Rather, it's a request asking httpd to run some other program. So that's exactly what httpd does. Hopefully, the program does what its designer intended it to do. At least part of that program's job is to output a stream of HTML bits and bytes. The browser gets those bits and bytes and renders them appropriately so that someone like Mark will be suitably impressed.

In other words, as far as the Netscape browser is concerned, the end result is the same. It receives a stream of bits and bytes which it renders. It doesn't know or care that the HTML it received came from a pre-existing file or from some program that made it up on the fly.

By far, the most popular web server in use today is the Apache web server. and that's the one we'll be talking about.

• Building Apache
• Runtime Apache configuration