Main Content

The Kernel, Shells and Daemons. Greek Gods in computing

Archive - Originally posted on "The Horse's Mouth" - 2012-07-01 08:07:02 - Graham Ellis

The Greek Gods didn't like washing up or ironing. So they employed mortals to to it. Problem was that those mortals didn't last for ever, and sometimes went on strike over one thing and another. So The Gods did a deal with some of the current batch of mortals, and it went like this: "We will make you immortal, and you, in perpituity, will do the particluar job that you're trained up for - be it washing, ironing ot cooking - queitly and without complaint unless there's a very serious issue that you need to tell us about. And the rest of the time you can just relax idly around". These immortal beings, but not deity, were known as the Daemons.

Nuts have a shell, and they have the edible (in some varieties) bit in the middle, which is known as the Kernel.

What's running on your Linux or Unix Computer?

You'll have a Kernel at the centre of things, controlling uses of the memory and file system (and under Unix / Linux, devices are also treated as files). You'll have a shell through which an interactive user can interact with the system - enter commands from the keyboard (or an alterative is STDIN is rerouted) and output to the screen (or an alterative if STDOUT is rerouted). And you'll have a number of daemons - there to pick up background process requests such as ftp, sftp, ssh, sql and http and to look after resources like printers. There's more about individual daemons [here].


There may be several users of the same daemon service at the same time. For example, two different individuals may want to connect to a web server to run ssh (secure terminal) sessions at the same time. So daemons are designed to sit awaiting a request, and when a request is received to spawn ("fork) a copy of themselves - also know as a "child process" to do the actual work, whilst the parent reverts to waiting for further requests. When the child has completed its work, it exits (dies) releasing the memory it was using back to the kernel. This is the model show in the middle column of the diagram.

Where it's planned / expected that a daemon will receive a very large number of requests, the process of forking and dieing would consume significant resource, so another model is employed. In such cases, a number of child processes are preforked and are available to be passed a request when one is received by the parent. And rather than exiting on completion, the child will signal back to the parent that it's done with the job it was given, and it will then be given another job to do in due course. This is the model used by the Apache httpd web server, and is shown in the left column of the diagram.

Some daemons are very rarely called upon, if ever ... but need to be available just in case. It's pretty rare for a remote system to set its time from your clock through the network time protocol, for example - but it's a usefully synchronisation service to have available. If all of these very rarely used daemons were to be running, and occupying memory, all the time then that would be an underutilisation of resources. So a single daemon - inetd or xinetd is run, which will manage the staring and stopping of the very rare daemons if they're called up. Ths is the model shown in the right column of the diagram.


When you start up a Linux or Unix system, you want appropriate daemons to start.

Here's how:
• The daemon programs themselves will be located in places like /usr/bin
• Scripts to control how each daemon is started and stopped will be in /etc/init.d
• Symbolic links in /etc/rc3.d will be provided as a patch panel to decide which daemon start scripts are to be run, and in what order (files starting with S are run in asciibetic order!)

The structure / directory names vary a little between Linux and Unix releases, I'm afraid, and there are a whole lot of rcX.d directories, where X is the runstate being entered. On many systems, you'll have a utility such as chkconfig to help you manage this setup. Run states are shown [here].