Я подозреваю, что Попен тайм-аут, не говоря - PullRequest
Новая
       67

Я подозреваю, что Попен тайм-аут, не говоря

2 голосов
/ 28 июня 2011

У меня возникли некоторые трудности с моими сценариями. Цель состоит в том, чтобы запустить один или несколько контейнеров OpenVZ для выполнения некоторого теста. Эти тесты могут быть очень длинными (обычно около 3 часов).

Первый скрипт работает следующим образом, после сортировки члена очереди для запуска он делает:

subprocess.Popen(QUEUE_EXECUTER % queue['queue_id'], shell=True)

Где "QUEUE_EXECUTER% queue ['queue_id']" - полная команда для запуска. В сценарии queue_executer это происходит следующим образом: 

# Launching install
cmd = queue['cmd_install']
report_install = open(queue['report_install'], 'a')
process_install = subprocess.Popen(cmd, shell=True, stdout=report_install, stderr=subprocess.STDOUT)
process_install.wait()

# Launching test
logger.debug('Launching test')
report_test = open(queue['report_test'], 'a')
cmd = queue['cmd_test']
process_test = subprocess.Popen(cmd, shell=True, stdout=report_test, stderr=subprocess.STDOUT)
process_test.wait()

Это работает довольно хорошо, но некоторое время, а в последнее время, в большинстве случаев, выполнение останавливается. Нет ошибок в журналах или что-нибудь. Файл отчета показывает, что он остановился прямо в середине написания строки (что, как я полагаю, связано с тем, что файл неправильно закрыт на стороне Python). На стороне хоста убийца OOM, похоже, ничего не делает, и я просмотрел логи хоста, но ничего не нашел.

Два запущенных выше «cmd» - это сценарий оболочки, который в основном устанавливает vz и выполняет на нем тестовую программу.

Итак, мой большой вопрос: я что-то упустил, что заставило бы сценарии остановиться на стороне Python?

Спасибо.

РЕДАКТИРОВАТЬ: Некоторые дополнительные сведения.

Неудачная команда всегда является второй. Вот два примера значений команд, которые я пытаюсь выполнить: /path/vzspawncluster.sh /tmp/file web --tarball /services/pkgs/etch/releases/archive.tar.gz --create и /path/vzlaunch.sh 172 -b trunk --args "-a -v -s --time --cluster --sql=qa3 --queue=223 --html --mail=adress@mail.com"

Сценарий vzlaunch запускает скрипт python для контейнера OpenVZ с vzctl enter ID /path/script.py, где ID - это идентификатор контейнера, а /path/script.py - сценарий для контейнера.

Компьютер report_install и report_test - это файлы, расположенные на другом компьютере, доступ к которому осуществляется через общий ресурс NFS. Это не должно иметь значения, но, поскольку я действительно не знаю, что происходит, когда это терпит неудачу, я все равно отмечаю это.

Когда происходит сбой, процесс на контейнере умирает. Он не остается в каком-либо состоянии зомби или чего-либо еще, он просто мертв. Хотя процесс в контейнере завершается неудачно, основной процесс (тот, который запускает их все) продолжается, как будто все в порядке.

Дополнительная информация: Я попробовал подход очистки буфера , указанный smci, но запись моего файла журнала продолжала сокращаться прямо в середине строки: 

[18:55:27][Scripteo]       Create process '/QA/valideo.trunk/tests/756/test.py -i 10.1.11.122 --report --verbose --name 756 --...
[18:56:35][Scripteo]       Create process '/QA/valideo.trunk/tests/762/test.py -i 10.1.11.122 --report --verbose --name 762 --...
[18:57:56][Scripteo]       Create process '/QA/valideo.trunk/tests/764/test.py -i 10.1.11.122 --report --verbose --name 764 --...
[18:59:27][Scripteo]       Create process '/QA/valideo.trunk/tests/789/test.py -i 10.1.11.122 --report --verbose --name 789 --...
[19:00:44][Scripteo]       Create process '/QA/valideo.trunk/tests/866/test.py -i 10.1.11.122 --report --verbose --name 866 --...
[19:02:27][Scripteo]       Create process '/QA/valideo.trunk/tests/867/test.py -i 10.1.11.122 --report --verbose --name 867 --...
[19:04:13][Scripteo]       Create process '/QA/valideo.trunk/tests/874/t

1 Ответ

0 голосов
/ 15 июля 2011

Ваше намерение - сначала запустить process_install до его завершения, а затем запустить process_wait? (последовательно, а не многопроцессорность, верно?) Какую команду вы подозреваете в таймауте?

Пожалуйста, вставьте фактические значения queue['cmd_install'], queue['cmd_test']

(Есть ли у этих команд завершающий символ '&' или перенаправления?)

Вот мои предложения по отладке:

  • (я не знаю OpenVZ, но я предполагаю, что вы проверили журналы и позволяет ли он запускать команды при выходе)

  • Вы работаете в UNIX? Если это так, вы можете поиграть с командами для запуска cmd в фоновом режиме, а также запустить цикл для генерации вывода, например, некоторое время (1), чтобы дотронуться до файла дозорного, затем спать 10 секунд. Или вы могли бы cmd; touch donesentinel.

  • Попробуйте добавить цикл опроса для poll () каждого объекта Popen каждый интервал вместо wait ().

  • Либо распечатайте Popen.pid после его запуска, затем внешне проверьте или опросите, что процесс еще жив (например, в UNIX top -p).

  • Если ваш процесс генерирует вывод lotta, вы заметили предостережение в Popen.wait () ? Warning: This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.

  • Если вы подозреваете, что это происходит, перенаправьте либо / оба из stdout, stderr на os.devnull и посмотрите, отличаются ли ваши результаты. Или посмотрите этот подход очистки буфера .

...