Background Processes vs. a Daemon: code a daemon

This is from my comment to LinkedIn The Linux Foundation group post "How To Create A Daemon In Linux?".

Background processes vs. a daemon: i.e. if you have a bash script with a super-loop or a while true:

A UNIX Daemon has two general mandatory requirements to be called a "daemon" - UNIX-lexically if you will: it must run as a child of init, and it must not be connected to a terminal.

What you have is a bash script - a process that is forked by bash/shell with the PPID of the shell itself but not init. Secondly, since it is a child process of bash and bash attaches itself to a terminal or TTY, it does not meet the second requirement as well.


So what you have is simply a background process with no knowledge of its environment and that makes it an alien to the system which puts its own survival at danger.

strace your-daemon.sh 2> tmp.txt

vi tmp.txt and you will notice a call to execve(), what that means is bash/shell that is forked by init, exec's a child process - your daemon script.

Reference from the must-have book title "Linux System Programming Talking Directly To The Kernel and C Library":

In general, a program performs the following steps to become a daemon:

1. Call fork( ). This creates a new process, which will become the daemon.

2. In the parent, call exit( ). This ensures that the original parent (the daemon’s
grandparent) is satisfied that its child terminated, that the daemon’s parent is no
longer running, and that the daemon is not a process group leader. This last
point is a requirement for the successful completion of the next step.

3. Call setsid( ), giving the daemon a new process group and session, both of
which have it as leader. This also ensures that the process has no associated controlling terminal (as the process just created a new session, and will not assign one).

4. Change the working directory to the root directory via chdir( ). This is done
because the inherited working directory can be anywhere on the filesystem. Daemons tend to run for the duration of the system’s uptime, and you don’t want to keep some random directory open, and thus prevent an administrator from
unmounting the filesystem containing that directory.

5. Close all file descriptors. You do not want to inherit open file descriptors, and,
unaware, hold them open.

6. Open file descriptors 0, 1, and 2 (standard in, standard out, and standard error) and redirect them to /dev/null.

In addition (not in the book) 7. Trap and handle Signals (see Perl script that follows)

Secondly, if not C, I would recommend using Python or Perl (I am a recent Python convert) for creating daemons; and manage run-control/rc scripts on these lines: http://weqaar.blogspot.com/2011/03/virtualbox-service.html

Here is a Perl sample that illustrates:

ServiceAlert: Monitors a process spawned by a service in /etc/rcX. Alerts using a remote SMTP server if the service is down and restarts it.

View/Download at https://sites.google.com/site/weqaar/Home/files/service-alert.pl?attredirects=0&d=1