/ usr / bin / env: ln: слишком много уровней символических ссылок

Эта проблема меня убивает, и я чувствую, что все перепробовал.

Во-первых, проблема началась при обновлении до Capistrano 3. Capistrano теперь использует / usr / bin / env перед каждой командой при развертывании, чтобы убедиться, что настройка среды правильная.

Когда Capistrano создает символические ссылки на необходимый общий каталог и соответствующие файлы, он пытается выполнить такие команды, как:

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

... а затем выдает ошибку:

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

Я понимаю, что это не вина Capistrano, поэтому я начал устранять неполадки, подключившись к серверу по ssh и попробовав ту же команду, и получаю ту же ошибку (что, по крайней мере, хорошо для согласованности). Затем я пробую ту же команду без / usr / bin / env:

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

И работает !!!! Может быть, ты видишь реальное решение, которого нет у меня?

вот результат только команды / usr / bin / env:

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

Я также пробовал такие команды, как следующие, чтобы найти потенциальные циклы символических ссылок:

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

Но не дает правильных результатов:

lrwxrwxrwx 1 deployer deployer ...

person mkralla11    schedule 15.12.2014    source источник
comment
Символическая ссылка, которую capistrano пытается создать, уже существует, и когда вы запускаете развертывание, она зацикливается и создает эту ошибку. Вы можете установить путь env по умолчанию в сценарии capistrano, используя set: default_env. Можете ли вы также опубликовать свой .bash_profile? Capistrano всегда назначает неинтерактивную оболочку без входа в систему, поэтому, когда она входит в систему, она ищет .bash_profile. Это тоже поможет.   -  person user944938    schedule 15.12.2014
comment
Как я сказал в исходном сообщении, я смог проверить проблему без capistrano, подключившись к моему серверу по ssh и выполнив ту же команду с префиксом / usr / bin / env. Таким образом, я могу доказать, что дело не в Капистрано. Кроме того, символическая ссылка еще не существует. Как я уже сказал, когда я пытаюсь выполнить ТО ЖЕ КОМАНДУ в качестве capistrano на моем сервере вручную, я получаю ту же ошибку. (Я также прочитал все документы для cap 3 и знаю о переменной: default_env, но, как я уже сказал, проблема лежит вне capistrano.) Я также опубликую свои .bashrc и .profile.   -  person mkralla11    schedule 16.12.2014
comment
Попробовать запустить его под strace? Как в strace /usr/bin/env ln -s /full/path /different/full/path - может быть, это даст ключ к разгадке.   -  person RoUS    schedule 15.01.2015


Ответы (2)


Возможно, вы не используете ту же ln утилиту.

При вызове его непосредственно из интерактивной оболочки ln может быть переопределено, например. с помощью alias или какой-либо функции оболочки ln() {...;}.

Этого не происходит, когда /usr/bin/env пытается это сделать (AFAIK он ищет ln в PATH). Я подозреваю, что обнаруженный ln имеет проблемы, поэтому вы получаете эту ошибку.

Это пример сценария, который может быть похож на ваш случай:

# 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"

Теперь давайте попробуем две альтернативы, первым идет /usr/bin/env:

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

Затем обычный ln (помните, что мы alias это сделали):

$ 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

Итак, мое предложение: посмотрите на проблемы с ln, например. найдя все возможные альтернативы, которые могут быть видимыми. В bash вы можете запустить это:

$ type -a ln
person polettix    schedule 07.01.2017

Попробуйте это, чтобы найти петли символических ссылок:

find . -follow -printf ""
person oldo    schedule 23.01.2015
comment
вы не видели команду, которую я уже пробовал? find . -maxdepth 20 -type l -exec ls -ld {} + (этот подробнее). И нет, на выходе ничего. - person mkralla11; 23.01.2015