Résolution de problèmes SIGTERM avec un tee sur un cluster dans des travaux SGE

J'ai un code scientifique hérité qui s'exécute sur un cluster Rocks avec SGE. J'ai un script de soumission de travail spécifique à l'application qui génère des scripts qsub (c'est-à-dire le script que Sun Grid Engine prend et exécute).Résolution de problèmes SIGTERM avec un tee sur un cluster dans des travaux SGE

Dans le script qsub, mon application héritée est appelée. Cette application envoie sa sortie à STDOUT. SGE intercepte STDOUT et le spoule dans un fichier dans le répertoire de base des utilisateurs, afin que l'utilisateur puisse voir les résultats s'accumuler en temps réel. Je veux que ce comportement soit maintenu, mais en même temps, je veux enregistrer de manière transparente toutes les sorties en arrière-plan. Je pensais que tee serait parfait pour y parvenir. J'ai donc modifié le script de soumission de travail pour exécuter l'app et le tube STDOUT à tee, qui enregistre STDOUT dans un fichier qui est copié dans un magasin central une fois le travail terminé. L'application est géré et canalisé au tertre comme suit:

\$GMSCOMMAND | tee \$SCRATCHDIR/gamess_output.log

Le problème est, depuis que j'ai commencé la tuyauterie du code à tee, l'application a été en train de mourir avec SIGTERMs, surtout quand je demande plusieurs noeuds. J'ai essayé d'utiliser le paramètre -i (ignore les interruptions) avec tee: cela ne fait aucune différence. Les choses fonctionnent bien si je redirige la sortie de l'application vers un fichier puis chat le fichier une fois l'application terminée, mais je ne peux pas permettre aux utilisateurs de voir l'accumulation des résultats en temps réel (ce qui est une exigence importante).

Des idées sur les raisons pour lesquelles cette utilisation de té pourrait échouer? Ou alternativement, des idées sur la façon dont je pourrais réaliser la fonctionnalité souhaitée?

Source

2009-11-23 tramdas

Pourriez-vous essayer de remplacer la commande 'tee' par' cat' - pour voir si c'est le tuyau qui pose problème? –

Etes-vous sûr que c'est SIGTERM, et non SIGPIPE? Essayez de mettre strace -o tr.gms. $ SGE_JOBID pour suivre les appels système et les signaux. Peut-être tracer à la fois $ GMSCOMMAND et tee. –

Je ne sais pas pourquoi votre cas particulier échoue, mais une option pourrait être de faire $GMSCOMMAND sa propre journalisation. (Mettre effectivement le tee dans l'application). Je suppose que cette option dépend du coût de la modification de l'application existante. A défaut, vous pourriez envelopper l'application 'legacy' avec votre propre script/application pour effectuer la redirection/duplication.

Source

2009-11-23 11:01:18

Merci Douglas, cela aurait été une bonne idée si j'étais autorisé à modifier l'application héritée, mais par politique, je ne peux pas le faire. – tramdas

Ok, pourriez-vous essayer de remplacer la commande 'tee' par' cat' - pour voir si c'est le tuyau qui pose problème? –

En effet, '| cat' échoue de la même manière '| té fait, donc il semble que le tuyau est le problème. En gardant cela à l'esprit, je commence à m'interroger sur l'exécution de '$ GMSCOMMAND> $ outputfile' détaché, puis sur la sortie de $ outputfile vers STDOUT jusqu'à EOF. Mais avant d'essayer cela, j'ai vraiment besoin de regarder correctement la documentation de Sun Grid Engine pour voir s'il y a des informations de paramétrage pertinentes. Merci pour votre aide jusqu'ici, si vous avez d'autres idées, je suis tout ouïe ... – tramdas

Si les tuyaux sont votre problème, vous pouvez peut-être contourner ce problème en utilisant une boucle 'while/read' avec substitution de processus. Est-ce que ça marche pour toi?

while read line; do 
    echo "$line" 
    echo "$line" >> ${SCRATCHDIR}/gamess_output.log 
done <(${GMSCOMMAND})

Source

2009-12-16 11:20:49 SiegeX

Résolution de problèmes SIGTERM avec un tee sur un cluster dans des travaux SGE

Répondre

Questions connexes