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?
views:
110answers:
4
+4
A:
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().
Kaelin Colclasure
2010-09-15 18:20:58
Not just historically; it's never been standardized and has no standard behavior. Every vendor's may be different or it might not exist at all. Best never to use it.
R..
2010-09-15 22:27:22
+2
A:
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 - Steven's "UNIX Network Programming", Rochkind "Advanced UNIX Programming" for more information on daemonization.
Jonathan Leffler
2010-09-15 18:51:41
+4
A:
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:
+3
A:
There is no daemon function in POSIX. It's a vendor extension. Thus anyone writing portable code simply writes their own.
R..
2010-09-15 21:31:42