I have an app that works perfectly on my local machine and am deploying it now. I have the VPS all set up and it pretty much works, as well. My problem comes from not being able to start delayed_job. I do the "ruby script/delayed_job start RAILS_ENV=production" while SSHd to the app and it returns "delayed_job: process with pid 11547 started." When I look for the process in htop, I can't find it.
So I dug around and read that Monit can keep delayed_job going. I set that up, hoping I could start up the delayed_job that way. There's no delayed_job.pid, though, so I didn't get far. I ended up setting up nginx and mysql in it, though, and would like to finish setting up delayed_job. The lack of delayed_job.pid gets in the way.
When I SSH into the app and run "rake jobs:work RAILS_ENV=production", everything works just fine. So I'm pretty sure the app itself is fine.
I'm using collectiveidea's delayed_job. Thanks for any help.
It turns out that there's a problem with the daemons gem. Using the ghazel-daemons fork works perfectly. Now onto setting up Monit.
In my case, I just declare that it must use version 1.0.10 of daemons in the Gemfile:
gem "daemons", "= 1.0.10"
Which is the previous version of daemons from 2008.
Related
I developed a simple rails app which works in development environment under WEBrick. However, when I move to production environment it doesn't work. I fixed trivial errors relating to assets and things. However, some things just don't work. It would be extremely helpful to be able to see what is going on interactively with debugger.
I can insert byebug in the code, and it pauses code from running, but since neither passenger nor nginx logs to STDOUT (by default) I can't get to the byebug prompt. (and neither read STDIN)
Is there a way to run byebug under passenger + nginx?
Edit
This time my issue was related to https.
Passenger author here. Byebug integration is available in Passenger Enterprise: https://www.phusionpassenger.com/library/admin/nginx/debugging_console/ruby/
You can use https://github.com/davejamesmiller/ruby-debug-passenger
This adds a rake task, just run 'rake debug' and you'll be connected to your code at the point where it hits byebug
I'm having trouble using collectiveidea/delayed_jobs to process tasks in Rails 4. Namely, it works, but doesn't seem to want to update code based on recent file updates. This is true on both production and development environments, although I'm focusing on debugging in development first, just to see what might be happening.
I'm on versions delayed_job (4.1.1) and delayed_job_active_record (4.1.0).
If I run a job synchronously (skipping the delayed_jobs worker) things process fine (the following code is what I use to test that):
app/config/initializers/delayed_job.rb
Delayed::Worker.delay_jobs = !(Rails.env.test? || Rails.env.development?)
But with the delayed_jobs table queue / worker running I end up with a significantly older version of my job per outdated code.
I've tried locking the daemons gem at 1.1.9, as mentioned here without luck.
Gemfile
gem 'delayed_job_active_record'
gem 'daemons', '1.1.9'
I could share more code, but I'm not sure it'd do much good. My testing shows just what I've mentioned.
Trouble restarting delayed_job workers is a known issue elsewhere. But my issue seems to be more specifically that, even if I can restart workers, some sort of more general cache seems to be interfering with proper execution. I have also tried restarting application servers in both dev and prod with no luck.
Any similar stories or tips would be greatly helpful!
Having a bit of a problem running multiple workers.
When creating workers with rake jobs:work jobs run without and problem, even when invoking it multiple times, but when creating workers with ruby script/delayed_job -n 5 start all jobs fail with undefined method on Syck::DomainType.
I've searched quite a bit, but can't seem to find the solution for this. I am running DelayedJob on the Mongoid backend. Gem versions:
rake 0.9.2
rails 3.0.6
delayedjob 2.1.4
delayedjob_mongoid 1.0.2
Has anyone experienced a similar error/have a solution? Or short of that some information on why/how workers are being created differently depending on which way they are invoked?
I had the exact same problem. I could reproduce it by loading the job in the console and trying to unserialize it:
$ rails console production
> j = Delayed::Job.last
> YAML.load(j.handler)
On my production environment, I got a Syck::DomainType object whereas in development it just unserialized my object (the data stored in db is the same in both case).
Long story short, I realized that I had ruby 1.9.1 instead of 1.9.2 on my server. Switching to an rvm managed environment with ruby-1.9.2p290 solved the problem for me.
Perhaps ruby script/delayed_job -n 5 start all doesn't invoke Bundler.setup and that's why it's different from other ways of launching workers? (Just a guess)
You may be able to fix the Syck::DomainType error by putting this at the top of config/application.rb
require 'yaml'
YAML::ENGINE.yamler = 'syck'
# [...]
require File.expand_path('../boot', __FILE__)
Thanks to this answer: rails error, couldn't parse YAML
It looks like the problem was derived from bundler >= 1.0.10 loading up psych and overwriting some of sycks functionality if libyaml is present. I was able to remove the libyaml install from my system, something that I know won't be possible for everyone. Tough to track down, hopefully this post will help someone else
Run it with:
bundle exec ./script/delayed_job -n 5 start
I don't know why but when I run rake commands in my rails project, nothing happens. Also rails server does nothing. Any suggestions?
you can add an "ruby -rtracer" to the begining to see where it is hanging.
The solution for me entailed exiting rails console -sandbox.
I think sandboxing console puts a lock of some sort on the database.
You could try adding the --trace argument to your rake calls to see if that sheds any light on where it is getting stuck. Failing that there may be some information in the logs.
It does suggest that something that is getting stuck during setting up your environment which may be something you've added to environment.rb.
Are you using rvm?
A lot of advice these days is to install ruby within rvm and rails within an rvm gemset. If you've done this, then you need to remember to do commands such as these at the start of your terminal session:
rvm use 1.9.3
rvm gemset use ruby193rails3
I found if I forgot to do this, then the rake command, even just a simple rake --version , would hang and thrash the disk.
...which all seems a bit fragile. I guess it's latching onto part of rails but with some files missing due to rvm not having moved them into place or something.
Spring has a bug in Rails 4.1 which also causes this (not the OP's issue, based on date). For those googling, I solved this problem my typing "spring stop". Spring will be automatically restarted the next time you run "rails ". To give proper credit, I found this information from this blog:
http://www.dixis.com/?p=754
What fixed this for me was running
bin/spring stop
and then running my rake command after.
This is my first stab at Ruby on Rails. Just deployed a very simple app to Heroku.
The thing is that my app runs flawlessly on mongrel development; When I run it with "mongrel_rails start -e production" however, I get the error "We're sorry, but something went wrong."
For the life of me, I couldn't debug this. Heroku logs is not returning anything, the Exceptional addon in Heroku is not returning anything, and I cannot find mongrel.log on my Windows machine (when I run mongrel using: mongrel_rails start -e production -d"
I'm using Rails 2.3.5 and sqlite3 with bundler to pack my gems.
I was told that probably rails is not booting up correctly. I can't find any other way to diagnose this. Any ideas?
Thanks,
ANaimi
Take a look at your log/production.log file. That should contain detailed information about what's going on. It will usually contain a line that specifies the name of a gem that needs to be installed.
Heroku doesn't use mongrel, so I'm assuming that's what you're trying to do to figure out why it isn't working when you push it to heroku.
I've found, in most cases, my heroku problems have been because of uninstalled gems. Make sure you create a gem manifest.
Try tailing logs while booting up. From the terminal in the log directory do: tail -f *.log and then launch the app from another terminal (likely it's development.log since you're probably running in development mode.)
Not sure if this got definitively answered, however, check your '%app_root%/config/environments/' folder, and compare 'development.rb' to 'production.rb'.
Make sure that you have all necessary settings in the production.rb file - might have missed something important there.