☰

Die Jobumgebung ist auf SGE nicht richtig eingerichtet

tag-icon • tag-icon bash cluster
Die Jobumgebung ist auf SGE nicht richtig eingerichtet

Mir ist klar, dass dies möglicherweise schwer zu beantworten ist, wenn Sie nicht wissen, wie mein Cluster eingerichtet ist, aber ich versuche, Jobs (über SGE) an einen Cluster zu senden, aber die Umgebung ist nicht richtig eingerichtet und die Jobs schlagen fehl. Darüber hinaus gibt es zwei verschiedene Masterknoten, bei denen ich mich anmelden kann, um Jobs an denselben Cluster zu senden, und meine Skripte funktionieren auf einem, aber nicht auf dem anderen.

Dies sind die Computerinformationen für den Masterknoten, auf dem mein Skript funktioniert:

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

Auf der Maschine, auf der es nicht funktioniert:

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

Hier ist ein Testskript, das ich verwende:

#!/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

Hier ist die Ausgabe nach dem Ausführen von „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

Um die Verwirrung noch zu steigern: Wenn ich mich per SSH direkt bei diesen Jobknoten anmelde (Knoten 156 im obigen Beispiel), kann ich die Befehle „ls“ und „Hostname“ problemlos ausführen!

Ich habe mit den Cluster-Administratoren Kontakt aufgenommen und sie können mein Problem nicht reproduzieren (selbst wenn sie sich als ich anmelden). Wir haben zunächst getestet, ob das Problem behoben werden könnte, wenn wir ~/.bashrc und ~/.bash_profile auf die Standardeinstellungen setzen, aber das hat nicht funktioniert. Hier sind diese Dateien:

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

Irgendwelche Vorschläge?

Antwort1

Ich habe keine vollständige Lösung, da ich nichts über SGE weiß. Aber ich kann einen Teil des Problems erklären.

Auf dem Rechner, auf dem Ihr Skript ausgeführt wird, läuft eine alte Version des Betriebssystems. Dies ist nicht nur an der Versionsnummer des Kernels erkennbar, sondern auch daran, dass er seit einiger Zeit keine Sicherheitsupdates mehr erhalten hat. Insbesondere glaube ich, dass auf dem Rechner eine Version von Bash läuft, die anfällig ist fürNeuroseInsekt.

Bash (missbraucht) dieUmfeldum Funktionen zu übergeben. Normalerweise wird die Umgebung nur verwendet, um Daten in Form einer Reihe von Elementen der Form zu übergeben . Ältere Versionen von Bash fügen Elemente der Form hinzu , was unter bestimmten Umständen das Einfügen von Code durch die Definition einer Variable ermöglichte, die ein Skript niemals verwenden würde – dieNAME=VALUENAME=() {CODE}Shellshock-Bug. Durch die Fehlerbehebung wurde die Art und Weise geändert, wie Funktionen codiert werden .BASH_FUNC_NAME%%=() {CODE}

Offensichtlich lädt ein Teil Ihres Setups die Umgebung herunter und analysiert sie. Dies kann entweder ein Teil von SGE oder etwas Spezifisches für Ihr Setup sein. Ein plausibler Grund hierfür ist, die Umgebung zu speichern, in der ein Job übermittelt wurde, um den Job in derselben Umgebung auszuführen.

Irgendwo wird eine Funktion definiert , die modulein Bash aufgerufen wird, und exportiert sie. Der Code würde ungefähr so ​​aussehen:

module () {
  …
}
export -f module

Die Lösung besteht entweder darin, den Umgebungsparser auf etwas zu aktualisieren, das mit der neuen Bash-Kodierung zurechtkommt, oder das Exportieren von Funktionen zu beenden.

verwandte Informationen