Как установить специфичную для USIF переменную "GLIBC" в файле модуля?

Question

Я работаю в кластере высокопроизводительных вычислений на основе slurm, и делаю это последние 5 лет. Мы загружаем и выгружаем модули, необходимые для нашего анализа, среди которых такие компиляторы, как gcc. У меня это работало без проблем еще два дня назад. В течение последних двух дней каждый раз, когда я пытаюсь загрузить какой-либо модуль, я получаю такую ​​ошибку:

Couldn't set USIF specific variable "GLIBC" in modulefile - please contact
 system administration! (Refer to UMEA register_USIF.sh utility.)

Интернет не помог, поскольку, похоже, ничего по этому поводу уже не спрашивали / не решали. Системный администратор в настоящее время не отвечает на мою почту, поэтому моя работа полностью остановлена ​​из-за этого.

Я пробовал монтировать / размонтировать модули с другого компьютера и другой учетной записи, и все работает нормально, поэтому проблема связана с моей учетной записью.

Есть ли у кого-нибудь здесь опыт работы с этой проблемой? Если да, то с чего это могло начаться? Я даже не знаю, с чего начать и чем это могло быть вызвано, поскольку мы не устанавливаем собственные компиляторы.

Редактировать #1:

Для чего это стоит (не уверен) мой $LD_LIBRARY_PATH выглядит так:

LD_LIBRARY_PATH=:/cm/shared/apps/slurm/current/lib:/cm/shared/apps/slurm/current/lib/slurm

Я немного подозреваю это :в начале. Не хватает первого компонента? Я не трогал эту переменную.

Редактировать #2:

После некоторого другого рытья и сравнения моей среды с окружающей средой моего коллеги, у которого нет проблем с этим, я обнаружил, что следующие три переменные отсутствуют в моем env:

UMEA_HOME=/opt/sw/UMEA/current
UMEA_INCLUDE=/opt/sw/UMEA/current/include
UMEA_CONFIG=/opt/sw/UMEA/current/config

И еще я узнал, что $CPATH начинается с : словно $LD_LIBRARY_PATH, а его $CPATH не делает:

CPATH=:/cm/shared/apps/slurm/current/include

Я попытался export ...им, но это не помогло. Однако это заставляет меня думать, что существует более глубокая проблема.

Редактировать #3:

Как просили ниже в комментариях, я сделал module show gcc/5.3чтобы увидеть фактический файл модуля. Вот содержание:

#%Module######################################################################
##

source $env(UMEA_INCLUDE)/vsc_include.tcl
source $env(UMEA_INCLUDE)/common_include.tcl
source $env(UMEA_INCLUDE)/prereq_include.tcl

set verbosity 0
set_versions 
set base_path  [ load_unload ]
set_paths $base_path $module_name
set_version_number 2

setenv CC gcc
setenv CXX g++
setenv FC gfortran
setenv F77 gfortran
setenv F90 f95
setenv GDB gdb
setenv VSC_COMPILER_NAME ${module_name}
setenv VSC_COMPILER_VERSION ${module_version}

Answer 1

Вместе с системным администратором кластера HPC мы ее решили. Это было действительно глупо, и я отправляю ответ только для того, чтобы кто-то другой, у кого есть такая же проблема, знал, где искать, не теряя дней проб и ошибок.

Проблема проистекает из $PATH. Хотя в некоторых случаях вы можете захотеть обновить $PATH переменная путем выполнения PATH=/my/extra/path/directory:${PATH}, в этом случае мне пришлось поставить дополнительные пути в конце, как в PATH=${PATH}:/my/extra/path/directory.

До двух дней назад это не было проблемой, пять лет все работало нормально. Возможно, они что-то изменили на стороне сисадмина, так что нужный исполняемый файл больше не был найден в моем $PATH.

Я проверил, и я единственный из моих коллег, у кого есть модифицированный $PATH в .bashrc. Это объясняет, почему проблема возникла только у меня.

В любом случае, если вы читаете это и столкнулись с той же проблемой, вы знаете, где искать.