I've been breaking my head over this for over 2 days now, and can't seem to figure out where the problem is. This is mostly a problem related to my setup, but if anyone could help me find a solution to this problem, then I'll be his slave for eternity..!
I'm running Snow leopard(host) and VMware fusion running Ubuntu Lucid server (guest OS). Somehow after a lot of head-banging I managed to get my workspace shared from Mac to Ubuntu. So, essentially I've been able to isolate my dev environment on a VM, which makes it easy for the entire dev team to be on the same environment irrespective of their host OS / setting, etc. While, it certainly has made everything easy, I'm stuck with a specific problem occurring due to sprockets (I guess). Every time I make changes to my stylesheets and reload, I get this error:
Error compiling CSS asset
Errno::EPERM: Operation not permitted - /mnt/hgfs/banjarey/tmp/cache/assets/DCF/780/sprockets%2F5f78b3457def1d02bd3fb75d4e0cfb63
/home/coderboy/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.0/lib/active_support/core_ext/file/atomic.rb:38:in `chown'
The strage thing though is that if I reload the page twice or thrice, the css compiles and everything works alright.
It's a real shame to be reloading the page twice or thrice for every single css change I make. I've played around with memberships and permissions a little bit, but been an amateur I've not ventured deep enough I guess.
Any idea folks ??
I have the same problem. my solution is to modify the File Permission after precompile assets:
#chown apache.root yourapp -R
#chmod 755 yourapp -R
A bit late with this answer, but chmod everytime the app is deploy does not seem to be a good solution. I think the issue is your apache instance and your passenger instance are running as different users. So the solution is to check what user your apache server is running as and set the PassengerDefaultUser,
For example:
PassengerDefaultUser www-data
This worked for me. As Passenger was making files only readable by nobody, weird is that if you just refresh a few times it some how works out, but making sure they are the same user stops this error.
I experienced the same error, but in development!
Solved after clean and recompile assets:
rake assets:clean && rake assets:precompile
Make sure the underlying file system supports the requested operation.
The following commands fixed it for me.
mv public/assets /tmp
ln -s /tmp/assets public/assets
Related
I hope you are all well!
For several days now I have been trying to deploy a simple rails app to Railway.app, and failing catastrophically and repeatedly to get it to run.
Here is the github repo:
https://github.com/CaffieneSage/blogApp-rails-
The error I am getting is during the deploy step specifically:
bundler: not executable: bin/rails
I have successfully deployed apps to heroku in the past. I suspect there is something simple that I am missing. I have tried rerolling and deploying the default rails app to simplify things. I have made sure to us postgres instead of SQLite3 as the db. I have spun up an instance of postgres on railway and tried to set my environment variables to point to it. I have had a go within the CLI as well.
Thanks in advance for any advice you may have to offer!
This is my first post on stack overflow, please go easy on me ;]
The issue likely stems from the script bin/rails not having the executable bit on the file.
You can see the file permissions using ls:
ls -l bin/
All of the files will display:
-rw-r—r—
These need to have the executable bit set, so you can run something like:
chmod +x bin/*
After which all the files should have this permission set:
-rwxr-xr-x
Don’t forget to commit the changes.
Read more on file permissions: https://en.wikipedia.org/wiki/File-system_permissions
Up until now I've been using script/runner to forward bouncebacks to eblast-bounceback#mydomain.com and eblast-bounceback#dev.mydomain.com. However it is no longer working in Rails 4.0. I also can't seem to find a good resource online to illustrate how to do it. I usually get directed to the 'whenever' gem - but that's for cron jobs, not for 'piping to programs'.
So this is essentially what I'm currently doing, but is failing:
|/home/user/rails/dev.www/script/rails runner 'EBlast.receive(STDIN.read)' -e development
How do I get this to work? I'm not on Rails 4.1, I'm on 4.0. FWIW I do not have bin/rails. The above command yields "no such file or directory".
There were actually a few things I needed to do.
The email eblast-bounce#dev.mydomain.com was considered 'unroutable'. At first I figured it was because there wasn't any MX records for the subdomain, so I added one. But then I still got the error. I had manually updated the aliases file in /etc/valiases to pipe to the program using a symlinked directory (because I was deploying with Capistrano, and the directory ends up changing after every deploy). Turns out symlinks don't work for some reason when it comes to exim routing (/home/me/rails_deployments/dev.www/current/bin/rails fails). Maybe I'm wrong about the symlinks thing but the problem went away when I used the solution below.
This problem however was solved when I eventually came to another problem (/usr/bin/env: ruby: No such file or directory). I'm using RVM to manage rubies/gems, and apparently the email forwarder didn't know what ruby was. This leads to the final solution:
(when in cPanel, "pipe to program" assumes the user home directory (/home/me/))
.rvm/wrappers/ruby-2.1.0#website/ruby /home/me/rails_deployments/dev.www/current/bin/rails runner 'EBlast.receive(STDIN.read)' -e development
Where ruby-2.1.0 is my current ruby version, and #website is the gemset used by the EBlast.receive code base.
EDIT: Spoke too soon, the command has its own set of problems...(gemfile not present). This is ludicrous.
I'm trying to test an opensource Ruby on Rails site (pophealth). I've got a VM running Ubuntu 12.10 and RubyMine. It took a while to get all of the gems working right but they are working well now. However, now all of the static assets that are supposed to be precompiled, are missing.
example:
http://0.0.0.0:3000/assets/application-67beadcf527de329bd600098663ee6ca.css
I can see in Firebug it came back with a 404 error. I've run rake assets:precompile several times and that works for the site fine when I run it normally under apache. But with RubyMine working against the same root directory it doesn't like it. I believe RubyMine is running a different web server called 'Thin'. They only thing I can think of is that it is caching its own copy of the webroot somewhere else. I've run find many times but I can't seem to find another local cache of the webroot.
Does anybody have any ideas?
I solved it. This was a stupid mistake on my part. In config/environments/production.rb, I had to set config.assets.compile = true, and then repeat this for the other environments of course.
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
I've a running nginx and Ubuntu 8.09 site running a rails app -- but we are not making use of Peassenger anymore and it seems to take up a lot of memory.
I google around and there's tons of info on how to install Passenger, but I didn't find any on uninstalling.
IF your only concern is the memory usage, removing the Passenger lines from the webserver config file will cause it to no longer be loaded.
If you want to completely remove it from your system, them you'll have to uninstall the gem too, assuming that's how you initially got it.
A tip for the future: I generally keep lots of tiny config files, one for each module that I'm using, so that it's easy to find, edit, and eventually, remove them. This is not the general case, though.
edit: hum, apparently Passenger compiles a new nginx with support for it, so it's not as simple as removing a module. Well, in that case I'd recommend you wipe your current nginx binary and compile a new one without mod_rails. Notice there may still be lines in the existing config file to be removed.
Edit your httpd.conf and remove the lines you once added to install mod_rails.
If you don't remember, look at the installation tutorials and undo the steps in reverse order.