Patch from Scott McKellar implementing cleaner daemonization; moved daemonizing code...
authormiker <miker@9efc2488-bf62-4759-914b-345cdb29e865>
Sat, 30 Jun 2007 03:14:36 +0000 (03:14 +0000)
committermiker <miker@9efc2488-bf62-4759-914b-345cdb29e865>
Sat, 30 Jun 2007 03:14:36 +0000 (03:14 +0000)
commitc3711902ce4e56bf8239854306692bce6e18cfb8
tree84347b9f41f66c8420a073181bb67005e4055e8e
parent73a91b27abecdc3d069170a8cbe1439a690c3995
Patch from Scott McKellar implementing cleaner daemonization; moved daemonizing code above worker forking in system boostrapping:

1. As long as I was in the neighborhood, I replaced the error messages
going to stderr with messages going to the logging machinery.

2. I altered the comment just above daemonize(), because the original
was inaccurate.  This function does not change the process title.

3. Pedantic point: I captured the return value of fork() with a pid_t
instead of an int.

4. After the fork, the parent process terminates with _exit()
instead of exit().  That way it doesn't flush any buffers or close
any files.  It also doesn't call any functions registered with
atexit().  In fact it doesn't do much of anything except get out of
the way and let the child process take its place in every way.

5. The child process switches to the root directory, calls setsid()
to create a new session, and freopens the three standard streams
to /dev/null.

I could have changed directories before the fork, or at any of
several other places.  I don't think it makes any difference.

I could also have done the freopens before the fork, but if the
fork failed, I might not have a way to report it (if the logging is
going to stderr for some reason).

Note that I'm not flushing any buffers, apart from the three standard
streams.  There's no need to.  The child process inherits the file
descriptors intact and can do with them whatever it likes.  The
parent may have died, but the estate doesn't have to go through
probate.

I didn't add any error checking for chdir(), setsid(), or freopen().
The first two are unlikely to fail, as is the freopen of stdin.  The
freopens of stderr and stdout could fail, if for example they are
redirected to a full disk.  I don't know how paranoid we need to be.

For more details, see archives starting at

  http://list.georgialibraries.org/pipermail/open-ils-dev/2007-June/001378.html

and also

  http://list.georgialibraries.org/pipermail/open-ils-dev/2007-June/001405.html

git-svn-id: svn://svn.open-ils.org/OpenSRF/trunk@987 9efc2488-bf62-4759-914b-345cdb29e865
src/libopensrf/osrf_system.c
src/libopensrf/utils.c