Fork to background

[Wilfried Schobeiri]

memcached and gearmand have "-d Daemon, detach and run in the background."

Can we get that for ./drizzled too?

[BJ Dierkes (derks)]

LP 702579 is also affected by this, and would benefit from a '--daemonize' capability.

[Stewart Smith (stewart)]

The plan is to:

- on startup, check for "--daemonize" in argv
- if not, continue as we do now
- if so,
  - setup pipe
  - fork()
  - child process is the real drizzled
  - child process inits all plugins
  - when plugins have finished initing and we're ready to accept connections,
    reply to parent over pipe saying we're okay.
  - parent can then return success
  - in event of plugin init failure, or child crashing, parent will return failure

NOTE: since initing plugins does things like do InnoDB recovery, it may be several hours (or days, depending on configuration) before drizzled --daemonize returns with a success/failure code. For systems without parallel init: sucks to be you.

[Clint Byrum (clint-fewbar)]

May I suggest that you move fork() to *after* plugin init?

I can't think of any reason why not to. Meanwhile there are a few reasons that make this better:

* it eliminates the need for any pipe
* allows error reporting using stderr directly
* simplifies the daemonizing code.
* for Upstart on Ubuntu, it makes 'expect fork' definitive, as we can say for sure once the fork happens, drizzle is ready to go.

[Stewart Smith (stewart)]

My thought behind it was to be able to report that we crashed during startup (this has been known to happen with rather corrupted databases in InnoDB)

Also we may be using a variety of different logging plugins - none of which could be stderr.

We're also doing a bunch of shared lib loading and the like... and I'm not sure I want to introduce the requirement of being okay across a fork() (if anything uses file locks for example).

I'm thinking that the parent will not exit until drizzle has started or failed, so waiting for it to exit would be the correct behaviour.

[Clint Byrum (clint-fewbar)]

Right, it does seem simpler to deal with forks only where you're doing the fork, namely in the daemonizing code itself.

Upstart seems to run into this problem sometimes where it just waits for the fork(), not the exit of the parent that did the fork. For Drizzle, that shouldn't be of concern, and really, upstart can just manage drizzle in the foreground anyway.

[Stewart Smith (stewart)]

Okay, so I have it going so that --daemon or -d simply waits until the server is ready before exiting (just before the loop processing connections).

I've kept stderr open as we do have some plugins that write stuff to here, so an init script could redirect it to somewhere sane.

Does this sound exactly like what you were looking for?

[Patrick Crews (patrick-crews)]

Played around with the attached branch and things are looking good to me.

This was only cursory testing - things worked as expected for a limited set of cases and nothing blew up ; )
Calling this good unless there is additional testing desired. Will also update the merge request