I've managed to get a Rails app deployed with Capistrano to a server running NGinx & Passenger. On deploy I was getting the "We're sorry, something went wrong" message & was rather confused as the production log was blank. I then switched the rails_env to development in my NGinx Conf & now I'm getting:
SQLite3::CantOpenException
unable to open database file
Rails.root: /www/testcap/releases/20120407015032
I logged into the server, into the current folder within testcap (which I believe symlinks to the latest release) and ran rake db:create, however the db files exist. Having looked within the app's db folder I see both development.db & test.db.
If I run rails s -e production and then head to myurl.com:3000 the app works completely fine, which is weird, and it also works fine when I run rails s -e development too.
I'm at a complete loss as to what the issue might be here. I'm sure it must be a relatively obvious issue, potentially with capistrano? I'm still new to it so I could well have missed anything but googling so far has been fruitless.
The only thing I can think of is that I've nothing explicitly relating to databases in my config/deploy.rb ? However I've not been able to find any guides on the net to help out thus far.
Thanks in advance for your help :)
Jack.
Thanks to the comments from Adam P & Ben L above, I managed to make some head way on this. This Guide also solved my issue.
I followed the steps in that guide above and in my database.yml file I changed the path to the production db from:
`db/production.sqlite3`
To
`/www/testcap/shared/db/production.sqlite3`
(eg the absolute path)
I then added this to my config/deploy.rb:
role :db, "{my vps IP}", :primary => true
On my VPS I went into the nginx conf & removed the line rails_env development (Passenger then sets it to production by default).
And then ran cap deploy followed by cap deploy:migrate, which worked, and I get the app displayed when I visit the URL.
I hope this might help someone out in the future stuck on the same issue :)
Jack.
Related
I've set up my rails server using nginx, passenger, and deploy with capistrano. I've just committed/pushed my project to github and executed cap production deploy and everything worked normally. However my server showed an error, when looking at the error logs it's erroring out on a line of code that is "old". It's pointing to an earlier release and not the current release.
I've checked my passenger config (i believe it's the passenger config... in /sites-enabled/default) and the root is pointing to current/public. Is there anything else that I can check or does anyone know why my server is using a previous release? Thanks!
Turns out there was a migration error, and I needed to correct that and then make sure my migrations ran fine. Hope this silliness on my part helps someone else in the future.
I have a working RoR app that's running on Ubuntu Server, served by Nginx and Unicorn. It's using a local postgres database. I also think it's running on Sinatra instead of rails, but I'm too new to RoR to be able to say for certain.
I am attempting to create a development copy of the app to do some testing with. I'm able to do so using the source code, bundle install, and then running webbrick on my desktop. However, my developer wants to duplicate the environment that the actual production copy is running in. I cloned the server hosting the application, but when I browse to the server I get the dreaded "We're sorry, but something went wrong" error.
Here's what I've checked so for. I looked at the log files in the app/logs directory, and those haven't been updated in the last 6 days, so I suspect nothing relevant will be in them. If I run "service nginx status", it appears to be started. The database is running, and I can access it through the psql interface. Again, I'm pretty much an RoR newb... I was hoping one of you kind folks might give me some advice. Where should I look next? I'm sure it's something simple that I'm just overlooking. Thanks in advance!
In your config > environments > production.rb file change the consider_all_requests_local variable to true.
config.consider_all_requests_local = true
FYI, unicorn was not starting along with NGINX. I was able to script unicorn to start on boot, and this fixed my problem.
I'm having a real tough time diagnosing a 500 error from my application running in production. I've had it working before, but after re-deploying via Capastrano I am unable to get it going.
Here are the facts:
The server is setup with nginx + passenger, and I'm using
PostgreSQL.
Static assets are working properly, as in I'm able to access them just fine in a browser.
I can access the rails console via RAILS_ENV=production bundle exec rails console and perform Active Record actions (like
retrieving data from the db).
Within console, I can run app.get("/"), which returns a 500 error as well (after first showing the query that was run to load
the model).
The production.log file is never written to. I've set permissions 777 on it just for the hell of it. I've also set the log level to
:debug with nothing to show for it.
The nginx log (which passenger also uses) shows no indication of errors, it just notifies about cache misses.
Because nothing of use is being logged, I have no idea what to do here. I've tried setting full permission on the entire app directory with no help. Restarted the server multiple times, nothing. The database is there and rails can clearly communicate with it. I'm not sure what I did to get it to run the first time around. I just don't know why rails isn't outputting anything to the log.
Okay, I figured this out. The app ran fine in development mode, so I knew something production-specific was screwing it up. I went into config/environments/production.rb and changes these settings:
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false # changed from true
config.action_controller.perform_caching = true # changed from false
And then after restarting passenger, rails showed me the error w/ stacktrace. Turns out I was forgetting to precompile the asset pipeline!
Things to check
1) Are you sure you are running in production environment?
Check to see if any entries are in the development.log file
2) Set up your app to email you when a 500 error occurs with a full stack trace. I use the Exception Notifier gem but there are plenty of other solutions for this.
3) When checking your app in the console are you sure you are starting the console in production mode? It is possible that the app is not starting up at all and you just forgot to set the production param thereby thinking that the app runs fine when it doesn't.
4) Are you getting an nginx 500 error or the Rails 500 error? If nginx then it is likely that your app is not starting at all and highly unlikely that you will get any rails error in your log file. The assets are static files and navigating to them proves nothing other than that they exist.
5) Are you sure you are checking the right folder on the server? Sounds really stupid but capistrano could be deploying the app to a folder that is different to the folder that nginx is looking for for your app so double check both the folder capistrano is deploying to and the folder that nginx is looking for are the same.
Just a suggestion, I would use puma rather than passenger. It's awesome with nginx.
My problem is passenger's log file (error.log) has nothing. Then it's a rotation log issue. Run
passenger-config reopen-logs
solved my problem. More.
Have you tried running in development mode to see if the error reports itself?
http://site.com/users/password/new is returning a 404 in production mode but not in development. I am deploying via capistrano and it looks like it's copying the entire site over properly. I tried running the console in production mode on the server and couldn't find anything. Has anyone seen this before?
Since this path works in development and fails in production I would focus on the differences between your environments.
A common issue is that people commit their changes locally, but do not push them to (e.g.) GitHub before deploying with capistrano. Can you ssh into your server and go to the current path and run rake routes there? Try and check if there are differences.
Once you've confirmed that at least the routes on the server are up to date, try checking the production log while accessing /user/password/new. It should be in /shared/log/production.log. You could ssh there and use tail -f production.log to follow the log while you try to access the path.
On a side note, it seems that you are using Devise. There have been similar issues for the user root path. See for example this question. Perhaps this will shed some light on your problem.
Here's what I've determined:
Delta indexing works fine in development
Delta indexing does not work when I push to the production server, and no action is logged in searchd.log
I'm running Phusion Passenger, and, as recommended in the basic troubleshooting guide, have confirmed that:
www-data has permission to run indexing rake tasks (ran them from command line manually)
the path to indexer and searchd are correct (/usr/local/bin)
there are no errors in production.log
What on earth could I possibly be missing? I'm running Ruby Enterprise 1.8.6, Rails 2.3.4, Sphinx 0.9.8.1, and Thinking Sphinx 1.2.11.
Thanks!
Last night as I slept it hit me. Unsurprisingly, it was a stupid issue involving bad configuration, though I am rather surprised that it produced the results it did. I guess I don't know much about Thinking Sphinx internals.
Recently I migrated servers. sphinx.yml looked like this:
production:
bin_path: '/usr/local/bin'
host: mysql.mysite.com
On the new server, MySQL was just a local service, but I had forgotten to remove that line. Interestingly, manual rake reindexing still worked just fine. I'm intrigued that Thinking Sphinx didn't throw an error when trying to reload the deltas, since mysql.mysite.com no longer exists, even though that was clearly the source of the issue.
Thanks for all your help, and sorry to have brought up such a silly problem.
Are there any clues in Apache/Nginx's error log?
Here's the next troubleshooting step I would take. Open up the file for the delta indexing strategy you are using (presumably lib/thinking_sphinx/deltas/default_delta.rb). Find the line where it actually generates the indexing command. In mine (v1.1.6) it's line 20:
output = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
Change that so you can log the command itself, and maybe log the output as well:
command = `#{config.bin_path}indexer --config #{config.config_file} #{rotate} #{delta_index_name model}`
RAILS_DEFAULT_LOGGER.info(command)
output = `#{command}`
RAILS_DEFAULT_LOGGER.info(output)
Deploy that to production and tail the log while modifying a delta-indexed model. Hopefully that will actually show you the problem. Of course maybe the problem is elsewhere in the code and you won't even get to this point, but this is where I would start.
I was having this problem and found the "bin_path" solution mentioned above. When it didn't seem to work, it took me a while to realize that I'd pasted in the example code for "production" when I was testing on "stagiing" environment. Problem solved!
This was after making sure that the rake tasks that config, index, and start sphinx are all running as the same user as your passenger instance. If you log into the server as root to run these tasks, they will work in the console but not via passenger.
I had the same problem. Works on the command line, not inthe app.
Turns out that we still had a slave database that we were using for the indexing, but the slave wasn't getting updated.
As above, same issues were faced our side on two machine. The first one we had an issue with mysql which showed in apache2 log. Only seemed to affect local OSX machine..
Second time when we deployed to Ubuntu server, we had same issue. Rails c production was fine, no errors, bla bla bla.
Ended up being a permissions problem. Couldn't figure this out as there were no problems starting, although I guess I was doing so as root.
Using capistrano and passenger, we did this:
Create a passenger user and added to www-data group
Changed user in deploy.rb to be passenger
Manually changed all the /current files to be owned by above
Logged in as passenger user.
Ran rake ts:rebuild RAILS_ENV="production"
Worked a treat for us...
Good luck