Running a Linux Program as a Daemon


Programs that are designed to run as system daemons need to be a little careful how they become daemons to get all of the details right. Here is a list of things that should be done:

  1. Most of the initialization work should be done before the program becomes an actual daemon. This allows any errors to be reported to the user starting the program and a meaningful exit code to be returned. This type of work includes parsing configuration files and opening sockets.

  2. The current directory should be changed to whatever is appropriate. This is often the root directory, but it is never the directory from which the program was run. If the daemon does not do this, it may work properly, but it is preventing the directory from which it was started from being removed, as it is still a program's current directory. It is a good idea to chroot() to a directory if it is possible to do so.

  3. Any unneeded file descriptors should be closed. This may seem obvious, but it can be easy to neglect to close file descriptors that have been inherited instead of opened by the program itself.

  4. The program should then call fork() and the parent process should call exit(), allowing the program that ran the daemon (often a shell) to continue.

  5. The child process, which is continuing, should close stdin, stdout, and stderr, as it will no longer use the terminal. Rather than reuse file descriptors 0, 1, or 2, it is a good idea to open those files as /dev/null. This ensures that any library functions that report error conditions to stdout or stderr do not write those errors into other files the daemon has opened, and it allows the daemon to run external programs without worrying about their output.

  6. To completely disassociate from the terminal from which the daemon was run, it should call setsid() to place it in its own process group. This prevents it from getting signals when the terminal is closed, as well as job-control signals.

The C library provides a daemon() function that handles some of these tasks.

int daemon(int nochdir, int noclose);
This function forks immediately, and if the fork succeeds, the parent process calls _exit() with an exit code of 0. The child process then changes to the root directory unless nochdir is nonzero and redirects stdin, stdout, and stderr to /dev/null unless noclose is nonzero. It also calls setsid() before returning to the child. This could still leave open inherited file descriptors, so programs that use daemon() should check for that. If possible, the programs should also use chroot().

Legal Disclaimer

Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.


This article was sent to us by: Humberto Mitchson at 12082007

Related Articles

1. Designing Shared Libraries
Building shared libraries is only marginally harder than building normal static libraries. There are a few constraints, all of which are easy to manage. There is also o...

2. Shared Libraries
Shared libraries have several advantages over static libraries: Linux shares the memory used for executable code among all the processes that ...

3. Minimizing the Risk for Software Attack under Linux Platforms
One of the best strategies for making a program secure against attempts to exploit their privileges is to make the parts of a program that can be attacked as simple as ...

4. Installing Shared Libraries
The ldconfig program does all the hard work of installing a shared library. You just need to put the files in place and run ldconfig. Follow these steps: ...

5. Using Shared Libraries
The easiest way to use a shared library is to ignore the fact that it is a shared library. The C compiler automatically uses shared libraries instead of static ones unl...

6. What's a Linux Process
What exactly is a process? In the original Unix implementations, a process was any executing program. For each program, the kernel kept track of ...

7. POSIX Interfaces
POSIX Required Types POSIX defines several typedefs defined in the header file <sys/types.h> and used for many arguments and return values. These typede...

8. Common Linux Security Holes
Now that we have looked at ways of reducing the potential impact of insecure code, we go over some of the most common programming mistakes that lead to security problem...

9. Emax vs. vi Unix text editors
Unix developers have traditionally held strong and diverse preferences, especially about editors. Many programmers' editors are available for you to try; the two ...