RH 6.1, 7.4, 7.6 зависящая от пользователя ошибка в s sh и установка LD_LIBRARY_PATH и openmpi mpiexec - PullRequest
Новая
       38

RH 6.1, 7.4, 7.6 зависящая от пользователя ошибка в s sh и установка LD_LIBRARY_PATH и openmpi mpiexec

0 голосов
/ 30 января 2020

И, да, это странно.

У меня были проблемы с запуском openmpi-4.0.2 на RH 7.6. Все segfaults, даже не сценарий оболочки MPI. Если я запускаю от имени другого пользователя, все работает так, как ожидалось - поэтому есть что-то зависящее от пользователя. И я танцевал свое окружение и окружение другого пользователя в поисках того, что является токси c.

После разборки вещей до чистого металла я обнаружил, что базовая команда s sh устанавливает переменную среды LD_LIBRARY_PATH к строке, заканчивающейся на ":", и это токси c в моем пользователе. Это не toxi c для другого пользователя.

Это происходит для RH 6.1, 7.4 и 7.6. У меня есть система RH 7.1, в которой это НЕ происходит (причудливость продолжает давать и давать).

Мне нужна одна из двух вещей, чтобы решить эту проблему: либо способ заполнения LD_LIBRARY_PATH в базовом s sh команда из команды «mpiexe c» (все мои попытки не увенчались успехом), или найдите причину root в среде моего пользователя и устраните ее.

Следующее из RH 6.1, который выдает фактическое сообщение об ошибке, а не просто ошибку. 

-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney:fred ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
LD_LIBRARY_PATH=barney:fred
-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney: ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
env: relocation error: libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
egrep: relocation error: libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
LD_LIBRARY_PATH=barney
-bash-4.1$ sudo su - otheruser
-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney:fred ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
LD_LIBRARY_PATH=barney:fred
-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney: ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
LD_LIBRARY_PATH=barney:
-bash-4.1$ /usr/bin/ssh -x $(hostname) 'LD_LIBRARY_PATH=barney ; export LD_LIBRARY_PATH ; echo done ; env | egrep LD_'
done
LD_LIBRARY_PATH=barney

1 Ответ

0 голосов
/ 30 января 2020

Я танцевал с этим только три дня. (Должен заставить openmpi работать на моего пользователя.)

Из этого поста: https://comp.os.linux.development.apps.narkive.com/P7hTPwxP/must-ld-library-path-end-with-a Я обнаружил, что терминал ":" добавит ваш $ HOME в конец LD_LIBRARY_PATH. Это не то, что я знал (и у меня 35-летний профессиональный опыт работы с * системами NIX).

Я обнаружил копию lib c .so.6 в моем домашнем каталоге, который я там положил четыре месяца go по какой-то (вероятно, действительной в то время) причине или просто потому, что я был неуклюжим в тот день. Удалил lib c .so.6, и проблема исчезла.

Два решения: не ставьте суффикс LD_LIBRARY_PATH и НИКОГДА НЕ ОСТАВЛЯЙТЕ ЛЮБЫЕ ОБЩИЕ БИБЛИОТЕКИ В ВАШЕМ ГЛАВНОМ КАТАЛОГЕ КАЖДОЕ.

Четыре дня я никогда не вернусь.

Опыт - это то, что вы получаете, когда не получаете того, что хотели.

Сохранение смущения: вы не найдете ответа на свою глупость задавайте себе вопросы, пока не опубликуете это на stackoverflow.com.

...