Thanks, I'll get on this tomorrow morning. All else being equal, I want to do as much as possible before forking so that errors can be detected and reported visibly.
That leads me to option 2, calling event_reinit. If I can just go ahead and call it safely regardless of the platform I'd prefer that. Otherwise, I'll try moving the fork before event_init, then moving as much as possible (probably just prot_replay_binlog) before the fork. kr On Mon, Apr 20, 2009 at 5:47 PM, Godfrey <[email protected]> wrote: > > I can confirm this problem is happening on my MBP running 10.5.6, and > yun's solution does seems to fix it. > > Godfrey > > On Mar 8, 7:57 pm, Yun Huang Yong <[email protected]> wrote: >> On Mar 7, 10:02 pm, Alex MacCaw <[email protected]> wrote: >> >> > I'm doing something like this: >> > beanstalkd -l 0.0.0.0 -p 8002 -d >> > And the process just disappears! >> > If I don't'detachit it, it works. >> >> > Any ideas why? >> >> This is due to BSD's kqueue event queue not surviving across fork(). >> Quoting the man page (from my FreeBSD box, its the same on MacOSX): >> >> The kqueue() system call creates a new kernel event queue and >> returns a >> descriptor. The queue is not inherited by a child created with >> fork(2). >> However, if rfork(2) is called without the RFFDG flag, then the >> descrip- >> tor table is shared, which will allow sharing of the kqueue >> between two >> processes. >> >> There's a few solutions I can see to this: >> >> 1. daemonize() earlier, in my own testing I moved the "if (detach) >> daemonize();" to just before event_init(), allowing all the beanstalkd >> init stuff to execute as normal. >> >> 2. Preserve the event_base struct returned from event_init(), then >> call event_reinit() as suggested by Niels Provos >> inhttp://monkeymail.org/archives/libevent-users/2007-November/001061.html >> >> 3. Use rfork() as suggested by the kqueue man page >> >> The solutions get more and more BSD specific as you go down the list >> so Option 1. seems like the simplest solution since it keeps >> beanstalkd's execution path fairly identical across platforms (one of >> the confusing things about debugging this issue was why the "-d" fork >> () would affect behaviour so drastically). I don't think this has any >> side effects on beanstalkd... >> >> yun > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
