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

Question

Sei que isso pode ser difícil de responder sem que você saiba como meu cluster está configurado, mas estou tentando enviar tarefas (via SGE) para um cluster, mas o ambiente não está configurado corretamente e as tarefas falharam. 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 enquanto não no outro.

A é a informação da máquina para o nó mestre em que o 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 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á a saída depois de 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 eu ssh diretamente nos nós do job (node156 no exemplo acima) eu posso executar os comandos ls e hostname bem!

Estou em contato com os administradores do cluster e eles não conseguem replicar meu problema (mesmo se fizerem login como eu). Primeiro, testamos que se definir ~ / .bashrc e ~ / .bash_profile para as configurações padrão, isso seria corrigido, 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?

    

Answer 1

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

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

O Bash (ab) usa o ambiente para passar funções. Normalmente, o ambiente é usado apenas para transmitir dados, na forma de uma série de itens no formato NAME=VALUE . Versões mais antigas do bash adicionam itens do formulário NAME=() {CODE} , que em algumas circunstâncias permitiam injetar código definindo uma variável que um script nunca usaria - o bug do shellshock . A correção para o bug mudou a maneira como as funções são codificadas para BASH_FUNC_NAME%%=() {CODE} .

Evidentemente, alguma parte da sua configuração despeja o ambiente e analisa-o. Isso pode ser uma 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 module no bash e exportando-a. O código seria algo como

module () {
  …
}
export -f module

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