Have got new project with production server already running on passenger.
After doing normal deploy as described in 1 page docs left by old team (only cap prod deploy) we are having constant problems. First of all - code we pushed doesn't seem to be working. It should be adding new data on rake tasks to items in database. Physically code is there - in current folder. But it doesnt seems to be triggered.
I ve noticed that there were no rails or gem installed when I ve tried to do simple rails c via ssh. After installing everything and manually launching code with binding.pry added looks like code was triggered. But via normal scheduled rake task it was not.
It looks like passenger is running in daemon since there are no pid in tmp folder (usual for rails app).
1) Is there a chance restarting server will actually help - it was not restarted after deploy and I have no idea how to restart it without pid.
2)passenger-config restart-app returns actually 2 servers. Can they collide and prevent normal app work?(Update: servers are not same - single letter difference in the name)
Still passenger-config restart-app dont seem to restart server
Sorry for the wall of text by I ve spent 2 nights getting it to work and I still lost.
Related
I am using DelayedJob for a long running task in my app. I have the job defined in a class MyJob saved in app/jobs/my_job.rb.
All was well, but I added some code to the file and restarted the server and the changes are not up. Before it was saving one field and now it should be saving two, and I added a logger.debug line to help me, but nothing is coming up in the logs and the models aren't being saved with the field.
This is in 'production' (though still using Thin webserver).
development works.
Since the folder is in the autoload path (at least if I am not misunderstood) I didn't think I needed to do anything special. But since it is not working, something must be off. Help? Let me know if you need more info.
Well, turns out I had a worker who was off the radar.
I run my server in a docker container (should have mentioned that) so even though I did a
RAILS_ENV=production script/delayed_job restart
in both the container and the host (the container has the app from the host as a volume), a worker I probably started some other time continued on. I saw it in the logs when I went back, so I did a
kill {pid}
and that solved my problem. So Flavio was right, I just had to kill the worker myself because the script wasn't picking it up.
I am using delayed jobs in my rails application. it works fine but there is an issue occurred on production server. I created a class in lib and call its method from controller to generate a csv file through delayed jobs. It was working fine when I ran the delayed jobs on local and production server but then I made some changes to this class for file naming convention and restarted the delayed jobs on local and then on production server. Now when I call that method through delayed job then it works according to latest changes I made to the class and sometimes it uses the old logic of file naming convention.
What could be the issue?
Delayed job has a hidden "feature" which is to ignore any changes to your app, and just use old settings, env-variables, email-templates, etc. You can clear every cache and restart your server, and it still holds onto data which no longer exists anywhere in your app's codebase.
delayed_job - Performs not up to date code?
Also be aware that DJ's "restart" does not always kill and restart all the workers, so you need to hunt them down and kill them all manually with
ps aux | grep delay
See: Rails + Delayed Job => email view template does not get updated
I have not yet found a "clear delayed job cache" function. If it exists, someone please post it here.
In my case, I just spent almost 4 hours trying everything to delete failing delayed_jobs in Heroku. In case you get here trying to kill a zombie delayed_job, but you're in Heroku, this won't work.
You can not do ps aux like you'd do in a regular server, nor you can do rake jobs:clear, and if you check via Rails console, you'll see the jobs there, but not in the Database, so nothing you can do there either.
What I did was placing the app in maintenance mode, made a deployment totally uninstalling delayed_job gem and all its references, and then another deployment reverting that change. That cleared the zombie cache, and that did the trick.
I had a similar issue in Dokku. My solution was to remove the worker=1 entry from my DOKKU_SCALE file (so all it contained was web=1) and also to remove the worker: bundle exec rake jobs:work line from my Procfile.
I pushed that to my production server, reversed the changes above, pushed again and it was fixed.
I have successfully managed to set up a VPS production server (Ubuntu 10.04 LTS) from the excellent Railscasts episode. It's an "internal" server (not live yet), so I've been building my app locally and doing a cap deploy at regular intervals to check that things are running smoothly.
However, what I'd like to do now is delete all records on the production server (as I've just been testing stuff) - that is, to start with a completely empty database for when the site actually goes live to the public.
Obviously, I can do this locally by running something like rake db:reset, but how do I do this on the production server? Should I be adding some code to my deploy.rb file?
I'm a bit of a noob at this, but I've been unable to find anything via a Google search.
** EDIT ** Oh, and obviously this is a one-off - once things go live, I'll remove any code which deletes records!
You can ssh into the server and run any rake command from the application directory. You could create a Capistrano task just to run this one rake task, but since this task is obscenely dangerous with any real system I would not recommend it. The last thing you would want is to accidentally run it.
I have a Rails app installed on a Slicehost server running Apache 2 and Ubuntu LTC 10.04. Things have worked beautifully up until now: I edit a file, do a quick mongrel_rails cluster::restart, and the changes are reflected in production. However, suddenly this process has broken down.
For example, I have a class called Master located in /lib/master.rb. I added a new method to this class that simply runs puts "it works!", then restarted the mongrel cluster. Looking at the production logs, the server throws an error and thinks this method doesn't exist. When I go to the console using ruby script/console production, however, I can use this new method perfectly. I even tried deleting the file containing entire Master class. Once again, the production thought it was still there, but the production console correctly recognized it was missing.
Any ideas? How can the production environment detect a class that doesn't even exist anymore?
Funny, I spend 2 hours debugging this, then post to StackOverflow and figure it out in 20 minutes.
The problem is that I needed to also restart my background jobs as well. They were running the old version of the classes stored in /lib. It's interesting that this problem has never snagged me before.
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