☰

O ambiente de trabalho não está configurado corretamente no SGE

tag-icon • tag-icon bash cluster
O ambiente de trabalho não está configurado corretamente no SGE

Sei que pode ser difícil responder sem que você saiba como meu cluster está configurado, mas estou tentando enviar trabalhos (via SGE) para um cluster, mas o ambiente não está configurado corretamente e os trabalhos falham. Além disso, há dois nós mestres diferentes nos quais posso fazer login para enviar trabalhos para o mesmo cluster, e meus scripts funcionam em um e não no outro.

Estas são as informações da máquina para o nó mestre em que meu script funciona:

cat /proc/version 
Linux version 2.6.32-279.el6.x86_64 ([email protected]) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Wed Jun 13 18:24:36 EDT 2012

A máquina em que não funciona:

cat /proc/version
Linux version 3.10.0-514.6.2.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Thu Feb 23 03:04:39 UTC 2017

Aqui está um script de teste que estou usando:

#!/bin/bash -I
#$ -wd ~
#$ -N test
#$ -o ~/test.log
#$ -j y
#$ -terse
#$ -V
#$ -notify
#$ -l h_vmem=2G -pe smp 1 -l athena=true
ls
hostname
nproc

Aqui está o resultado após executar "qsub test.sh":

/bin/bash: module: line 1: syntax error: unexpected end of file
/bin/bash: error importing function definition for `BASH_FUNC_module'
/opt/sge/default/spool/execd/node156/job_scripts/1063646: line 11: ls: command not found
/opt/sge/default/spool/execd/node156/job_scripts/1063646: line 12: hostname: command not found

Para aumentar a confusão, quando faço ssh diretamente nesses nós de trabalho (node156 no exemplo acima), posso executar os comandos ls e hostname perfeitamente!

Entrei em contato com os administradores do cluster e eles não conseguem replicar meu problema (mesmo que façam login como eu). Testamos primeiro se definir ~/.bashrc e ~/.bash_profile com as configurações padrão resolveria o problema, mas isso não aconteceu. Aqui estão esses arquivos:

cat ~/.bashrc 
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

.bash_profile:

cat ~/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi


# User specific environment and startup programs

Alguma sugestão?

Responder1

Não tenho uma solução completa porque não sei nada sobre SGE. Mas posso explicar parte do problema.

A máquina onde seu script funciona está executando uma versão antiga do sistema operacional. Isso fica evidente não apenas pelo número da versão do kernel, mas também pelo fato de ele não receber atualizações de segurança há algum tempo. Especificamente, acho que está executando uma versão do bash vulnerável aoTrauma pós guerraerro.

Bash (ab) usa oambientepara passar funções. Normalmente o ambiente é utilizado apenas para passar dados, na forma de uma série de itens do formato . Versões mais antigas do bash adicionam itens no formato , o que em algumas circunstâncias permitia a injeção de código definindo uma variável que um script nunca usaria - oNAME=VALUENAME=() {CODE}erro de choque. A correção do bug mudou a forma como as funções são codificadas para .BASH_FUNC_NAME%%=() {CODE}

Evidentemente, alguma parte da sua configuração descarta o ambiente e o analisa. Isso pode fazer parte do SGE ou algo específico para sua configuração. Uma razão plausível para fazer isso é salvar o ambiente no qual um trabalho foi enviado, para executar o trabalho no mesmo ambiente.

Algo em algum lugar está definindo uma função chamada moduleno bash e exportando-a. O código seria algo como

module () {
  …
}
export -f module

A solução é atualizar o analisador de ambiente para algo que possa lidar com a nova codificação bash ou parar de exportar funções.

informação relacionada