Hey Keith, What you're saying makes sense. It's better practice to let the OS's init/launch mechanisms daemonize a process. Not to keep beating a dead horse.. -d is convenient for quick deploys, without having to write your own init script. Each variant of the OS has their own nuances and it's annoying to have to fiddle with those scripts to boot the daemon. beanstalkd & isn't a good option because you'll have to do some extra work to handle the HUP on exit of the shell... something like beanstalkd & disown, but depends on the OS.
It's really just a convenience thing.. and keeping -d doesn't take away from sysops who want the OS to daemonize/manage the process. Anyways, I'm done now :) whatever you decide is cool... beanstalkd is awesome, good work on 1.5, its solid. Peter On Feb 5, 1:12 am, Keith Rarick <[email protected]> wrote: > On Sat, Feb 4, 2012 at 6:56 PM, Chad Kouse <[email protected]> wrote: > > I agree it's handy. I run dedicated beanstalkd servers so I can see > > the value. Ops team would appreciate only having one thing to monitor. > > If its a big issue though it's no problem. We will make it work. > > Thanks for the great work. > > Thanks! > > It really shouldn't be any more difficult to run beanstalkd without the > -d flag. I've tried to make switching more straightforward by including > several examples of configuration for production process-monitoring > tools. If there's anything else I can do to make life easier, I'd love to > hear about it. > > Ops teams in particular should be pleased that -d is no longer there > to confuse the issue. It's easier to monitor a process that doesn't > daemonize itself. > > kr -- 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.
