Periapt Technologies - fresh clean websites
Bookmark and Share

Mastering your Daemons

Those little people inside your computer


There comes a time in every computer owner's career when he has to struggle with daemons. I do not mean the sort of demons, who punish sinful programmers by forcing them to use their least favourite text editor for the rest of eternity. Nor do I mean the ghosts of projects past, that return to haunt those who have moved onto new projects; driving them to the brink of insanity, copious quantitites of real ale and making their goatees go to seed. Rather, I mean the little people who sit inside our computers, keeping the CPUs warm, spinning the hard disks, sorting bits into bytes, and meticulously interpreting our scripts and disassembling our machine code, all whilst singing a merry ditty.

Hard working daemon

Okay, okay I was only joking but there really are daemons inside your Linux, Unix or BSD box and essentially any operating system has an equivalent concept. The term goes back to an MIT project and refers to the Unix processes that sit in the background and do stuff like running databases, serving up web pages and handling email. A daemon is like a backroom boy, who delivers the mail, does stock takes, cleans the toilets whilst the sales staff get the more glamourous job of talking to customers and showing them the latest glossy brochure. The term was inspired by one of James Maxwell's thought experiments:

The 19th century scientist James Maxwell once daydreamed (the polite term is "thought experiment") about a problem in physics. He imagined a closed container which was divided in half. In the middle of the divider was a tiny gate, just large enough to admit one molecule of gas. This gate, in Maxwell's imagination, was operated by a tiny daemon. This daemon observed the speed (i.e. temperature) of the molecules heading for the gate and, depending on the speed, let them through. If he let only slow molecules pass from side A to side B and only fast molecules pass from side B to side A, then A would get hot while B cooled.

This usage in turn goes back to ancient Greek mythology and philosophy:

In Plato's Symposium, the priestess Diotima … describes daemons as "interpreting and transporting human things to the gods and divine things to men; entreaties and sacrifices from below, and ordinances and requitals from above...".

The Christian concept of demons as evil beings goes back to the same etymological roots, but the computing term uses the daemon spelling to emphasise that it is a good and necessary part of a computer's architecture.

The life cycle of a Daemon.

So what does a process need to do, to be counted among the worthy crew of daemons? Let us take the simplest example:

? yes
Daemon behind a curtain, wearing glasses, mouth closed and not sitting on a usb stick

This command will merely print out a stream of single letter affirmations. We can stop it by pressing Ctrl-C, which shows that it is attached to our console terminal. A daemon process should not be attached to a terminal like this. We can detach the process from the terminal, but then you will not be able to stop it with Ctrl-C, without first bringing it back to the foreground using the fg command;

? yes &
? fg

or by tracking down the pid and killing it. Similarly a daemon process should not be rudely spewing out text to a screen like this. To fix that we need to redirect the output — and for good measure we should redirect all the IO.

? yes > /dev/null 2> /dev/null < /dev/null &

A daemon process must also not be sitting on a filesystem that might be unmounted. Usually either the daemon process itself, or the script that starts it, will change the current directory to the root directory, /, to ensure its file system does not disappear. I have inherited a bug report of exactly this form.

? cd / && yes > /dev/null 2> /dev/null < /dev/null &

Unfortunately our little daemon still has a parentage problem. It is descended from a long line of processes that are owned by the user who typed the commands in at the keyboard. You can try to complete the path to daemonhood, by tracking down the parent of the process and killing it. Hmm, that is beginning to sound a bit evil, so I better remind you that treating these processes as beings, is really just a metaphor. These are actually data structures inside the operating system. There are also a few other pieces of tidying up that should be done. The daemon process should be its own session leader and process group leader. (Those concepts are higher groupings of processes.) Also a daemon process likes to know what permissions it is going to leave files with, so it sets its own umask. In summary when a computer boots up and starts spawning daemons, the whole process is as follows:

  1. The init process spawns the boot scripts.
  2. Our boot script spawns the grand-father daemon.
  3. The grandfather daemon spawns the father daemon.
  4. The father daemon starts a new session and spawns the child daemon.
  5. The child daemon tidies up, redirects IO, changes working directory and so on.
  6. All the family of the child daemon have now died, so the init process adopts the child daemon as its own.

Daemon Security

Daemon with the head ofa cockatoo behind bars

So now we have our daemon process, dutifully doing whatever we (or one of our clients) ask of it. However the bitter experience of the computer industry has shown that just about every piece of software can be tricked by into doing something evil on behalf of bad people. A crucial defence against this is to fix such vulnerabilities as soon as they are identified. However this only deals with known vulnerabilities. In order to limit potential damage, due to a daemon taking instructions from bad people, it is normal to take two precautions:

  • The daemon should change identity so that it does not run as the all powerful root user.
  • The daemon should work inside a private virtual computer inside the real one, known as a jail, often using the chroot command.
Nicholas Bamber, 20th May 2011
Behind the magic there has to be technology:
Valid XHTML 1.0 Transitional Valid Robots.txt Ethical Junction Member 2010 Sitemap ©2009-11 Periapt Technologies Ltd