Rbenv: can't rehash, .rbenv shims exists, but it doesn't

Created on 20 Jun 2012  Â·  27Comments  Â·  Source: rbenv/rbenv

I'm using a shared install of rbenv as per https://github.com/sstephenson/rbenv/wiki/shared-install-of-rbenv

In general, it was working, when I only had one ruby installed. But now I installed a jruby too, and have set it using rbenv shell.

And for some reason rbenv rehash ain't working when jruby is active.

bash-3.2$ rbenv rehash
rbenv: cannot rehash: /usr/local/rbenv/shims/.rbenv-shim exists
bash-3.2$ ls -l /usr/local/rbenv/shims/.rbenv-shim
ls: /usr/local/rbenv/shims/.rbenv-shim: No such file or directory

Any ideas of where I should start troubleshooting here?

All 27 comments

According to the source of rbenv-rehash, this file should only exist as long as an rbenv-rehash is running. So you can delete it if you're positive there ain't no rbenv-rehash running and try again.

Yeah, but as demonstrated in my sh capture up there, it doens't actually exist. There's no file there before or after running rbenv rehash, but somehow in the middle of running it rbenv gets confused and thinks it's already there.

However, the problem does not seem to be happening every time, it hasn't been happening lately, it comes away and goes back.

Could accidentally executing echo 'eval "$(rbenv init -)"' more than once possibly cause it? It may be that's what did it, not sure.

I got the same problem.

An issue may be with permissions. Rbenv cannot write to a folder when it expects to be able to write (or something like that), but says file exists instead of access denied?

I had this same problem (also using shared install) and these steps ultimately solved the problem for me:

Making sure the ~/.profile contained the right things:

export RBENV_ROOT=/usr/local/rbenv
# these next are as usual for rbenv
export PATH="$RBENV_ROOT/bin:$PATH"
eval "$(rbenv init -)"

And then followed the steps from this SO answer (starting with obliterating existing folders):
http://stackoverflow.com/a/11146496/21217

Actually here are the steps for posterity:

I was having the same issue. One hint was that rbenv exec bundle exec command worked and that rbenv exec bundle install --path vendor/bundle worked, but their none prefixed equivalents failed.

I wiped my ~/.rbenv, ~/.gem Gemfile.lock and vendor/bundle a few times trying to start fresh. Once these were cleaned away I tried the following:

rbenv install 1.9.3-p194
rbenv rehash # for paranoia's sake
rbenv global 1.9.3-p194
gem env # to check that everything was pointing at 1.9 and not the system
gem install --no-ri --no-rdoc bundler
rbenv rehash # necessary to load up the bundle executable
bundle --path=vendor/bundle

and it worked!

I think the important thing, since I tried this a few times, is to remove the .gem file from your home directory. It seems to get in the way.

Closing due to lack of info. If it comes and goes, it probably isn't a bug with rbenv. Ensure there isn't a background process or overly magical plugin doing rehash. @jrochkind, if you're still affected by this, provide more about your environment. For example:

  • rbenv versions
  • rbenv shims (paste in a Gist)
  • RBENV_DEBUG=1 rbenv rehash (also paste in a Gist)

Hi @mislav,

I've been facing the same problem. I created a gist with the info you asked: https://gist.github.com/4349834

I'm on a Ubuntu 10.04 VM (downloaded from http://www.vagrantbox.es/). Maybe you could try it yourself. I don't remember how I installed rbenv though. Not sure whether I used Chef Solo or did it manually.

@lucaspottersky: Does the /opt/rbenv/shims/.rbenv-shim exist? Does it get fixed when you remove it?

FWIW - I also had this problem, and had to change permissions on the dir where it was checking for the .rbenv-shim... so it could write to the dir, so it stopped complaining.

Also seeing this problem. I'm using rbenv 0.4.0 on CentOS 6.3 in a Vagrant VM, with rbenv installed for all users (as root) in /usr/local. rbenv rehash will fail saying the lock file exists when it doesn't unless the shims directory is world-writable:

$ whoami
vagrant
$ pwd
/usr/local/rbenv
$ ls -l | grep shims
drwxr-xr-x 2 root root  4096 Mar  6 19:39 shims
$ ls -a shims | grep .rbenv-shim
$ rbenv rehash
rbenv: cannot rehash: /usr/local/rbenv/shims/.rbenv-shim exists
$ sudo chmod o+w shims
$ rbenv rehash
$ 

@jimmycuadra could you show the output of which rbenv and rbenv --debug rehash, both as normal and root user?.

@nihilismus Sure, here you go:

$ which rbenv
/usr/local/rbenv/bin/rbenv
$ rbenv rehash --debug
rbenv: cannot rehash: /usr/local/rbenv/shims/.rbenv-shim exists
$ sudo su
# which rbenv
/usr/local/rbenv/bin/rbenv
# rbenv rehash --debug
# 

@jimmycuadra it should be rbenv --debug rehash, not rbenv rehash --debug :)

I tried that first, and got:

rbenv: no such command `--debug'

So the problem might be that just the error message is wrong? It's not that the lock file exists; the actual problem is that the shims directory isn't writeable by the current user?

@mislav I think that's correct. The intent of this section of code in rbenv-rehash is make sure the lock is not present, but there are two ways writing to that path can fail: if the lock is present, and if you don't have permissions to write to that path in the first place. The error message makes it seems like it was always the first reason.

I noticed that all files generated by rbenv rehash in shims directory have the same exact code, so as a workaround I just copied an existing one.

I'm still seeing this, and doing a bit of debugging, I change the

{ echo > "$PROTOTYPE_SHIM_PATH"
} 2>/dev/null ||
{ echo "rbenv: cannot rehash: $PROTOTYPE_SHIM_PATH exists"
  exit 1
} >&2

block to simply echo > "$PROTOTYPE_SHIM_PATH"

I then confirm that the .rbenv-shim file does not exist before running bundle install, and I get: e.g:

Using sunspot 2.0.0 from git://github.com/redbubble/sunspot (at reenable-get-requests-2-0-0)
Using sunspot_rails 2.0.0 from git://github.com/redbubble/sunspot (at reenable-get-requests-2-0-0)
/opt/boxen/rbenv/libexec/rbenv-rehash: line 19: /opt/boxen/rbenv/shims/.rbenv-shim: cannot overwrite existing file

The file is then removed by the script in the remote_prototype_shim() function after.

Is there some kind of race condition, or double execution happening here?

Do you have the gem-rehash plugin? Which version of Bundler? Which version of Rubygems? Is Bundler configured to run multiple jobs in parallel? Check $BUNDLE_JOBS environment variable. Thanks

  • Yes, I have the gem-rehash plugin installed
  • Bundler 1.6.6
  • Rubygems 2.2.2
  • $BUNDLE_JOBS is set to 8.

Doing a BUNDLE JOBS=1 bundle install makes the problem go away, so it looks like that's the culprit

Is this aspect of rbenv basically incompatible with that setting, or is there something else we can do...?

I'm trying to bake gem-rehash functionality into rbenv core, but for that I wanted to cure it of its parallelism problem. I couldn't solve the Bundler jobs problem; see WIP changeset and commit message here https://github.com/sstephenson/rbenv/compare/bundle-rehash

What is the current state of this? I'm not able to run rehash now..

@lacostenycoder Automatic rehash after gem install is now a part of rbenv. How are you not able to run rehash? Are there error messages? Which executable were you expecting to be available after rehash? Is there a `rbenv root/shims/.rbenv-shim` file?

Hey, @mislav. I suppose I might met the same problem. But I am not sure, perhaps it is expected behaviour.

I've switched from rvm to rbenv yesterday. So I am using rbenv 1.0.0-19-g29b4da7. And Ruby 2.3.0.

I've set 2.3.0 as global.

I've installed bundler. $ gem install bundler.

If I call bundler directly from my project I cannot find it.

julian@julian-dell:~/best_quotes$ bundle install
The program 'bundle' is currently not installed. You can install it by typing:
sudo apt-get install bundler

This one is works
julian@julian-dell:~/best_quotes$ rbenv exec bundle install

*_My shims folders looks like this and .rbenv-shim is empty, also I cannnot run rbenv rehash because *_

rbenv: cannot rehash: /home/julian/.rbenv/shims/.rbenv-shim exists

.

julian@julian-dell:~/.rbenv/shims$ ls -la
total 36
drwxrwxr-x  2 julian julian 4096 Mar  8 12:51 .
drwxrwxr-x 12 julian julian 4096 Mar  7 20:43 ..
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 erb
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 gem
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 irb
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 rake
-rw-rw-r--  1 julian julian    0 Mar  7 23:18 .rbenv-shim
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 rdoc
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 ri
-rwxrwxr-x  1 julian julian  399 Mar  7 20:22 ruby
julian@julian-dell:~/.rbenv/shims$ gem list

*** LOCAL GEMS ***

bigdecimal (1.2.8)
bundler (1.11.2)
dhh (0.1.0)
did_you_mean (1.0.0)
io-console (0.4.5)
json (1.8.3)
minitest (5.8.3)
net-telnet (0.1.1)
power_assert (0.2.6)
psych (2.0.17)
rack (1.6.4)
rake (10.4.2)
rdoc (4.2.1)
test-unit (3.1.5)

I guess I should not call rbenv exec explicitly every time, yes?

@raventid You should delete the .rbenv-shim file (which shouldn't have been there) and run rehash again. That should pick up the bundler shim and allow you to invoke bundler.

Seeing the same problem, there's no .rbenv-shim file, but the shim folder doesn't include all executables.

Had servers where the correct shims where installed, and some where it wasn't:

Output of .bundle/config:

root@all1:/data/server# cat .bundle/config 
---
BUNDLE_FROZEN: '1'
BUNDLE_PATH: vendor/bundle
BUNDLE_DISABLE_SHARED_GEMS: '1'
BUNDLE_WITHOUT: development:test
BUNDLE_BIN: bin

On a working server i found this:

root@api3:/data/server# cat .bundle/config 
---
BUNDLE_WITHOUT: development:test
BUNDLE_BIN: bin

So, I'm guessing my problem has to do with the fact --deployment was used with bundler?

@tdegrunt Yes. With bundle install --deployment, all gems from the bundle are not installed in the default gem location, but to vendor/bundle within the project's root directory. In this case, rbenv doesn't pick up the gem executables. Instead, you should use bundle exec rake … to run the executables for this project, or you can add --binstubs to install the binstubs for this project in ./bin directory. Either way, rbenv will not pick up those executables as part of its rbenv rehash process because there is no need to.

Thanks @mislav for your answer. It would still be handy if rbenv would pick it up though, it's easier to do puma than bundle exec puma. Could you elaborate a little on why there is no need to? (Just trying to understand).

Was this page helpful?
0 / 5 - 0 ratings