/usr/bin/env: ln: Too many levels of symbolic links
Asked Answered
R

3

6

This problem is killing me and I feel like I've tried everything.

First off, the problem started happening when upgrading to Capistrano 3. Capistrano now utilizes /usr/bin/env before every command when deploying, to make sure the environment setup is correct.

When Capistrano goes to create symlinks to the necessary shared directory and respective files, it attempts commands like:

/usr/bin/env ln -s /full/path /different/full/path

...and then it errors out:

/usr/bin/env: ln: Too many levels of symbolic links

I realize it's not Capistrano's fault, so I began troubleshooting by ssh'ing to my server and trying the same command, and I receive the same error (which at least is good for consistency). I then try the same command without /usr/bin/env:

ln -s /full/path /different/full/path

And it works!!!! Maybe you can see the real solution that I can't?

here is the output of just the /usr/bin/env command:

rvm_bin_path=/home/deployer/.rvm/bin
GEM_HOME=/home/deployer/.rvm/gems/ruby-1.9.3-p392
TERM=xterm-256color
SHELL=/bin/bash
IRBRC=/home/deployer/.rvm/rubies/ruby-1.9.3-p392/.irbrc
SSH_CLIENT=...
OLDPWD=/home/deployer/Sites/example.com
MY_RUBY_HOME=/home/deployer/.rvm/rubies/ruby-1.9.3-p392
SSH_TTY=/dev/pts/0
USER=deployer
LS_COLORS= .....
_system_type=Linux
rvm_path=/home/deployer/.rvm
SSH_AUTH_SOCK=....
rvm_prefix=/home/deployer
MAIL=/var/mail/deployer
PATH=/home/deployer/.rvm/gems/ruby-1.9.3-p392/bin:/home/deployer/.rvm/gems/ruby-1.9.3-p392@global/bin:/home/deployer/.rvm/rubies/ruby-1.9.3-p392/bin:/home/deployer/.rvm/bin:/opt/rubyee/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/deployer/.rvm/bin
PWD=/home/deployer/Sites
LANG=en_US.UTF-8
_system_arch=i386
_system_version=12.04
rvm_version=1.26.4 (latest)
SHLVL=1
HOME=/home/deployer
LOGNAME=deployer
GEM_PATH=/home/deployer/.rvm/gems/ruby-1.9.3-p392:/home/deployer/.rvm/gems/ruby-1.9.3-p392@global
SSH_CONNECTION=....
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
RUBY_VERSION=ruby-1.9.3-p392
_system_name=Ubuntu
_=/usr/bin/env

I have also tried commands like the following, to find potential symlink loops:

find . -maxdepth 20 -type l -exec ls -ld {} +

But is not producing correct results:

lrwxrwxrwx 1 deployer deployer ...
Referent answered 15/12, 2014 at 18:53 Comment(3)
The symlink which capistrano is trying to create already exists and when you run a deploy it is self-looping and creating this error. You can set default env path in capistrano script using set :default_env. Can you also post your .bash_profile too? Capistrano always assigns a non-login, non-interactive shell so when it is logged in it looksup for .bash_profile. Having that would help too.Sleight
As I said in the original post, I was able to test the problem without capistrano, by ssh'ing to my server and attempting the same command, with /usr/bin/env prefixing it. Therefore, I can prove that Capistrano is not the cause. Also, the symlink does not already exist for a fact. Like I said, when attempting the SAME COMMAND as capistrano on my server manually, I get the same error. (I also have read all the docs for cap 3, and I know about the :default_env variable, but like I said, the problem lies outside of capistrano.) I will post my .bashrc and .profile as well.Referent
Try running it under strace? As in strace /usr/bin/env ln -s /full/path /different/full/path -- maybe that will provide a clew.Cacus
K
2

You might not being using the same ln utility.

When invoking it directly from the interactive shell, ln might be overridden e.g. by an alias or by some shell function ln() {...;}.

This does not happen when /usr/bin/env tries to do that (AFAIK it looks for ln in PATH). I suspect that the ln it finds has issues, so you are getting this error.

This is an example scenario that might be similar to your case:

# start from an empty directory
$ ls -l
total 0
# create a problematic `ln` in the current directory
$ ln -s ln ln
$ ls -l
total 0
lrwxrwxrwx 1 me me 2 Jan  7 20:28 ln -> ln
# have an alias for the "real" ln
$ alias ln=/bin/ln
# mess up PATH
$ PATH="$PWD"

Now let's try the two alternatives, /usr/bin/env goes first:

$ /usr/bin/env ln -s /some/path /tmp/path
/usr/bin/env: ln: Too many levels of symbolic links

Then plain ln (remember that we aliased it):

$ ln -s /some/path /tmp/path
$ echo $?
0
$ /bin/ls -l /tmp/path
lrwxrwxrwx 1 me me 10 Jan  7 20:31 /tmp/path -> /some/path

So my suggestion is: look at issues with ln, e.g. by finding all different alternatives that might be visible. In bash you might run this:

$ type -a ln
Kessler answered 7/1, 2017 at 19:42 Comment(0)
B
0

Try this to find symlink loops:

find . -follow -printf ""
Bertsche answered 23/1, 2015 at 2:13 Comment(1)
did you not see the command I already tried? find . -maxdepth 20 -type l -exec ls -ld {} + (this one is more detailed). And no, the output is nothing.Referent
B
0

if you are using docker so you should install ruby in your case

docker run ruby

source

https://github.com/docker/for-win/issues/5763#issuecomment-585749243

Brume answered 25/1, 2023 at 8:57 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.