So I have a hobby web server running. It works fine, and I have fun making cgi scripts and thinking I can take down facebook.

Anyway, my latest project has been to make my own database program to accept queries for a forum. I have no real need to do this, its mostly just for educational purposes. And one thing I've been unable to figure out, is what the advantage is to actually forking a daemon (somewhat complicated and I have no real idea as to what is going on when it all happens), and just using setsid in the program to keep it running in the background. I know there has to be a reason, but its a tough thing to search for, and I've been able to find nothing really helpful.

So I figured I'd ask. If anyone can tell me what a daemon process does for me, that'd be great. And if anyone could tell me what the forking procedure actually does, conceptually (in either C or python terms, if possible. I could probably make sense of java), that'd be an added bonus.

Thanks a ton in advance!

How about a definition (from http://www.linfo.org/daemon.html -- worth reading the entire document)?
OK, so what the heck does that mean? Basically, a daemon process is forked off a parent process and will continue until the system is shut down, there is a fatal error in the daemon programming or somebody or something kills it.

By the way, if you're going to roll your own data base, you're probably going to want to look into the inter process communications facilities (IPC); i.e., shared memory, semaphores, and message queues. Those are how you manage multiple simultaneous access so you don't have collisions and other bad things happening. A quick overview is found at http://web.cs.wpi.edu/~cs3013/b00/we...6-unixipc.html (and Google "unix ipc" will turn up a whole bevy of stuff that's interesting).

The best I can do is point you to Linux Daemon Writing HOWTO (http://www.netzmafia.de/skripten/uni...mon-howto.html) that is pretty much everything you need to know about the what's, why's, how's and wherefore's. I'm not being lazy -- it's a large subject that really can't be adequately addressed here.

Hope this helps some.

Thanks for the answer! I read through everything you posted (and a little more) and I certainly learned a lot. I'm still not entirely sure, however, why just doing setsid in the program to make it run independently in the background is not adequate. I do however, now understand why the procedure for making a daemon is so complicated, and why it does what it does.

Is just running a program in the background with setsid just bad practice, or does it actually restrict me somehow? Does it have to do with memory management?

When you use the fork() system call and exit (the parent), the child process is orphaned and then becomes a child of the init process (PID 1).

In Unix and Linux systems, http://www.enderunix.org/docs/eng/daemon.php That is, a setsid() process will not become a child of init.

Is one better than the other? Well, I confess that I don't really know; I suspect that there are subtle differences (and, probably butt-byters) either way. I suppose the best thing would be... well, try it both ways and see if it makes any difference. I've always done it the old-fashioned way (which is what MySQL and PostgreSQL and other applications do) but that's pretty much because that's the way I learned to doit toit.

There is an example setsid() program at http://www.enderunix.org/docs/eng/exampled.c that might be worth a look-see.

Hope this helps some.

Alright. Thanks to the links you posted, and the further searching they inspired, I've managed to make sense of what I found earlier at an activestate tutorial on daemonization.

So, to answer my own question, setsid() is technically enough to make a process into a daemon, but it has a few holes. One, if the process calling setsid() is a session leader, UNIX won't allow setsid() to function, because allowing such would cause any child processes to be orphaned and estranged. So, in order to make sure setsid() will always execute, a child process is forked using fork(). Since a child is never a session leader, setsid() will work always.

Running setsid() on the forked process will then make it its own session and process group leader. But, this means it can be attached to a controlling terminal, which daemons don't want/need (possible security risk?), but in UNIX, only a session leader can be attached to a controlling tty, so a child of that process could not have a controlling tty. Another fork creates a child process.

At this point killing off the two parent processes closes all connections to the daemonized process, making it isolated (and, again, more secure? still not sure what isolation does for it, but oh well). Once its parents are killed off, it will be adopted by init, and officially be a daemon in Unix.

Yup, the really basic thing you (must) do is fork-and-exec so the child can operate without a controlling terminal (it'll just sit there all by its lonesome doing what it does). Best of luck with your data base application.