Okay, I pushed a fix for this, using event_reinit. Now beanstalkd will not build with libevent prior to 1.4.1.
I apologize for not replying to any of the original messages in this thread over a month ago. I think my spam filter (gmail) trapped them. kr On Tue, Apr 21, 2009 at 2:16 AM, Keith Rarick <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
