On Tue, Jan 3, 2012 at 12:18 PM, Olaf van der Spek <[email protected]> wrote: > On Tue, Jan 3, 2012 at 8:10 AM, Clint Byrum <[email protected]> wrote: >> Trying then to send SIGUSR1 is a bug for sure. There are two ways around >> it that I see. Either we must use a pipe to signal the parent that it >> can exit, or try having the parent actually send itself a SIGSTOP, and >> then use SIGCONT from the child. I think the former is more portable, >> and I have a branch here that does that, and no longer waits forever >> with --daemon --user on my Ubuntu precise (dev version) system. > > Why is all this magic needed anyway? > Can't we fork *after* we're sure everything is ready?
I was wondering the same myself, and suspecting threads and forks as Clint and Jeremy already enlightened us. In addition, I can think of the following logic: * A security requirement is to fork into a non-root process before doing anything dangerous. * Modules can do pretty much anything, hence we must assume they are dangerous. * An example is json_server, which will listen on a port upon initialization. * It follows (also from the other reasons) that we must fork before initializing modules. * Init script semantics and just good usability dictates that if initialization fails, the process should abort and return a non-zero value. * Module initialization can fail (and actually does with default configs in the current rpms :-( * It follows that the parent process cannot return before initialization is complete. >From this we end up with the current magic. henrik -- [email protected] +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
