We''ve got some backgroundrb workers that we want to start at some point after backgroundrb has been started, and exit as soon as they''ve finished their task. The starting works fine and reliably, using: MiddleMan.new_worker(:worker => worker, :worker_key => jobkey) MiddleMan.worker(worker, jobkey).async_wrapper(:job_key => jobkey, :arg => task.id) worker and jobkey are both extracted from our database table of jobs to be run. When using the previous version of backgroundrb we were just calling exit at the end of execution in those workers that we wanted to die once they''d done their work. However this now results in: Error calling method wrapper with 516 on worker scanner_worker exit /usr/data/nac_development/rails/lib/nac_worker.rb:84:in `exit'' /usr/data/nac_development/rails/lib/nac_worker.rb:84:in `wrapper'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:313:in `send'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:313:in `invoke_user_method'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:245:in `process_request'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:219:in `receive_data'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:209:in `receive_internal_data'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _parser.rb:44:in `extract'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _parser.rb:26:in `loop'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _parser.rb:26:in `extract'' /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m eta_worker.rb:207:in `receive_internal_data'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _worker.rb:55:in `handle_internal_messages'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:194:in `handle_read_event'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:192:in `each'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:192:in `handle_read_event'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:146:in `start_reactor'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:139:in `loop'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _core.rb:139:in `start_reactor'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet _worker.rb:20:in `start_worker'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner :33:in `load_worker'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner :26:in `initialize'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner :47:in `new'' /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner :47 /usr/local/bin/packet_worker_runner:19:in `load'' /usr/local/bin/packet_worker_runner:19 After some checking online, we tried moving to using: MiddleMan.worker(worker_name, job_key).delete at the end of the worker after it had finished all work. This seems to work, but only about half the time. Sometimes the worker process will die, and can no longer be seen in the process list, but sometimes it continues to sit there after the worker has finished doing all it''s work. If the worker is re-run using the same job key it will run fine again using the same process and the process will sometimes then be removed correctly, but of course the expected operation on our live system is that a lot of these workers will never be run twice with the same job key, as we want the ability to run many concurrently. As such we would end up with hundreds of erroneous worker processes from backgroundrb. We never used to get unkilled workers using the old version of backgroundrb, so I feel safe in assuming this is some issue with the delete method rather than our worker''s code. I am assuming that I am doing something wrong in my deletion here. What should I be doing to reliably exit/kill a worker from within itself once it has finied executing it''s designated task? Thanks in advance. -- Dan Meyers Network Specialist, Lancaster University E-Mail: d.meyers at lancaster.ac.uk