Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Linux daemonize

Tags:

linux

daemon

I am writing a Linux daemon . I found two ways to do it.

  1. Daemonize your process by calling fork() and setting sid.
  2. Running your program with &.

Which is the right way to do it?

like image 262
Sirish Avatar asked Jun 22 '10 17:06

Sirish


People also ask

What is Daemonize in Linux?

What is a Daemon in Linux? A daemon (usually pronounced as: day-mon , but sometimes pronounced as to rhyme with diamond ) is a program with a unique purpose. They are utility programs that run silently in the background to monitor and take care of certain subsystems to ensure that the operating system runs properly.

What is Daemonize package?

daemonize runs a command as a Unix daemon. It will close all open file descriptors, change working directory of the process to the root filesystem, reset its umask, run in the background, ignore I/O signals, handle SIGCLD , etc. Most programs that are designed to be run as daemons do that work for themselves.


1 Answers

From http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16

Here are the steps to become a daemon:

  1. fork() so the parent can exit, this returns control to the command line or shell invoking your program. This step is required so that the new process is guaranteed not to be a process group leader. The next step, setsid(), fails if you're a process group leader.
  2. setsid() to become a process group and session group leader. Since a controlling terminal is associated with a session, and this new session has not yet acquired a controlling terminal our process now has no controlling terminal, which is a Good Thing for daemons.
  3. fork() again so the parent, (the session group leader), can exit. This means that we, as a non-session group leader, can never regain a controlling terminal.
  4. chdir("/") to ensure that our process doesn't keep any directory in use. Failure to do this could make it so that an administrator couldn't unmount a filesystem, because it was our current directory. [Equivalently, we could change to any directory containing files important to the daemon's operation.]
  5. umask(0) so that we have complete control over the permissions of anything we write. We don't know what umask we may have inherited. [This step is optional]
  6. close() fds 0, 1, and 2. This releases the standard in, out, and error we inherited from our parent process. We have no way of knowing where these fds might have been redirected to. Note that many daemons use sysconf() to determine the limit _SC_OPEN_MAX. _SC_OPEN_MAX tells you the maximun open files/process. Then in a loop, the daemon can close all possible file descriptors. You have to decide if you need to do this or not. If you think that there might be file-descriptors open you should close them, since there's a limit on number of concurrent file descriptors.
  7. Establish new open descriptors for stdin, stdout and stderr. Even if you don't plan to use them, it is still a good idea to have them open. The precise handling of these is a matter of taste; if you have a logfile, for example, you might wish to open it as stdout or stderr, and open '/dev/null' as stdin; alternatively, you could open '/dev/console' as stderr and/or stdout, and '/dev/null' as stdin, or any other combination that makes sense for your particular daemon.

Better yet, just call the daemon() function if it's available.

like image 148
nos Avatar answered Oct 21 '22 16:10

nos