Linux daemonize

Question

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?

Tenney

You could use nohup: #958749 – Pacifa

Answer 1

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.

Virgulate

you do have to close all open descriptors. Otherwise the files may continue to have a reference, which will prevent them from being deleted, for example. This is quite like chdir("/"). – Retrogradation

@n-alexanderso - is daemon() double forks? – Ampersand

A good example at the Ruby WEBrick daemonize (toggle source): ruby-doc.org/stdlib-2.1.1/libdoc/webrick/rdoc/WEBrick/… – Hildebrand

daemon() may not work as you want on Linux. From the daemon() man page: "The GNU C library implementation of this function was taken from BSD, and does not employ the double-fork technique (i.e., fork(2), setsid(2), fork(2)) that is necessary to ensure that the resulting daemon process is not a session leader. Instead, the resulting daemon is a session leader." – Pinter

Answer 2

I suggest not writing your program as a daemon at all. Make it run in the foreground with the file descriptors, current directory, process group, etc as given to it.

If you want to then run this program as a daemon, use start-stop-daemon(8), init(8), runsv (from runit), upstart, systemd, or whatever to launch your process as a daemon. That is, let your user decide how to run your program and don't enforce that it must run as a daemon.

Zack

+1. At the very least, offer the option to run in the foreground. – Armandoarmature

Sorry to bring an old answer, but does monit can launch your process as a daemon as well? – Backplate

Answer 3

Just use daemon(3) (from unistd.h).

The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons. ...

Lyophilize

I've spent several days investigating how I can run flask application as a daemon on ubuntu using jenkins until I saw your advice. Thank you! My problem resolved with shell command export BUILD_ID=dontKillMe daemon flask run – Nihi

Answer 4

The first. The second is not daemonizing, but running on the background. Daemonized programs should be on its own session and process group, and should not have a controlling terminal.

Bannerman

but i still not able understand what is use of setting own session and process group – Tenney

Answer 5

Actually to make a daemon you have to double fork.

Running the program with a & makes the shell run the program in the background, which does not make it a daemon. Daemons have init (pid 1) as a parent, that's why the double fork is needed.

So the nice way to do things, if your program is a daemon, would be to take care of this issue yourself (there are more methods, see here too). You could also use the start-stop-daemon program.

Lungfish

Double fork is something else, it literally involves your program calling fork() twice. #881888 – Spoilt

Answer 6

What language are you using? Some languages have helper methods that make daemonizing easier. For example, Ruby has the daemons package.

Kissee