Сначала попробуйте более простой сценарий, например, только 2 процесса FOO1
и FOO2
, и если бы вы запустили внутри сценария, например, с именем parent.sh
:
#!/bin/bash
FOO1 &
pid1=$!
echo "Child PID=$pid1 launched"
FOO2 &
pid2=$!
echo "Child PID=$pid2 launched"
BAR exit FOO1
BAR exit FOO2
echo "Pausing to wait for children to finish..."
wait $pid1
wait $pid2
echo "Children finished, moving on."
Посмотрите, работает ли это с двумя FOO
s, и если да, то реализуйте для 20.
Поскольку мы не можем видеть внутреннее устройство FOO
s и BAR
процесса, я полагаюсь только на то, что вы опубликовали, и, как я понимаю, вы сказали
FOO1
каким-то образом, чтобы BAR exit FOO1
повлиял на негоСреди вашего первоначально опубликованного сниппета, вы также написали:
BAR exit FOO1
PID1=$!
$!
захватывает самый последний процесс, находящийся в фоновом режимеBAR exit FOO1
не является процессом, уходящим в фон, это, как вы утверждаете, средство использования BAR для управления FOO: "BAR используется для проверки FOO, а также используется для его убийства"$!
вряд ли будет перехватывать pid FOO1
Поэтому вместо этого убедитесь, что прямо там, где вы действительно запускаете процесс FOO
*, вы перехватываете pid. Например, если вы запускаете все в parent. sh
, и у вас только 2 процесса, вы сделаете следующее:
#!/bin/sh
FOO1 &
pid1=$!
echo "Child PID=$pid1 launched"
FOO2 &
pid2=$!
echo "Child PID=$pid2 launched"
pid1
, вы можете использовать и прописные буквы, лишь бы они были последовательными, я предпочитаю использовать строчные буквы, чтобы не перепутать их с переменными окружения#
или удалите его, как только решите проблемуЗатем мы выполняем команды, которые, как вы утверждали, вы используете для проверки и убиваем FOO1
и FOO2
:
BAR exit FOO1
BAR exit FOO2
Затем,
echo "Pausing to wait for children to finish..."
wait $pid1
wait $pid2
echo "Children finished, moving on."
echo
- необязательные, но информативные, пока вы все еще устраняете неполадки, позволяющие нам знать, что происходитwait
для каждого отдельного $pid
. .. echo
, чтобы сообщить, что ожидание
закончилосьShotts 2009 пример асинхронных скриптов на странице 506 бесплатного pdf
Макросы RPM имеют ассоциированный уровень, который является глубиной рекурсии.
При возврате из рекурсивного расширения макросы на этом уровне автоматически становятся неопределенными.
Макросы с уровнем <= 0 всегда определены (в некотором смысле глобальны).
Отрицательные значения уровней изначально использовались для того, чтобы отметить, где макросы были определены: из внутреннего rpm или из чтения конфигурационного файла.
На практике ничто в RPM никогда не использовало и не нуждалось в макроуровне.
Но именно это и означает "-14".
А также изменение ":" на "=" в выводе --showrc, которое говорит о том, какие макросы были определены или использованы.
Лучшая информация, которую я смог найти, просмотрев исходный код здесь , заключается в том, что% dump просматривает все макросы и печатает их с помощью rpmDumpMacroTable
From MacroEntry
struct , Печатается член уровня
. Согласно определению здесь - это «уровень охвата» (вероятно, это связано с вложенностью макросов, но я просто размышляю)
Я бы подождал, пока другие с глубокими знаниями ответят / предоставят дополнительную информацию, так как документации не так много
Я спросил в списке рассылки rpm-экосистемы. См .: http://lists.rpm.org/pipermail/rpm-ecosystem/2017-March/000476.html
В случае "rpm --showrc" такое отрицательное число представляет "источник" или "расположение" определения макроса:
-14 = -13 - 1: макрос определен в файле макроса (например, /etc/rpm/macros.*)
-11: макрос определен в файле rpmrc (например, / usr / lib / rpm / rpmrc)
-8 = -7 - 1: макрос определен в командной строке (например, через rpm -D "zzz 42" --showrc)
и т. д.