Pourquoi le couple qsub ne crée-t-il pas de fichier de sortie?

Question

J'essaie tâche de démarrage sur le cluster via PBS Couple avec commande

qsub -o a.txt a.sh 

a.sh fichier contient chaîne unique:

hostname 

Après commande qsub je fais commande qstat, qui donnent la sortie suivante:

Job ID     Name    User   Time Use S Queue 
------------------------- ---------------- --------------- -------- - ----- 
302937.voms    a.sh    user   00:00:00 E long 

Après 5 secondes, la commande qstat renvoie la sortie vide (aucun travail dans la file d'attente). Commande

qsub --version 

donner sortie: Version: 2.5.13

Commande

which qsub 

Sortie:/usr/bin/qsub

Le problème est que le fichier a.txt (à partir de la commande qsub -o a.txt a.sh) n'est pas créé! Dans le terminal renvoyé uniquement ID de travail, il n'y a pas d'erreurs. La commande

qsub a.sh 

a le même comportement. Comment je peux le réparer? Où sont les fichiers journaux qsub avec des erreurs?

Si je commande

qsub -l nodes=node36:ppn=1 -o a.txt a.sh 

alors les fichiers de sortie que je peux trouver dans le dossier

/var/spool/pbs/undelivered 

sur node36 (après la connexion ssh dessus). Le fichier de sortie contient la chaîne "node36", le fichier d'erreur est vide. Pourquoi mes fichiers sont "non distribués"?

Answer 1

Les fichiers journaux de sortie et d'erreur sont conservés sur le noeud d'exécution dans un répertoire spoule et recopiés dans le noeud principal une fois le travail terminé. L'emplacement du répertoire de spoule peut varier. Mais vous devez rechercher sous /var/torque/spool sur le premier noeud de la liste des noeuds que le travail a été alloué.

Il existe plusieurs raisons pour lesquelles le couple risque de ne pas pouvoir fournir les fichiers de sortie.

1. L'utilisateur soumettant le travail peut ne pas exister sur le nœud ou leur répertoire personnel pourrait ne pas être accessibles, ou il y a un décalage d'ID utilisateur entre les nœuds du cluster. Le couple utilise ssh pour copier des fichiers sur le noeud principal, mais l'authentification par clé publique sans mot de passe pour l'utilisateur pour ssh sur le cluster n'a pas été configurée de manière cohérente sur tous les noeuds.
2. Un noeud a échoué lors de l'exécution du travail.

Cette liste n'est en aucun cas complète. Déjà ici sur Stack Overflow on peut trouver un certain nombre de questions traitant d'un tel échec. Essayez de vérifier si l'un des cas ci-dessus s'applique à votre cas.