6. Операционные вопросы
В начало страницы
Эта глава посвящена некоторым рутинным операционным вопросам,
которые могут возникнуть перед администратором.
В начало страницы
Имеются три формы защиты в пакетной системе:
Внутренняя защита
Можно ли доверять демону?
Аутентификация
Как проверить, что клиент -- тот, за кого он себя выдает.
Санкционирование
Уполномочен ли клиент на выполнение запрошенных действий?
В начало страницы
Были приложены усилия к тому, чтобы различные демоны PBS не оказались
уязвимыми при атаках на систему. Две главные цели этих усилий составляют
защита файлов, используемых демонами и защита окружения демонов
Любой файл, используемый PBS, особенно файлы, которые определяют конфигурацию
или другие исполнительные программы, должны быть защищены. Файлы должны
принадлежать корню и в общем случае не доступны для записи никому кроме
корня. Когда устанавливаются каталоги PBS, make-процессы исполняют программы,
обеспечивающие собственность и соответствующий доступ к файлам. Это может быть
перепроверено в любой момент запуском check-tree на верхнем уровне make-файла.
check-tree помещается в каталоге, определяемом значением bindir в конфигурации.
Каждый демон также проверяет наиболее критичные файлы и каталоги при каждом
старте.
Испорченное окружение есть другой источник атак на систему. Чтобы предупредить
эту форму атак, каждый демон переустанавливает свое окружение при старте.
Источником для окружения служит файл с именем PBS_ENVIRON, устанавливаемый
параметром конфигурации --set-environ, определенным по умолчанию в
{PBS_HOME}/pbs_environment. Если он еще не существует, он создается во время
процесса установки. Построенный при установке, он будет содержать очень
важную PATH, а если находится в корневом окружении, то и переменные:
TZ, LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_NUMERIC и
LC_TIME. Его можно редактировать для включения других переменных, требуемых
в вашей системе. system. Заметьте пожалуйста, что PATH должна быть
включена. Это зачение PATH будет передаваться пакетным заданиям. Для
поддержания безопасности важно, чтобы PATH ограничивалась известными,
безопасными каталогами. Не включайте "." в PATH. Другая переменная,
которая может быть опасной и не должна
устанавливаться, есть IFS.
Синтаксис вхождения в файле PBS_ENVIRON есть или
variable_name=value
или
variable_name
В последнем случае значение для переменной получается из
окружения самого демона перед его перезапуском.
В начало страницы
PBS использует комбинацию информации для аутентификации хоста. Если запрос
поступил от клиента, чей разъем привязан к привилегированному порту (меньше
чем 1024, который требует корневой
привилегии), то PBS (правильно или ошибочно) полагает, что IP (Internet
Protocol) сетевой уровень и есть тот, которому принадлежит хост
Если запрос клиента пришел из непривилегированного порта , имя хоста,
сделавшего клиентский запрос, должно быть включено в удостоверение прав,
соответствующее запросу и должно соответствовать мнению сетевого уровня
IP об идентификации хоста.
В начало страницы
Доступ к pbs_server из другой системы может быть проконтролирован по
контрольному списку доступа (ACL). См. детали в разделе 10.1.1 ERS.
Доступ к pbs_mom контролируется по списку хостов, приведенному в его
конфигурационном файле. По умолчанию, допускаются только "localhost" и хосты
с именем, выдаваемым по gethostname(2). См. дополнительные сведения о
конфигурационном файле в man pages pbs_mom(8B). Доступ к pbs_sched ограничен
только тем, что должен быть из привилегированного порта.
В начало страницы
Есть ли пользователь тот, за кого он себя выдает?
Сервер проверяет имя, названное в запросе пользователем, по мандату,
имеющемуся в PBS. Этот мандат он получает по pbs_iff(1B), см. раздел 10.2
в ERS.
В начало страницы
Предоставлено ли пользователю с этим именем право запроса к Серверу заданий?
PBS, получив запрос, предполагает, что имя пославшего запрос пользователя
действительно в пределах в пределах множества систем, составляющих кластер PBS.
Так, если задание представлено от UserA@hostA, PBS позволяет снять или изменить
задание по UserA@hostB. Подпрограмма site_map_user() вызывается дважды.
Раз для проверки имени запрашивающего и второй раз для сверки имени хозяина задания
с именем на локальной системе Сервер. Если обе проверки прошли благополучно,
запросивший считается хозяином задания. См. раздел 10.1.3 в ERS.
Такое поведение на сайте можно изменить, изменив подпрограмму Сервера
ite_map_user(), находящуюся в файле src/server/site_map_user.c, см.
Internal Design Spec.
Имеет ли пользователь право выполнять задание под таким именем?
Пользователь может дать имя, под которым задание должно выполняться на
определенной системе. Если такое имя не задано, для исполнительного имени
избирается имя владельца задания. См. параметр -u в пользовательском списке
параметров команды qsub(1B). Право выполнять задание под избранным именем
гарантируется при следующих условиях:
1. Задание было представлено на локальный хост Сервера, и имя представившего
совпадает с избранным исполнительным именем.
2. Хост, с которого было представлено задание, объявлен исполнительным
хостом как заслуживающий доверия в файле /etc/hosts.equiv, или
представивший задание хост и имя представившего задание пользователя
указаны в исполнительном пользовательском файле .rhosts. Для проверки
таких отметок служит библиотечная функция системы ruserok().
Если названные условия не считаются достаточными для сайта, можно изменить
служебную подпрограмму site_check_user_map() в файле
src/server/site_check_u.c. См. IDS для получения дополнительной информации.
В дополнение к названным выше проверкам, доступ к Серверу PBS и очередям
Сервера может контролироваться контрольными списками доступа. Подробности см.
в разделах 10.1.1 и 10.1.2 of в ERS.
В начало страницы
PBS разрешает отдельным пользователям представлять задания, указывая
от какой группы это задание должно исполняться. Пользователь указывает
атрибут group_list для задания, который содержит список groups@hosts,
подобный списку пользователей. См. атрибут group_list с помощью
параметра -W в qsub(1B). Сервер PBS подтвердит, что пользователь является
членом указанной группы, посредством:
1. Проверит, не является ли группа первичной пользовательской группой
согласно строке пароля. Если так, то имя пользователя может не
фигурировать в групповом входе его первичной группы
2. Проверит наличие пользовательского имени в указанном групповом входе в
/etc/group.
Задание будет отвергнуто, если обе проверки потерпят неудачу. Проверки не
будут производиться, если пользователь не представит атрибут group list.
В этом случае будет использована первичная группа пользователя из файла
пароля.
При установке или возвращении файлов PBS также использует избранную
исполнительную группу для операций копирования. Это обеспечивает нормальную
для UNIX защиту доступа к файлам. Поскольку вся групповая информация
передается как цепочка символов, PBS не может определить, предназначена ли
цифровая цепочка служить групповым именем или GID.
Поэтому, когда список групп указывается пользователем, PBS помещает одно
требование на группы в пределах системы. Каждая и всякая группа, в которой
пользователь мог выполнять задание, должна иметь групповое имя и
соответствующий элемент в /etc/group. Если никакие групповые списки никогда
не использовались, PBS будет использовать группу login (регистрационную) и
будет принимать ее, даже если группа не указана в /etc/group.
Заметим, что в этом случае значение атрибута egroup есть цифровая цепочка,
представляющая пользовательский GID, а не групповое "name".
В начало страницы
Сервер отвергнет каждое задание для выполнения под пользовательским
идентификатором UID, равным нулю, если только владелец задания, обычно root на
его или другой системе, не числится в атрибуте сервера acl_roots.
В начало страницы
PBS обеспечивает возможность исполнять заданный сайтом сценарий перед и /или
после выполнения задания. Это позволяет выполнять инициализацию или очистку
ресурсов, таких как временные каталоги или рабочие файлы. Эти сценарии могут
использоваться для написания "шапок" выходных файлов заданий. Когда для
задания отводятся кратные узлы, эти сценарии выполняются только "Материнской
вершиной", pbs_mom на первом отведенном узле. Там же выполняется сценарий
оболочки задания.
Если сценарий пролога или эпилога отсутствует, Mom продолжает работу обычным
образом. Если присутствует, он выполняется с корневой привилегией.
Чтобы быть выполненным, сценарий должен придерживатья следующих правил:
- Сценарий должен располагаться в каталоге PBS_HOME/mom_priv под именем
prologue для сценария, выполняемого перед заданием, и под именем epilogue
для сценария, выполняемого после задания.
- Сценарием должен владеть root.
- Сценарий должен быть читаемым и исполнимым для root.
- Сценарий не может записываться никем кроме root.
Сценарий может быть сценарием оболочки или исполнимым объектным файлом.
Обычно оболочечный сценарий должен начинаться с строки вида: #! interpreter.
См. правила под execve(2) или exec(2) в вашей системе.
В начало страницы
При запуске пролог вызывается с следующими аргументами:
argv[1] идентификатор задания.
argv[2] имя пользователя, под которым выполняется задание.
argv[3] групповое имя, под которым выполняется задание.
Эпилог, кроме перечисленных выше аргументов, имеет дополнительно:
argv[4] имя задания .
argv[5] идентификатор сеанса.
argv[6] запрошенные пределы ресурсов (список).
argv[7] список использованных ресурсов.
argv[8] имя очереди, в которой расположено задание.
argv[9] строка учета, если таковая существует.
И для пролога и для эпилога:
envp означает окружение, передаваемое сценарию в очищенном виде.
cwd означает текущий рабочий каталог в начальном каталоге пользователя
input Если задан, оба сценария имеют стандартный вход с зависящим от
системы файлом. В настоящее время для всех систем этот файл есть
/dev/null.
output С одним исключением, стандартный выход и стандартный выход для
сообщений об ошибках сценариев привязаны к соответствующим файлам
задания. Если задание есть интерактивное задание PBS, стандартный
выход и ошибки эпилога направляются в /dev/null, потому что связь с
псевдотерминалом разрывается системой, когда задание заканчивается.
В начало страницы
Чтобы ошибочный сценарий или ошибка в пределах сценария не вызывали
задержек в работе PBS, Mom устанавливает аварийные сигналы при выполнении
сценария. Они устанавливаются на 30 секунд. Если сигнал прозвучит ранее
окончания сценария, Мом убивает сценарий. Время сигнала можно изменить, изменив
определение PBS_PROLOG_TIME в src/resmom/prolog.c.
В начало страницы
Нормально сценарий пролога должен оканчиваться с нулевым кодом возврата.
Mom регистрирует в своем журнале каждый случай ненулевого выхода из сценария.
Значения кода выхода и их воздействия на задание таковы:
-4 Сценарий перерасходовал время. Задание будет переставлено в очереди.
-3 Вызов wait(2) ожидает выход из сценария по ошибке. Задание будет
переставлено в очереди.
-2 Не открывается входной файл, который должен быть передан заданию. Задание
будет переставлено в очереди.
-1 Сценарий имеет ошибку допуска, он не принадлежит корню или может
записываться не только из корня. Задание будет переставлено в очереди.
0 Сценарий прошел успешно. Задание будет исполняться.
1 Сценарий закончился с кодом 1. Задание снимается.
>1 Сценарий закончился с кодом больше 1. Задание будет переставлено в
очереди
Все сказанное выше относится к обычным пакетным заданиям. Заметим, что
интерактивно-пакетные задания (параметр -I) не могут быть переставлены в
очереди при ненулевом статусе, связь по сети назад к qsub теряется и не
может быть переустановлена. Интерактивные задания снимаются при ненулевом
выходе из пролога.
Администратор должен проявлять величайшую осторожность при установке пролога,
чтобы предохранить задание от выбрасывания из системы. Ненулевые коды выхода из
эпилога регистрируются, но не влияют на статус задания.
В начало страницы
Система PBS стремится внести много в log-файл. Имеются два типа log-файлов:
журналы событий, в которые заносятся события, связанные с каждым из демонов
(pbs_server, pbs_mom и pbs_sched), и журнал отчета Сервера.
В начало страницы
Каждый из демонов PBS ведет log-файл событий. Детали формата записей
описаны в разделе 3.3.8. ,Запись событий, в ERS. Сервер (pbs_server),
Планировщик (pbs_sched) и Mom (pbs_mom) записывают свои события в файл с
именем, использующим текущую дату, в каталоге PBS_HOME/(daemon)_logs
Его место можно изменить по параметру "-L pathname"; имя пути должно
указывать абсолютный путь.
Если используется имя по умолчанию, без параметра -L, журнал будет
закрываться и переоткрываться ежедневно с текущей датой. Это происходит при
первом событии после полуночи. Если путь указан с параметром -L, то
автомавтических close/reopen не происходит. Все демоны будут закрывать и
переоткрывать свои файлы по получении SIGHUP. pid демона доступен в его
lock-файле в его начальном каталоге. Таким образом, можно присваивать
текущему log-файлу новое имя и посылать SIGHUP для перезапуска файла:
cd PBS_HOME/daemon_logs
mv current archive
kill -HUP `cat ../daemon_priv/daemon.lock`
Количество записей в журнал зависит от избранных событий для регистрации и
и присутствия отметок debug, задействованных при компиляции с параметром
-DDEBUG. Сервер и Mom могут быть настроены на запись только сообщений о
событиях определенных типов. Указанные типы соединяются логическими OR.
Десятичные значения типов такие:
1 События-ошибки
2 Batch System/Server события
4 Административные события
8 События заданий
16 Использование ресурсов заданиями (шестнадцатиричное значение 0x10)
32 Нарушения защиты (hex value 0x20)
64 Вызовы Планировщика (hex value 0x40)
128 Отладочные сообщения (hex value 0x80)
256 Дополнительные отладочные сообщения (hex value 0x100)
Включение всего есть 511. Обычно используется 127. Маска включения регистрации
событий по-разному проверяется для Сервера и Mom. Маска Сервера
устанавливается с помощью qmgr(1B), устанавливающей атрибут log_events. Это
можно сделать в любой момент. Маска Mom может быть установлена через
конфигурационный файл со строкой $logevent, см. параметр -c в
pbs_mom. Чтобы изменить его регистрационную маску, отредактируйте
конфигурационный файл и пошлите в Mom сигнал SIGHUP.
Планировщик, как записываемый на сайте, может иметь различные методы изменения
регистрационной маски своих событий, или вообще не иметь такой возможности.
В начало страницы
Демон Сервера PBS Server ведет бухгалтерский журнал. Его формат описан в
разделе 3.3.9, Бухгалтерия, в ERS. По умолчанию его ими есть
PBS_HOME/server_priv/accounting/yyyymmdd где yyyymmdd есть дата.
Бухгалтерия может быть размещена где угодно указанием в параметре -A в
командной строке для pbs_server. Аргумент параметра есть полное (абсолютное)
имя пути к файлу. If дана нулевая цепочка, например
pbs_server -A ""
то бухгалтерский журнал не будет открыт и никаких бухгалтерских записей
делаться не будет.
Бухгалтерский файл заменяется по тем же правилам, что и другие регистрационные
файлы. Если используется файл, назначенный по умолчанию с именем по дате,
он будет закрываться и новый файл открываться каждый день при первом событии
(записи в файл) после полуночи. И файл, названный по умолчанию, и файл,
названный с использованием параметра -A, Сервер будет закрывать и снова
открывать по сигналу SIGHUP. Это позволяет переименовывать старый файл
и начинать запись заново в чистый файл. Например, если текущая дата есть
9 Февраля, Сервер начнет запись в файл 19990209. Следующие действия приведут к
переименованию текущего бухгалтерского файла в feb1, Сервер закроет этот файл и
начнет писать новый 19990209:
mv 19990201 feb1
kill -HUP 1234 (the Server's pid)
В начало страницы
Альтернативные или пробные копии различных демонов могут исполняться
с помощью параметров командной строки, которые установят собственный начальный
каталог и служебный порт. Например, следующие команды запустят трех демонов с
начальным каталогом /tmp/altpbs и четырьмя портами вокруг 13001, Сервер на
13001, Mom на 13002 и 13003, и Планировщик на 13004:
pbs_server -t create -d /tmp/altpbs -p 13001 -M 13002 -R 13003 -S 13004
pbs_mom -d /tmp/altpbs -M 13002 -R 13003
pbs_sched -d /tmp/altpbs -S 13004 -r script_file
Начальные каталоги должны быть предварительно построены. Простейший метод
состоит в изменении переменной PBS_HOME использованием параметра
--set-server-home для конфигурации, выполнении конфигурации переделке
(remake) PBS.
Задания могут направляться в пробную систему использованием синтаксиса
server:port с параметром -q. Статус также получается использованием
:port syntax:
Например, чтобы поставить задание в очередь по умолчанию на упомянутом выше
пробном Сервере, запросите статус пробного Сервера и запросите статус заданий
на пробном Сервере:
qsub -q @host:13001 job
qstat -Bf host:13001
qstat @host:13001
Если вы или пользователи используете зависимости заданий на или между пробными
системами, имеются небольшие проблемы, которые вы (или пользователи) должны
знать. В синтаксисе обеих цепочек зависимости, depend_type:job_id:job_id и
job id seq_number.host:port, двоеточия используются неразличимым образом.
Способ, как с этим бороться, содержится в разделе Советы пользователю в конце
настоящего руководства.
В начало страницы
После того, как вы запустили пакетную систему, придет время, когда вы захотите
обновить ее или установить новую версию. Предположим, что вы хотите построить
и проверить новую версию, используя альтернативные каталоги и номера портов,
как описано выше. Вы можете изменить место PBS_HOME для пробной версии,
см. параметр конфигурации --set-server-home. Если вы будете удовлетворены
новой системой, предполагается, что вы перестроите трех демонов с PBS_HOME,
установленной в каталог, который будет использоваться при нормальных операциях.
В противном случае вы должны будете всегда употреблять параметр -d, запуская
демонов.
Когда новая пакетная система будет готова для передачи в эксплуатацию, вы
захотите передать задания из старой системы в новую. Для этого нужно выполнить
следующую процедуру. Все Серверы должны выполняться в режиме корня. Команды
qmgr и qmove должны выполняться пакетным администратором (конечно,
годится и корень)
1. При работающей старой пакетной системе выключите очереди и остановите
планирование, установив "scheduling=false".
2. Сдублируйте пул заданий в PBS_HOME(old)/server_priv/jobs.
Для этого можно использовать Tar.
Если изменения в системе невелики (поменялся третий знак в номере версии)
или произведены местные изменения и структура заданий не изменилась по
сравнению со старой версией,
то весьма вероятно, что вы можете запустить новую систему в старом HOME и
все задания будут восстановлены. Но если структура заданий должна меняться,
будет необходимо перенести задания из старой системы в новую.
Примечания к версии содержат предупреждения, если меняется структура заданий
или перенос требуется по другим причинам.
Для переноса заданий проделайте следующие действия:
3. Вероятно, что PBS_HOME будет изменен и должен быть приготовлен во время
проверки. Если нет, постройте (временно) дерево серверских каталогов
изменением PBS_HOME, используя --set-server-home and напечатав
"buildutils/pbs_mkdirs server"
в вершине объектного дерева.
4. Запустите новый Сервер PBS в его новом Home. Если новый Home отличается
от каталога, где он компилировался, используйте параметр -d option.
Используйте параметр -t , если Сервер не был конфигурирован для нового
каталога. Запустите его с другим портом, используя параметр -p.
Прекратите попытки планирования с параметром -a:
pbs_server -t create -d new_home -p 13001 -a false
Помните, что будет необходимо использовать синтаксис :port при командах
новому Серверу.
5. Дублируйте на новом сервере текущие очереди и атрибуты сервера (в
предположении, что вы хотите этого). Задействуйте каждую очередь, в
которую будут поступать задания от нового Сервера:
qmgr -c "print server" > /tmp/config
qmgr host:13001 < /tmp/config
qenable queue1@host:13001
qenable queue2@host:13001
6. Теперь рассмотрите все задания начального Сервера и передайте несколько из
них одно за другим новому Серверу:
qstat
qmove queue@host:13001 job
qstat @host:13001
Если все пройдет хорошо, передайте оставшиеся задания по одной очереди за
раз:
qmove queue1@host:13001 `qselect -qqueue1`
qstat queue1@host:13001
qmove queue2@host:13001 `qselect -qqueue2`
qstat queue2@host:13001
7. Теперь все задания должны находиться под контролем нового Сервера и
располагаться в новом Home Сервера. Если это временный каталог, закройте
новый Сервер и перенесите все в реальный Home, используя
cp -R new_home real_home
или, если реальный (новый) Home уже установлен,
cd new_home/server_priv/jobs
cp * real_home/server_priv/jobs
для копирования заданий.
Теперь вы готовы создать и эксплуатировать новую пакетную систему.
Вы должны знать об одном выверте при использовании qmove. Если вы хотите
перенести задание от Сервера, работающего на пробном порте, к Серверу,
работающему на нормальном порте (15001), вы, возможно,попробуете
употребить следующую команду:
qmove queue@host 123.job.host:13001
Однако, это переведет задание только в конец той очереди, в которой оно стоит.
Сервер, получая запрос на перенос (13001), будет сравнивать имя сервера
назначения, хост, только с его собственным именем, не включая порт. Вследствие
их совпадения задание не будет послано, куда вы хотели. Чтобы передать
задание Серверу, работающему на нормальном порте, нужно указать этот порт
назначения так:
qmove queue@host:15001 123.job.host:13001
В начало страницы
Далее следует очень неполный список конфликтов и способов их разрешения.
В начало страницы
Если команды клиента, qstat, qmgr, ..., не в состоянии установить связь с
Сервером, нужно проверить несколько вещей. Если выдается ошибка 15034,
"No server to connect to", проверьте :(1) действительно ли Сервер работает,
и (2) подразумеваемая информация для Сервера установлена правильно. Команды
клиентов пытаются связаться с Сервером, указанным в командной строке, а если
такого указания нет, то с Сервером, указанным в "default server file" во
время постройки и установки команд.
Если код возвращенной ошибки есть 15007 , "No permission", действуйте как в
пункте (2). Также проверьте, что выполняемый pbs_iff расположен на поисковом
пути клиента и что это есть setuid root. Дополнительно попробуйте запустить
pbs_iff, напечатав:
pbs_iff server_host 15001
Там, где server_host есть имя хоста, на котором работает Сервер и 15001 есть
порт, к которому Сервер прислушивается (если он построен с другим номером
порта, используйте этот номер вместо 15001), pbs_iff выдаст цепочку мусора и
закончится с кодом 0. Мусор представляет зашифрованный мандат, который
должен использовался в команде для представления клиента Серверу. Если
pbs_iff не напечатает мусор и/или закончится с ненулевым статусом, то это
значит, что Сервер не работает или был построен с другой системой шифровки,
чем pbs_iff.
В начало страницы
PBS Сервер определяет состояние узла (up или down), опросив Mom на его узле.
Состояние узлов может быть сообщено двумя командами, qmgr и pbsnodes:
Qmgr: list nodes @active или pbsnodes -a. Узел в PBS может быть отмечен
как "down" в одном или двух подсостояниях.
Если числится как
Node lensmen
state = down, state-unknown
properties = sparc, mine
ntype = cluster
то Сервер не имел контактов с Mom с момента запуска. Проверьте, работает ли
Mom на узле. Если Mom имеется и только что стартовал, могло оказаться, что
Сервер пытался опросить его до запуска. Он должен увидеть его во время
следующего цикла опроса в 10 минут. Если узел все еще отмечается как
"down, state-unknown" после 10+ минут, то или имя узла, указанное в файле
узлов Сервера, не соответствует настоящему сетевому имени хоста, или имеются
сетевые неполадки между хостом Сервера и этим узлом.
Если узел числится как
Node lensmen
state = down
properties = sparc, mine
ntype = cluster
то Сервер мог запросить (ping) Mom на узле в прошлом, но Mom тогда не
ответил. Сервер посылает "ping"-запрос от PBS каждому свободному узлу в
каждый опросный (ping) цикл, 10 минут. Если узел не подтвердит получение
ping до следующего цикла, Сервер отметит узел как down.
На IBM SP, узел может быть отмечен как down, если Mom на узле полагает, что
узел не связан с быстродействующим переключателем. Когда Сервер получает
подтверждение от Mom узла, узел опять отмечается как up (свободен).
В начало страницы
Если выход задания не может быть доставлен пользователю, он сохраняется в
специальном каталоге, PBS_HOME/undelivered, а пользователю посылается почтовое
сообщение. Обычные причины недоставки:
(1) Хост назначения не надежен и пользователь не имеет .rhost file.
(2) Указан неправильный путь.
(3) Каталог, указанный в назначении, закрыт для записи.
(4) Пользовательский .cshrc в хосте назначения генерирует выход при
выполнении.
(5) Каталог PBS spool на исполняющем хосте не имеет правильного допуска.
Этот каталог должен иметь режим 1777 (drwxrwxrwxt).
Все это полностью разъясняется в разделе 7.5 "Доставка выходных файлов " в
следующей главе.
В начало страницы
Если пользователь получает почтовое сообщение, содержащее идентификатор
задания и строку: "Задание не может быть исполнено", это значит, что задание
было отвергнуто Mom-ом, когда оно поступало на исполнение. Объяснение можно
найти в одном из двух мест: Регистрационный файл Mom или стандартный файл
ошибок задания пользователя.
Если вторая строка сообщения будет "Обратитесь за помощью к Администратору",
то это значит, что Mom отверг задание до установки файлов задания. Причина
записывается в регистрационный файл Mom'а. Обычные причины: плохой счет
пользователя/группы, файл checkpoint/restart (для Cray) или системная ошибка.
Если вторая строка сообщения "См. стандартный файл ошибок задания", то Mom
создал файл задания и дополнительные сообщения написаны туда. Обычно это
неправильный заказ ресурсов.
В начало страницы
В очень редких случаях PBS может оказаться в ситуации, когда задание
находится в состоянии исполнения, но не имеет активных процессов.
Это может случиться только, когда смерть оболочки задания побудит Mom
известить сервер, что задание окончилось и нужно начать обработку конца
задания. Тот факт, что это случается, хоть и редко, означает, что где-то в
PBS сидит bug (Ах, как надоело все это!)
Если создалась такая ситуация, PBS предлагает следующий выход. Используйте
команду qsig для посылки SIGNULL, сигнала 0 для задания. Если Mom заметит,
что никаких процессов нет, он переведет задание в состояние выхода.
В начало страницы
Если вы имеете пользователей, работающих на тестовой пакетной системе,
использующей альтернативный номер порта, параметр -p для pbs_server,
неприятность может произойти с зависимостью задания, если не соблюдены
следующие условия:
1. Для тестовой системы идентификатор задания в спецификации
зависимости должен включать по крайней мере первую часть имени хоста.
2. Двоеточие в спецификации номера порта должно быть предварено обратным
слешем. Это должно быть сделано и для Сервера и для его текущих разделов.
Например:
123.test_host\:17000
123.old_host@test_host\:17000
123.test_host\:17000@diff_test_host\:18000
В строке оболочки сам обратный слеш должен быть выделен (escaped) из оболочки,
так что предыдущие строки будут:
123.test_host\\:17000
123.old_host@test_host\\:17000
123.test_host\\:17000@diff_test_host\\:18000
Эти правила не документированы в qsub/qalter man pages, поскольку
это нужно немногим пользователям и такое включение в общий справочник могло бы
привести к недоразумениям.
В начало страницы
Пользователи стремятся узнать, что происходит с их заданиями. PBS имеет
специальный атрибут, comment, который доступен оператору, менеджеру или
или программе Планировщик. Этот атрибут можно установить в цепочку,
сообщающую информацию владельцу
задания. Он может использоваться для выдачи информации о том, почему задание не
исполняется или почему приостановлено. Пользователи в состоянии посмотреть
на этот атрибут, если он установлен, используя параметр -f команды qstat.
Программа Планировщик может установить атрибут comment с помощью
pbs_alterjob() API. Операторы и менеджеры могут употреблять параметр -W
в команде qalter, например:
qalter -W comment="некоторый текстt" job_id