I am trying to install Gitlab CE from source and following this installation guide.
When I attempt to install the gitlab-shell using the command provided.
sudo -u git -H bundle exec rake gitlab:shell:install REDIS_URL=unix:/var/run/redis/redis.sock RAILS_ENV=production SKIP_STORAGE_VALIDATION=true
I received the following stack trace error.
WARNING: This version of GitLab depends on gitlab-shell 4.1.1, but you're running Unknown. Please update gitlab-shell.
rake aborted!
Gitlab::TaskFailedError: Gitlab::TaskFailedError
/home/git/gitlab/lib/tasks/gitlab/task_helpers.rb:87:in `run_command!'
/home/git/gitlab/lib/tasks/gitlab/task_helpers.rb:164:in `clone_repo'
/home/git/gitlab/lib/tasks/gitlab/task_helpers.rb:157:in `checkout_or_clone_tag'
/home/git/gitlab/lib/tasks/gitlab/shell.rake:16:in `block (3 levels) in <top (required)>'
/usr/local/bin/bundle:22:in `load'
/usr/local/bin/bundle:22:in `<main>'
Tasks: TOP => gitlab:shell:install
What config file should I be modifying to fix my issue? Do I need to modify the Redis URL even though I am using the default configuration? By the way, this install is on an Ubuntu 16.04 server.
This might be caused by using a version of git that is too old.
To debug: append the --trace option to bundle exec to get more info on where this error is coming from and inspect the source.
Related
We recently started having trouble with chef-client dying in the middle of a run after taking a lot more time stuck on various parts of the run-list that normally proceeded much quicker. I've been on my home wifi and my colleague has been on the work wifi, which has been having some connectivity problems of its own.
If your ssh connection gets interrupted to a machine while chef-client is running, does that crash the run in seemingly inexplicable ways? I am using PutTY to connect from my Win7 and my colleague is using the Apple Terminal App.
All the machines we've been running this on are Ubuntu 12.04 (in EC2) and have plenty of disk space left over - they're only utilizing ~1GB with ~5GB free.
Here is the output of the log from /var/log/chef/client.log (set with the log_location directive in /etc/chef/client.rb as described here).
[2014-01-08T00:27:07+00:00] WARN: Nodejs user is nodejs
[2014-01-08T00:27:07+00:00] WARN: Cloning resource attributes for group[nodejs] from prior resource (CHEF-3694)
[2014-01-08T00:27:07+00:00] WARN: Previous group[nodejs]: /var/chef/cache/cookbooks/nodejs/recipes/default.rb:26:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Current group[nodejs]: /var/chef/cache/cookbooks/spicoli-app/recipes/default.rb:38:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Cloning resource attributes for user[nodejs] from prior resource (CHEF-3694)
[2014-01-08T00:27:07+00:00] WARN: Previous user[nodejs]: /var/chef/cache/cookbooks/nodejs/recipes/default.rb:34:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Current user[nodejs]: /var/chef/cache/cookbooks/spicoli-app/recipes/default.rb:46:in `from_file'
[2014-01-08T00:27:30+00:00] WARN: Environment is _default
[2014-01-08T00:27:30+00:00] WARN: Nodejs user is nodejs
[2014-01-08T02:04:54+00:00] ERROR: Running exception handlers
[2014-01-08T02:04:54+00:00] ERROR: Exception handlers complete
[2014-01-08T02:04:54+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-01-08T02:04:55+00:00] ERROR: Input/output error - <STDOUT>
[2014-01-08T02:04:57+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
And the error stacktrace just has this:
Generated at 2014-01-08 02:04:54 +0000
Errno::EIO: Input/output error - <STDOUT>
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `write'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `puts'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `puts'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:61:in `display_section'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:44:in `block (2 levels) in display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:43:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:43:in `block in display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:42:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:42:in `display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:130:in `display_error'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:161:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/doc.rb:159:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `block in resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource.rb:637:in `rescue in run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource.rb:643:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection.rb:96:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:433:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:500:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:199:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:193:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:193:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application.rb:208:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:312:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:304:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:304:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:23:in `load'
/usr/bin/chef-client:23:in `<main>'
Which is a really generic error! But it does seem to indicate an interruption to STDOUT output, which kind of makes sense with a client disconnection.
Edit: As requested, here are the contents of the client.rb file (names obfuscated, naturally.)
$ cat /etc/chef/client.rb
log_level :auto
log_location "/var/log/chef/client.log"
chef_server_url "https://api.opscode.com/organizations/myapp"
validation_client_name "my-validator"
node_name "my-app-node"
Edit 2: Attempt using sudo su -s /bin/bash root -c "screen chef-client"
Screen terminated while I was at lunch and recorded a timeout on the ShellOut command for npm install. This was after chef-client was sitting stuck on this operation for over an hour.
[2014-01-09T16:39:07+00:00] WARN: Environment is _default
[2014-01-09T16:39:07+00:00] WARN: Nodejs user is nodejs
[2014-01-09T18:16:28+00:00] ERROR: Running exception handlers
[2014-01-09T18:16:28+00:00] ERROR: Exception handlers complete
[2014-01-09T18:16:28+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-01-09T18:16:31+00:00] ERROR: execute[npm-install-app] (spicoli-app::default line 110) had an error: Mixlib::ShellOut::CommandTimeout: command timed out:
---- Begin output of npm --registry http://my.npm.repo.amazonaws.com:5984/registry/_design/app/_rewrite install --cache /home/nodejs/.npm --tmp /home/nodejs/tmp
--- snip: install messages from npm ---
[2014-01-09T18:16:33+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
This is a totally different error than before. The stacktrace.out file also explicitly mentions ShellOut, so it is entirely different as well. Most oddly, when I run the same npm command from the command line, in finishes in under a minute.
So I'm not sure there is a way to further diagnose the previous failure, but I would welcome other suggestions. For input on this new failure, I asked this followup question.
If your ssh connection gets interrupted to a machine while chef-client is running, does that crash the run in seemingly inexplicable ways?
Well, the stacktrace seems to imply that something like that is happening. The message says "Errno::EIO: Input/output error - <STDOUT>" which is consistent with what I'd expect to see if STDOUT was going over an SSH channel that had been closed.
I suggest 2 things:
Run chef-client with all console output redirected to a file; e.g. add > /tmp/log 2>&1 to the end of the command. (The redirection needs to happen on the remote machine.)
Add -l debug to the command to increase the level of logging, as covered in Opscode's technical FAQ. This could reveal clues that are currently being hidden.
Looking at your second update, this has the hallmarks of some kind of firewall or network related problem.
I am trying to run Siriproxy on a fresh Raspberry Pi.
I have followed this tutorial step by step: http://www.hometoys.com/emagazine.php?art_id=2090
Everything looked to install 100%. But on the last step I tried to run 'rvmsudo siriproxy server' I get this error below.
siri#raspberrypi:~/SiriProxy$ rvmsudo siriproxy server
/home/siri/.rvm/rubies/ruby-1.9.3-p385/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or directory - /root/.siriproxy/config.ym l (Errno::ENOENT)
from /home/siri/.rvm/rubies/ruby-1.9.3-p385/lib/ruby/1.9.1/psych.rb:297:in `open'
from /home/siri/.rvm/rubies/ruby-1.9.3-p385/lib/ruby/1.9.1/psych.rb:297:in `load_file'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/gems/siriproxy-0.3.3/lib/siriproxy/command_line.rb:143:in `parse_options'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/gems/siriproxy-0.3.3/lib/siriproxy/command_line.rb:33:in `initialize'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/gems/siriproxy-0.3.3/bin/siriproxy:6:in `new'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/gems/siriproxy-0.3.3/bin/siriproxy:6:in `<top (required)>'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/bin/siriproxy:23:in `load'
from /home/siri/.rvm/gems/ruby-1.9.3-p385#SiriProxy/bin/siriproxy:23:in `<main>'
It seems like when you ran the sections involving cp ~/SiriProxy/config.example.yml ~/.siriproxy/config.yml you created these directories in your user directory, not in the root directory where it is looking. The ~/ symbol is shorthand for a home directory. Try learning how basic linux navigation works and matching up where your config.yml files should be stored-- e.g., root vs user directories.
I have a problem with Capistrano deploying to a server with RVM and gemsets
executing `deploy:assets:precompile'
* executing "cd /var/app/releases/20111229233555 && rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile"
*** [err ::] rake aborted!
*** [err ::] Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes.
*** [deploy:update_code] rolling back
failed: "rvm_path=$HOME/.rvm/ $HOME/.rvm/bin/rvm-shell '1.9.2#mygemset' -c 'cd /var/app/releases/20111229234715 && rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile'"
This is my Capfile
$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
require 'rvm/capistrano'
set :rvm_bin_path, "$HOME/.rvm/bin"
set :rvm_ruby_string, '1.9.2#mygemset'
set :rvm_type, :user
load 'deploy/assets'
When I log in as the very same user which is used by Capistrano the failing command is executed without any problems.
It seems that Capistrano is using some other environment.
Here is my ~/.rvmrc file:
rvm_gemset_create_on_use_flag=1 rvm_trust_rvmrcs_flag=1
Is there a way how to check which ruby and gemset is used at the execution time?
node.js is and V8 are installed on the system, and all needed gems are in Gemfile:
here is my rvm info:
ruby:
interpreter: "ruby"
version: "1.9.2p290"
date: "2011-07-09"
platform: "x86_64-linux"
patchlevel: "2011-07-09 revision 32553"
full_version: "ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]"
homes:
gem: "/home/capistrano/.rvm/gems/ruby-1.9.2-p290#mygemset"
ruby: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290"
binaries:
ruby: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/ruby"
irb: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/irb"
gem: "/home/capistrano/.rvm/rubies/ruby-1.9.2-p290/bin/gem"
rake: "/home/capistrano/.rvm/gems/ruby-1.9.2-p290#mygemset/bin/rake"
setting up PATH in the deploy.rb solved this issue:
default_environment['PATH'] = "/usr/local/bin:/usr/bin:/bin:/opt/bin:$PATH"
it's a Gentoo distribution and the PATH var seems to be empty when using cap deploy, so I copied the content of server PATH and now it works
This issue went away for me when I installed nodejs (using apt-get) on my server. As I stated in this Stackoverflow answer, it's the most practical choice because you don't need to include any dependencies in your Gemfile.
So I want to deploy my app to Heroku, registered the account and did other necessary things. But I ran on a problem running command heroku keys:add. Here's the errors I get:
ruby#Rubuntu:~/rails_projects/first_app$ heroku keys:add
/home/ruby/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no such file to load -- readline (LoadError)
from /home/ruby/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/heroku-2.1.4/lib/heroku/command/run.rb:1:in `<top (required)>'
from /home/ruby/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /home/ruby/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/heroku-2.1.4/lib/heroku/command.rb:17:in `block in load'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/heroku-2.1.4/lib/heroku/command.rb:16:in `each'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/heroku-2.1.4/lib/heroku/command.rb:16:in `load'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/heroku-2.1.4/bin/heroku:13:in `<top (required)>'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/bin/heroku:19:in `load'
from /home/ruby/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/bin/heroku:19:in `<main>'
Help me out please!
PS! I am learning RoR using this book:
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#sec:install_rubygems
Solution here
It looks like this is a fairly common problem on Ubuntu. From this post on another forum:
On my system Ubuntu (Hardy 8.04) I
required libncurses5-dev and
libreadline5-dev (installed with
apt-get install . Re-run
"ruby extconv.rb" and it will show you
whether anything else is missing, or
create a makefile. Once you have your
makefile, run make, then make install.
Using rvm solved all the problems.
Install RVM with ruby:
$ \curl -L https://get.rvm.io | bash -s stable --ruby
Additionally with rails:
$ \curl -L https://get.rvm.io | bash -s stable --rails
$ gem install heroku
$heroku login
I have installed thin and try to do thin start, which end up with this error
C:/Ruby192/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no such file to load -- C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.8-x86-mingw32/lib/1.9/thin_parser (LoadError)
from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.8-x86-mingw32/lib/thin.rb:48:in `rescue in <top (required)>'
from C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.8-x86-mingw32/lib/thin.rb:43:in `<top (required)>'
from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/Ruby192/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.8-x86-mingw32/bin/thin:5:in `<top (required)>'
from C:/Ruby192/bin/thin:19:in `load'
from C:/Ruby192/bin/thin:19:in `<main>'
Can someone help me out please, thanks in advance
the output denotes a directory called 1.9 i.e.
<ruby_install_dir>/lib/ruby/gems/1.9.1/gems/thin-1.2.8-x86-mingw32/lib/1.9/
Note: My thin version is 1.2.10. In the following i will use the path as it appears on my system.
For some reason the thin gem doesn't come with this directory. But a file called thin_parser.so resides in the parent directory <ruby_install_dir>/lib/ruby/gems/1.9.1/gems/thin-1.2.10/lib/
So my first solution was to create a directory 1.9 and copy the file thin_parser.so to it.
Now thin start works for me.
Alternatively you can edit the file <ruby_install_dir>/lib/ruby/gems/1.9.1/gems/thin-1.2.10/lib/thin.rb and change
if Thin.win?
# Select proper binary under Windows
major_ruby_version = RUBY_VERSION[/^(\d+\.\d+)/]
require "#{Thin::ROOT}/#{major_ruby_version}/thin_parser"
else
require "#{Thin::ROOT}/thin_parser"
end
to
if Thin.win?
# Select proper binary under Windows
major_ruby_version = RUBY_VERSION[/^(\d+\.\d+)/]
require "#{Thin::ROOT}/thin_parser"
else
require "#{Thin::ROOT}/thin_parser"
end
or even simpler
require "#{Thin::ROOT}/thin_parser"
I'm not sure what workaround is the better one, since i don't know what else files thin expects in the not existing directory. I don't know either where the Thin.win? fork becomes important.
I decided in favor of the first solution. But both ways fixed the Problem for me.
Best regards,
Tim
I ran into this same error when running rake db:migrate (I suspect thin start would have given me the same error.)
I'm running on Amazon Linux (rpm based, so similar to CentOS and Redhat). I had previously installed thin as root (gem install thin). Although it may be irrelevant to your situation, just for completeness, I had also installed eventmachine using:
gem install eventmachine --platform=ruby
Here is the error I got:
% rake db:migrate
rake aborted!
LoadError: cannot load such file -- thin_parser
/home/rails/.gem/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
etc. etc.
Based on the above information, I ran rake under strace and discovered that it was looking for thin_parser.so in the wrong place. I was able to fix the problem by installing this symbolic link (I did this as root since I installed thin as root). Obviously, adjust the path to where your version of thin is installed:
cd /usr/local/share/gems1.9/gems/thin-1.6.3/lib
ln -s ../ext/thin_parser/thin_parser.so .
Poof! That fixed it for me.