I'm using zeus ruby gem on a vagrant for development
the problem is that running any of the following commands
zeus start
env ZEUSSOCK=/home/vagrant/zeus.sock zeus start
env ZEUSSOCK=/tmp/zeus.sock zeus start
export ZEUSSOCK=/tmp/zeus.sock
zeus start
produces the following error
Starting Zeus server
Unable to accept socket connection.
It looks like Zeus is already running. If not, remove .zeus.sock and try again.
there is no .zeus.sock file created in the project root directory or in any of the specified directories
how can i fix this problem without using NFS vagrant configuration
reference to wiki
running on
Mac osx 10.9
Vagrant 1.3.5
zeus (0.13.3)
the solution I found was to update the zeus gem any version grater than 0.13.4.pre2
any of the upper commands works fine with me on version 0.14.0.rc1 and also on 0.13.4.pre2
version 0.13.4.pre2 works best with RAILS_ENV, as of version 0.14.0.rc1 they suppressed executing test with RAILS_ENV enabled
Related
Ubuntu 20 > Apache 2.4 > Passenger 6 > ruby 2.7.4 > Rails 6.1 > `ruby script`
I'm invoking a ruby script via backticks from within a Rails controller (and collecting a return integer).
In production, somwhere in this chain, something is insisting on trying to run the ruby script with ruby 2.7.0 (the native system version) and complaining that it should be 2.7.4 (which it should).
The Rails app itself runs fine until I invoke a script.
When invoking the script, Passenger (I think?) is logging in the Apache error.log with
/home/rcm/.rbenv/versions/2.7.4/lib/ruby/2.7.0/bundler/definition.rb:495:in `validate_ruby!':
Your Ruby version is 2.7.0, but your Gemfile specified 2.7.4 (Bundler::RubyVersionMisMatch)
I have searched and tried numerous suggestions (most of which were already done).
All scripts use: #!/usr/bin/env ruby
$PATH includes /home/rcm/.rbenv/shims:/usr/local/sbin:... and the usual suspects (I see that's rather explicit with /home/rcm/.rbenv instead of ~/.rbenv --- does it matter?)
The apache .conf file has: PassengerRuby /home/rcm/.rbenv/versions/2.7.4/bin/ruby
I have .ruby-version files at every layer I can think of specifying 2.7.4
I have used rbenv to declare global 2.7.4.
I have updated bundler.
I have run bundle install.
Restarted apache, rebooted the system, etc.
I can't figure out where in the chain anything could be trying to run the script with 2.7.0.
It all works fine in dev mode on macOS and Ubuntu, and even works fine running the project in e -production mode with the built in Puma on both macOS and Ubuntu. Only in the full Apache > Passenger production mode is there a problem. So, I'm thinking it has to be Passenger that's confused, but it's running the Rails app itself just fine -- which makes me confused.
The screwy part is, this was all working fine, and "all of a sudden" I'm getting this failure. (No idea which bit I twiddled.)
Would appreciate any ideas to give me something new to chase. Thanks.
ruby is not necessarily the same as the ruby running Rails. It will run whatever the first one it finds in its PATH. Since this is running on a webserver, this will be different from the PATH of your own user.
Use bundle exec ruby to run the Ruby associated with the application.
The best thing to do is to not run a script, instead incorporate the script code as a class in your Rails project. This is faster and easier to test.
Edit: 2021/05/12
The problem resolved itself after doing a full restart of my PC. I'll revisit this question when/if I can recreate the issue.
Problem
When running rails c from VSCode's integrated terminal, each new command line prepends a set of garbage characters that I have to delete.
$ rails c
Running via Spring preloader in process 4481
Loading development environment (Rails 6.1.3.2)
irb(main):001:2> ^[[7;1R^[[7;1R
Notes
Seems to be specific to my VSCode configuration? This problem does not occur when running in a separate Windows Terminal instance.
Does not occur when running python and node shells.
Setup
I am using
WSL2 Ubuntu 20.04
VSCode integrated terminal w/ WSL remote enabled
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-linux]
Rails 6.1.3.2
I can manually run bundle install and get something sane back, but when I let Puppet provision a Vagrant box, this happens the second time (the first I get successful output).
[default] Running provisioner: Vagrant::Provisioners::Puppet...
[default] Running Puppet with /tmp/vagrant-puppet/manifests/default.pp...
stdin: is not a tty
/opt/vagrant_ruby/lib/ruby/site_ruby/1.8/rubygems.rb:900:in `report_activate_error': Could not find RubyGem puppet (>= 0) (Gem::LoadError)
from /opt/vagrant_ruby/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `activate'
from /opt/vagrant_ruby/lib/ruby/site_ruby/1.8/rubygems.rb:1276:in `gem'
from /opt/vagrant_ruby/bin/puppet:18
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
I am not requesting the puppet gem anywhere, it's not in my Gemfile and my manifest does not require it either. Why is the puppet gem being looked for, and how do I get rid of this error?
I'm using https://github.com/blt04/puppet-rvm for provisioning my Vagrant box with RVM and I get the same problem. Unsetting "default_use => true" indeed fixes it. Unfortunately then you have to manually select your target Ruby once you ssh'd into the box.
Alternatively, you can add the puppet gem explicitly to the default Ruby in your manifest (not to any gemset, just to the Ruby itself). It still kept bugging me about some config file for hiera (??) missing, but it seemed to work anyway.
I'm wondering if RVM on Vagrant is even worth the hassle. The whole point about creating a Vagrant box is to have an isolated environment for a single project, so why would I need multiple Rubies/Gemsets then?
Puppet is run by you VM on your VM. Make sure the gem is still installed for users vagrant and root.
It could be a switch of your default ruby version too (system vs installed via rvm or rbenv ?).
Hope this helps.
Puppet is expected to be run by vagrant with the system ruby, but RVM may default to your chosen installed ruby. To work around this, I did this (a pretty ugly hack) while still having a default ruby when logging in normally:
In your vagrant file:
# setup working dir only to exploit in below
working_dir = '/home/vagrant/puppet'
config.vm.provision :shell, :inline => "mkdir -p #{working_dir}"
config.vm.provision "puppet" do |puppet|
# [ ... Your config ... ]
# before puppet is run, vagrand `cd`s into the working directory, failing to escape it.
puppet.working_directory = "#{working_dir}; rvm use system || true"
end
Due to an escaping bug/feature in the vagrant puppet provider (https://github.com/mitchellh/vagrant/blob/master/plugins/provisioners/puppet/provisioner/puppet.rb#L154) this causes vagrant to
Start out with the rvm loaded and configured with the default
Change into the given directory
Switch to the system ruby, making the gem be found again
Run puppet like on the first run without any RVM-rubies interfering with it.
I am trying to get Ruby on Rails going on my Windows 7 machine. I am using gitbash and have install ruby using ruby installer. All my gems have installed successfully (Rails 3.0.7), but when I try to run a command like rails s I get sh.exe": rails: command not found
echo $PATH gives me:
/c/Users/Dave/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Ruby192/bin:/c/Program Files/Common Files/Microsoft Shared/Windows Live:/c/Program Files/NVIDIA Corporation/PhysX/Common:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files/Common Files/Adobe/AGL:/c/Program Files/QuickTime/QTSystem/:/c/Program Files/Common Files/Microsoft Shared/Windows Live
Since the path for Ruby is in there I am at a bit of a loss for how to be able to start the rails server.
running gem install rails fixed it
This Problem confuses basic developers. Because they simultaneously use both Git Bash & Command Prompt with Ruby and Rails.
When we type "Rails any command" in CMD with Ruby and Rails, we don't see any failure. But if we run the same command in gitbash means, we get the result "Command not found". Running "Gem install rails" fixs it for gitbash users as the above sayings.
For those who use both Git and Cmd with ROR, they can get the command executed anyhow by running on any of the one...
I'm working with Xubuntu 11.04.
I do not succeed to have thin running at server startup.
when I try the command:
/etc/init.d/thin start
I get the following message:
/usr/bin/env: ruby 1.8: No such file or ...
But the commands ruby -v is working fine and the result is ruby 1.8.7 (2011-02-18 patchlevel334) Ruby enterprise
rails -v is also working fine and the result is Rails 2.3.5
If I do the command sudo thin -C configfile.yml start then the thin server is starting without any issue.
Why can't it be started with the server? What can I do to have it working?
The thin script is a usual one which is working fine on a Debian-lenny
I got the some error when using sudo gem install unicorn, and find a solution here. When ruby is not installed in the location /usr/bin/ruby, you need give a full path of ruby which means you need to use command like follows:
/full/path/to/ruby /etc/init.d/thin start
Hope this also works for you.
The header of your file should be:
#!/usr/bin/env ruby
If you include any additional arguments they should be flags for ruby itself, as others may be interpreted as a script name.
What you may have is:
#!/usr/bin/env "ruby 1.8"
Unless you have an executable named ruby 1.8 including the space, that won't work.