Is there a good reason to write my own daemonize function instead of using daemon(3)?

Question

There are a lot of example implementations of daemons on the net. Most that I saw do not use the daemon(3) function to run the program in the background. Is that just a matter of taste, ignorance, or is there a good reason to write my own daemonize function? Is there a specific disadvantage in using daemon(3)? Is it insecure?

Answer 1

The daemon() function was not historically available in all flavors of Unix, so a lot of "portable" code doesn't use it. There's really no reason to roll your own recipe as long as all the target platforms you care about have daemon().

Answer 2

The BSD daemon() function is very limited and invites misuse. Only very few daemons may use this function correctly.

The systemd man pages have a list of what a correctly written SysV daemon should do when daemonizing:

http://0pointer.de/public/systemd-man/daemon.html

Answer 3

There is no daemon function in POSIX. It's a vendor extension. Thus anyone writing portable code simply writes their own.

Answer 4

If you don't like any of the standard daemon() function actions, you might write your own. You can control whether it switches to the root directory; you can control whether it reconnects the standard I/O channels to /dev/null. But if you want to keep stderr open to a log file, while reconnecting stdin and stdout to /dev/null, you have to decide whether to use daemon() with appropriate options followed by other code is better than rolling your own.

There isn't much rocket science in daemon(); it calls fork() and setsid() (according to the Linux version; the MacOS version mentions suspending SIGHUP while daemon() is operating). Check out the standard resources for more information on daemonization — for example:

• W. Richard Stevens, Bill Fenner, Andrew M. Rudoff UNIX® Network Programming, Vol 1: The Sockets Networking API, 3rd Edn

• Marc J Rochkind Advanced Unix Programming, 2nd Edn