Rails - Aug 2007 - backgroundrb: failed to find slave socket - (RuntimeError)

Every time I try to create a worker using backgroundrb, I receive this
error in the backgroundrb server log:

 failed to find slave socket - (RuntimeError)
 /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.1/lib/slave.rb:435:in
`initialize''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
`new''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
`new_worker''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in
`dispatch''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`initialize''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`new''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`dispatch''
 .../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in
`new_worker''


I''m not doing anything fancy.  On an action I simply create the worker

def test
  MiddleMan.new_worker(:class => :test_worker)
end

and in the worker I just write to the log.  It never gets that far
though, because when it tries to create the worker it keeps raising the
failed to find slave socket error.  Has anyone run into something like
this before, or have any ideas what could be causing the problem?  I''m
completely stumped.

Version Info
backgroundrb (0.2.1)
slave (1.2.1)
daemons (1.0.6)

Cheers,
Ray
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''m afraid I''ve run into the same thing on OSX.  I''ve
tried install
the rb-slave port as well as the slave gem (seems like they''re the
same).

Anybody?

20070822-16:08:49 (21090) Loading Worker Class File: /Users/stevend/
Projects/extrovert/cms/lib/workers/email_search_results_worker.rb
20070822-16:10:09 (21090) failed to find slave socket - (RuntimeError)
20070822-16:10:09 (21090) /opt/local/lib/ruby/gems/1.8/gems/
slave-1.2.1/lib/slave.rb:435:in `initialize''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
`new_worker''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in
`dispatch''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`initialize''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`new''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`dispatch''
20070822-16:10:09 (21090) /Users/stevend/Projects/extrovert/cms/vendor/
plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in
`new_worker''


On Aug 15, 4:45 am, Raymond O''Connor <rails-mailing-l...@andreas-
s.net> wrote:
> Every time I try to create a worker using backgroundrb, I receive this
> error in the backgroundrb server log:
>
>  failed to findslavesocket - (RuntimeError)
>  /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.1/lib/slave.rb:435:in
> `initialize''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
> `new''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
> `new_worker''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in
> `dispatch''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `initialize''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `new''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `dispatch''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in
> `new_worker''
>
> I''m not doing anything fancy.  On an action I simply create the
worker
>
> def test
>   MiddleMan.new_worker(:class => :test_worker)
> end
>
> and in the worker I just write to the log.  It never gets that far
> though, because when it tries to create the worker it keeps raising the
> failed to findslavesocket error.  Has anyone run into something like
> this before, or have any ideas what could be causing the problem? 
I''m
> completely stumped.
>
> Version Info
> backgroundrb (0.2.1)slave(1.2.1)
> daemons (1.0.6)
>
> Cheers,
> Ray
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''m experiencing the same issue.

Are there any alternatives to BackgroundRb? I just want to run some 
async tasks.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Backgroundrb seems to function very well when it comes to
''triggered''
jobs. The time scheduling though is very choppy.We converted the jobs
to a custom daemon w/ thread calls. This was helpful example code for
daemons in case you need it: http://snippets.dzone.com/posts/show/2265

On Sep 5, 5:23 am, Giant Cranes
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> I''m experiencing the same issue.
>
> Are there any alternatives to BackgroundRb? I just want to run some
> async tasks.
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Dan wrote:
> We are having the same problem... For our case, we have noticed that
> the /tmp/backgroundrb.$$ (i.e.  /tmp/backgroundrb.26943/ where 26943
> is the PID) gets filled up w/ worker socket files which don''t get
> cleaned up even after the worker has stopped. After 42 of those files
> are created, background simply stops processing, period. It had to be
> restarted. We upgraded to backgroundrb from the Dejavu trunk, and it
> helped in that when this issue happened, backgroundrb would at least
> try again. It still gets stuck, but I can get it to start processing
> again if I remove the workder files from /tmp/backgroundrb.$$/. This
> 42 file max happens for all workers.
Do you call self.delete at the end of each worker to remove it from the 
queue? It''s also good practice to wrap the entire do_work call in a 
begin..rescue statement to ensure that the self.delete call will get 
called.

We''re running several large-scale deployments of BackgrounDRb that are 
iterating over 120,000 workers and are loving it.

--
Roderick van Domburg
http://www.nedforce.nl
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Yea, we did the self.delete. You are running 120,000 *time-triggered*
workers with no problems? Standard triggered background jobs works
fine, the time scheduled ones do the behavior described.

thanks

On Sep 5, 8:26 am, Roderick van Domburg <rails-mailing-l...@andreas-
s.net> wrote:
> Dan wrote:
> > We are having the same problem... For our case, we have noticed that
> > the /tmp/backgroundrb.$$ (i.e.  /tmp/backgroundrb.26943/ where 26943
> > is the PID) gets filled up w/ worker socket files which don''t
get
> > cleaned up even after the worker has stopped. After 42 of those files
> > are created, background simply stops processing, period. It had to be
> > restarted. We upgraded to backgroundrb from the Dejavu trunk, and it
> > helped in that when this issue happened, backgroundrb would at least
> > try again. It still gets stuck, but I can get it to start processing
> > again if I remove the workder files from /tmp/backgroundrb.$$/. This
> > 42 file max happens for all workers.
>
> Do you call self.delete at the end of each worker to remove it from the
> queue? It''s also good practice to wrap the entire do_work call in
a
> begin..rescue statement to ensure that the self.delete call will get
> called.
>
> We''re running several large-scale deployments of BackgrounDRb that
are
> iterating over 120,000 workers and are loving it.
>
> --
> Roderick van Domburghttp://www.nedforce.nl
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Dan wrote:
> Yea, we did the self.delete. You are running 120,000 *time-triggered*
> workers with no problems? Standard triggered background jobs works
> fine, the time scheduled ones do the behavior described.
We schedule a single "maintenance worker" that in turn spawns any
other
workers as necessary depending on the current time and the tasks 
required. So our backgroundrb_schedule.yml only contains a single entry.

--
Roderick van Domburg
http://www.nedforce.nl
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ooh ok, thanks. So that''s the difference. In essence your using
background as a daemon. We''ve been trying to use it with multiple
entries to run time-scheduled jobs and having the behavior mentioned.
We reverted to using a daemon threads for jobs and our own methods of
scheduling.

On 9/5/07, Roderick van Domburg
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Dan wrote:
> > Yea, we did the self.delete. You are running 120,000 *time-triggered*
> > workers with no problems? Standard triggered background jobs works
> > fine, the time scheduled ones do the behavior described.
>
> We schedule a single "maintenance worker" that in turn spawns any
other
> workers as necessary depending on the current time and the tasks
> required. So our backgroundrb_schedule.yml only contains a single entry.
>
> --
> Roderick van Domburg
> http://www.nedforce.nl
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Raymond O''Connor

I had the same problem several minutes ago.
After below command

chmod -R 777 /tmp

the issue is resolved.



On Aug 15, 6:45 pm, Raymond O''Connor <rails-mailing-l...@andreas-
s.net> wrote:
> Every time I try to create a worker using backgroundrb, I receive this
> error in the backgroundrb server log:
>
>  failed to find slave socket - (RuntimeError)
>  /usr/local/lib/ruby/gems/1.8/gems/slave-1.2.1/lib/slave.rb:435:in
> `initialize''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
> `new''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
> `new_worker''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in
> `dispatch''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `initialize''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `new''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
> `dispatch''
> 
.../vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in
> `new_worker''
>
> I''m not doing anything fancy.  On an action I simply create the
worker
>
> def test
>   MiddleMan.new_worker(:class => :test_worker)
> end
>
> and in the worker I just write to the log.  It never gets that far
> though, because when it tries to create the worker it keeps raising the
> failed to find slave socket error.  Has anyone run into something like
> this before, or have any ideas what could be causing the problem? 
I''m
> completely stumped.
>
> Version Info
> backgroundrb (0.2.1)
> slave (1.2.1)
> daemons (1.0.6)
>
> Cheers,
> Ray
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, 10 Sep 2007, codian wrote:
> 
> Raymond O''Connor
> 
> I had the same problem several minutes ago.
> After below command
> 
> chmod -R 777 /tmp
  That should be 1777 if you are going to do that to /tmp.  You don''t
  want any directory world writable without a sticky
bit.
> 
> the issue is resolved.
> 
        Hugh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks Hugh. :)



On Sep 10, 2007, at 10:45 PM, Hugh Sasse wrote:
>
> On Mon, 10 Sep 2007, codian wrote:
>
>>
>> Raymond O''Connor
>>
>> I had the same problem several minutes ago.
>> After below command
>>
>> chmod -R 777 /tmp
>
>   That should be 1777 if you are going to do that to /tmp.  You
don''t
>   want any directory world writable without a sticky bit.
>>
>> the issue is resolved.
>>
>
>         Hugh
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---