# Backgroundrb misbehaving again

**URL:** <https://www.ruby-forum.com/t/backgroundrb-misbehaving-again/152008>\
**Category:** Rails\
**Created:** [October 28, 2008, 10:51pm UTC](https://www.ruby-forum.com/t/backgroundrb-misbehaving-again/152008 "2008-10-28T22:51:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![bruparel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e47774/32.png) [@bruparel](https://www.ruby-forum.com/u/bruparel)\
**Post date:** [October 28, 2008, 10:51pm UTC](https://www.ruby-forum.com/t/backgroundrb-misbehaving-again/152008/1 "2008-10-28T22:51:15Z")

</div>

I have a really strange problem with Backgroundrb. On one of my staging  
servers, it is not recognizing the RAILS\_ENV variable for some reason.  
I have tried everything I could, that is:

a) stopping and starting from the command line by issuing the following  
command

RAILS\_ENV=staging script/backgroundrb stop|start

b) script/backgroundrb stop|start -e staging

c) from the Capistrano script, here are the relevant snippets:

namespace :backgroundrb do  
desc “Start backgroundrb service”  
task :start, :roles =\> :app do  
run “RAILS\_ENV=#{rails\_env} nohup  
#{current\_path}/script/backgroundrb start 2\>&1 1\>/dev/null”  
end

```
desc "Stop backgroundrb service"
task :stop, :roles => :app do
  # echo at end makes the return code always 0
  run "test -f #{current_path}/log/backgroundrb.pid &&

```

#{current\_path}/script/backgroundrb stop; echo"  
end

```
desc "Restart backgroundrb service"
task :restart, :roles => :app do
  stop
  start
end

```

end

When I look at the log, it is clear to me that it is picking up the  
development environment since the backgroundrb workers are looking for  
the development database. See the following snippet from the log:

Started reminders processing at: 2008-10-28 21:40:01  
Unknown database ‘isabont\_dev’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/connection\_adapters/mysql\_adapter.rb:505:in  
`real_connect' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:505:in`connect’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/connection\_adapters/mysql\_adapter.rb:183:in  
`initialize' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:88:in`new’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/connection\_adapters/mysql\_adapter.rb:88:in  
`mysql_connection' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:292:in`send’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/connection\_adapters/abstract/connection\_specification.rb:292:in  
`connection=' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_specification.rb:260:in`retrieve\_connection’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/connection\_adapters/abstract/connection\_specification.rb:78:in  
`connection' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/base.rb:2693:in`quoted\_table\_name’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/base.rb:1469:in  
`construct_finder_sql' /var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active_record/base.rb:1341:in`find\_every’  
/var/www/apps/isabont/releases/20081028150434/vendor/rails/activerecord/lib/active\_record/base.rb:536:in  
`find' /var/www/apps/isabont/current/app/models/reminder.rb:84:in`find\_delinquent’  
12286,1  
99%

That ‘isabont\_dev’ is my development database. Why is it failing to  
pick up the right environment all of sudden? If it had picked up  
staging then my database would be isabont\_staging since that is how my  
database.yml is configured. What is bad is that this used to work fine  
on the same server. That is; I have deployed on this server using the  
Capistrano deploy.rb many times before. Exactly the same script works  
fine on yet another server in another staging environment (for UK).

Seems like Backgroundrb is stuck on not recognizing the RAILS\_ENV no  
matter how it is passed to it and defaults to development since it is  
trying to query the dev database.

Anyone has experienced this kind of inconsistent behavior in  
Backgroundrb?

Thanks in advance for your time and apologies for the long post.

Bharat

---

<div class="post-metadata">

**Author:** ![bruparel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e47774/32.png) [@bruparel](https://www.ruby-forum.com/u/bruparel)\
**Post date:** [October 29, 2008, 2:26am UTC](https://www.ruby-forum.com/t/backgroundrb-misbehaving-again/152008/2 "2008-10-29T02:26:09Z")

</div>

Please disregard.  
For those who might be interested, the problem was that Backgroundrb had  
spawned a rogue linux process on the port that backgroundrb was supposed  
to listen on and will not go down when you shut Backgroundrb via normal  
commands. I had to find it and then do a kill -9.  
After that, it worked fine.  
Are there any simpler to debug and more reliable alternatives out there?  
I mainly need a cron style functionality to send out scheduled reminders  
and download feeds which are also scheduled.  
Thanks.  
Bharat