"The Linux Gazette...making Linux just a little more fun!"


(?) The Answer Guy (!)


By James T. Dennis,
LinuxCare, http://www.linuxcare.com/


(?) Daemons

From sangeeth george on Tue, 18 Jan 2000

sir,

i am sangeeth george, doing my final year Btech.in information technology.recently i came across a new topic(which not actually a new one but i came to know only recently)called "Daemons".since then i had been fetching for materials to learn more about it.but i couldn't find any worthy one.can u help me in getting more info about this topic. i've got a lot of doubts about it and i would like to share with you.some of them are,

(!) A daemon under UNIX (and some other operating systems) is a program which runs in the background, has no controlling terminal (is detached) and is (under UNIX and Linux) in it's own process group.
Other than those (relatively minor and technical) details it is just a program.
I've heard that the term originally was 'dmon' from Multics, or ITS or some other predecessor to UNIX. I guess it stood for "device monitor."
However, since I'm on my Debian box, which has a 'dict' client, and a 'dictd' (dictionary daemon) and several freely available lexicons installed I'll just yank in a definition from that:
[using my xemacs macro equivalent of vi's :r!dict daemon]

(?) From Jargon File (4.0.0/24 July 1996) [jargon]:


daemon /day'mn/ or /dee'mn/ /n./ [from the mythological
meaning, later rationalized as the acronym `Disk And Execution
MONitor'] A program that is not invoked explicitly, but lies
dormant waiting for some condition(s) to occur. The idea is that
the perpetrator of the condition need not be aware that a daemon is
lurking (though often a program will commit an action only because
it knows that it will implicitly invoke a daemon). For example,
under {{ITS}} writing a file on the {LPT} spooler's directory
would invoke the spooling daemon, which would then print the file.
The advantage is that programs wanting (in this example) files
printed need neither compete for access to nor understand any
idiosyncrasies of the {LPT}. They simply enter their implicit
requests and let the daemon decide what to do with them. Daemons
are usually spawned automatically by the system, and may either
live forever or be regenerated at intervals.

Daemon and {demon} are often used interchangeably, but seem to
have distinct connotations. The term `daemon' was introduced to
computing by {CTSS} people (who pronounced it /dee'mon/) and
used it to refer to what ITS called a {dragon}. Although the
meaning and the pronunciation have drifted, we think this glossary
reflects current (1996) usage.

From The Free On-line Dictionary of Computing (15Feb98) [foldoc]:


daemon

<operating system> /day'mn/ or /dee'mn/ (From the mythological
meaning, later rationalised as the acronym "Disk And Execution
MONitor") A program that is not invoked explicitly, but lies
dormant waiting for some condition(s) to occur. The idea is
that the perpetrator of the condition need not be aware that a
daemon is lurking (though often a program will commit an
action only because it knows that it will implicitly invoke a
daemon).

For example, under {ITS} writing a file on the {LPT} spooler's
directory would invoke the spooling daemon, which would then
print the file. The advantage is that programs wanting files
printed need neither compete for access to, nor understand any
idiosyncrasies of, the {LPT}. They simply enter their
implicit requests and let the daemon decide what to do with
them. Daemons are usually spawned automatically by the
system, and may either live forever or be regenerated at
intervals.

{Unix} systems run many daemons, chiefly to handle requests
for services from other {host}s on a {network}. Most of these
are now started as required by a single real daemon, {inetd},
rather than running continuously. Examples are {cron} (local
timed command execution), {rshd} (remote command execution),
{rlogind} and {telnetd} (remote login), {ftpd}, {nfsd} (file
transfer), {lpd} (printing).

Daemon and {demon} are often used interchangeably, but seem to
have distinct connotations (see {demon}). The term "daemon"
was introduced to computing by {CTSS} people (who pronounced
it /dee'mon/) and used it to refer to what {ITS} called a
{dragon}.

(11 May 1995)
(!) It's obvious that the Jargon file and FOLDOC entries are basically the same. I believe that the Jargon entry was adopted by FOLDOC.

(?) 1.It is possible for us to retrieve the commands that we have entered in a shell promptusing 'uparrow key'.Is it due to the action of Daemons . if yes,name of that daemon?

(!) What you're describing is a feature of some of the common UNIX/Linux command shells. It is not done through any sort of daemon.

(?) 2. in one of the magazine i've read that Daemons are much more powerful than TSR ,as Tsr need some user intervention.is it true?can u give an eg. for that.

(!) That is hogwash. The old MS-DOS print spooler TSR (terminate/stay resident) was about as close to a daemon as you can get under MS-DOS (serving almost the same function as the lpd line printer daemon under Linux and the BSD UNIX').

(?) 3.surely there must be some kind of difference exsists between ordinary programs and daemons in the INSTALLATION part ,since daemons are executed by system itself . can you explain me how to(where to)install a program if we want it to act as a Daemon.

(!) No. Daemons can be started by any user at any time under UNIX. A daemon is just a program that detaches itself from it's controlling terminal (by closing STDIN, standard input, STDOUT, standard output, and STDERR, standard error file descriptors) and using the setpgrp() system call to set itself into a separate process group.
Most daemons on most UNIX systems are started by the init process (either directly, via /etc/inittab, or through one of the rc*) scripts during the boot process.
The most common daemons are:
inetd:
"Dispatcher" --- starts other daemons in response to network connections on well known service (WKS) ports as specified in the /etc/inetd.conf and the /etc/services files.
sendmail:
Handles SMTP,
competitors: qmail and Postfix
init:
"Father of all processes" --- it starts all of the rc* scripts, and it monitors all terminals, and consoles forcing new getty and xdm processes on them as login sessions are ended.
httpd:
Web server daemon.
cron:
Scheduler: this keeps a list of commands to be run at given intervals. cron performs most of the routine system maintenance
atd:
The at service used to be managed by cron (there was a cron job that ran every minute to execute any outstanding at jobs). However, recently (a couple years ago) at was set into a separate daemon in most Linux distributions. This is particularly useful on laptops where the old method would keep the disk drives spinning unnecessarily.
lpd:
print spool server
... et cetera.

(?) 4.what really is the importance of Daemons in new world (say E-commerce)?(i raised this question since i may most probably take a seminar on this topic)

(!) There is nothing special about daemons.
What is the importance of background jobs in e-commerce and the "new world?" They are just programs. Likewise for daemons.

(?) kindly provide me anwsers to these questions + any website from where i can learn more about it.

(!) You need a basic book on UNIX.

(?) expecting an early reply from you.

thanking you
sangeeth george t


Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 50 February 2000
HTML transformation by of Starshine Technical Services, http://www.starshine.org/


[ Answer Guy Current Index ] [ Index of Past Answers ] greetings 1 2 3 5
5 6 7 8 9
10 11   13 14 15 16 17
18 19 20 21 22 23 24  
26 27 28 29 30 31 32 33
34   36 37 38 39 42 41
42 43 44 45 46 47 48


[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Linux Gazette FAQ ] [ Next Section ]