Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Daemon programming

2 views
Skip to first unread message

Rafi Kil

unread,
May 7, 1998, 3:00:00 AM5/7/98
to
Hi,

Does anyone can explain me briefly (or point to some internet resources)
what is the difference between daemon-process and plain process in Unix
and how do I cause Unix process to become daemon ?
Thanks in advance, Rafi

Steve Bellenot

unread,
May 7, 1998, 3:00:00 AM5/7/98
to

In article <3551C5A6...@flash-networks.com>,

A daemon process is a plain unix process which has hidden itself from
keyboard interrupts (and perhaps other things.) Depending on the version
of unix a number of steps most be done including closing all file
the usual file describtors, ingoring interrupts, forking one or more
times (parents exit) and starting a new process group. This is all from
memory, so perhaps I forgot a couple. I bet Richard Stevens Advanced
Unix Programming will tell you more, but that is not in front of me
either.
--
bell...@math.fsu.edu http://www.math.fsu.edu/~bellenot (850)644-7189 (4053fax)


Russell Cannon

unread,
May 8, 1998, 3:00:00 AM5/8/98
to

Rafi Kil wrote in message <3551C5A6...@flash-networks.com>...


>Hi,
>
>Does anyone can explain me briefly (or point to some internet resources)
>what is the difference between daemon-process and plain process in Unix
>and how do I cause Unix process to become daemon ?
> Thanks in advance, Rafi
>

Rafi,

There are various opinion about what constitutes a bonifide UNIX daemon.
Some say that any process that forks and closes all STD I/O and then
continues executing and performing a real process would be considered a
daemon. Others say that the term daemon is reserved for those programs that
open sockets to conduct interprocess or internetwork communications.

I tend to take a middle view. A daemon is a program that forks, waits for
some event, and then does something as a result of the event. For processes
that are launched by inetd, the fork is an optional step. The waiting and
listening is where a program is blocking on events (anything from mouse
motion in GUI drivers to incoming traffic on sockets). The event could
simply be a signal from kill(1). A program that forked, blocked for a
SIGHUP, and then wrote a line to the syslog before exiting would be a daemon
in its most rudimentary form.

I do not consider just forking and running in the background to be
sufficient to call something a daemon. I once wrote a crack program that
was designed to test the strength of my user's passwords. I did not want
such a long-running, CPU-intensive application to be stuck to a console or
tty, so I coded it to fork, close all standard I/O channels, and continue
processing in the background. Because this program just processed in the
background and was not waiting for system events, I do not consider it to be
a daemon.

I also wrote a program that opened a socket and exchanged encrypted network
packets between HP-UX servers and then processed the packets. This would be
considered a daemon even by the strictest interpretation.

By definition, any process that is not a daemon, would be considered just a
user process. This is not to be confused, however, with the difference
between a user process and a kernel process. That distinction would put
virtually all daemon processes into the "user process" category as this term
is pulling double-duty.

Shalom,
Russ
Russell T. Cannon
HP-UX System Administrator

0 new messages