Используя крутящий момент, если я запускаю задание с qsub с определенными аргументами, задание завершается и происходят три вещи. 1) Я получаю файл file.eXXXX, содержащий стандартный вывод процесса 2) Я получаю файл file.oXXXX, содержащий стандартный вывод процесса 3) Я получаю электронное письмо с такой информацией, как распределение и статус выхода.
Я хотел бы иметь эту информацию о статусе в файле рядом с файлами .oXXXX и .eXXXX, потому что слишком сложно сопоставить сотни электронных писем с сотнями выходных файлов задания, особенно несколько дней спустя. Я не могу найти такую встроенную возможность. Тем не менее, я заметил, что могу использовать «qstat -f job-id», чтобы получить информацию, очень похожую на ту, что находится в электронном письме. Но я не вижу в документации, как долго мне разрешена задержка для запуска qstat.
Я думал о том, что после запуска задания A с помощью qsub после этого используйте идентификатор задания для запуска зависимого задания B (qsub -W depend=...), которое будет запускать «qstat -f» идентификатора A, сообщая id-A через переменную окружения. Однако я не знаю, как далеко в будущем продлится задание B. Кроме того, если задание B выполняется не на том же узле, что и A, сможет ли qstat найти правильную информацию?
Моя идея кажется запутанной. Нет ли более простого/лучшего способа сделать это?
Я не думаю, что это можно сделать, установив какой-то монитор электронной почты, потому что я читаю свою электронную почту на совершенно другой машине, у которой нет доступа к вычислительному кластеру.
echo Success
в конец сценария задания и проверить наличие этой строки в файле.oXXXXXX
. - person Dmitri Chubarov   schedule 31.03.2018qstat -f
уже содержат информацию в параметрахresources_used
. Вполне вероятно, что что-то вродеqstat -f $PBS_JOBID | grep resources_used
должно работать при выполнении в качестве последней строки сценария задания. - person Dmitri Chubarov   schedule 03.04.2018