Upstart: Каков первый отслеживаемый PID без ожидаемого, но со сценарием AND exec?

809
Thorsten Schöning

У меня есть несколько конфигов Upstart, которые используются для запуска некоторых передних планов и блокирования процессов в фоновом режиме как некие «демоны», особенно те процессы, которые ни в коем случае не ветвятся. Я хочу перезапустить их автоматически, если они выходят по неизвестной причине, поэтому я настроил их respawn, но поскольку эти процессы не выполняются, я не настраивал их expect. Казалось, это сработало, как и ожидалось, но недавно я кое-что изменил, а сегодня снова наткнулся на что-то в кулинарной книге Upstart, что заставило меня задуматься ...

Если вы не укажете ожидаемый раздел, Upstart будет отслеживать жизненный цикл первого PID, который он выполняет в разделах exec или script.

Я использую scriptраздел для создания classpath для моего «демона» и недавно добавил, что некоторые ожидают, когда Postgres и / или некоторые веб-приложения будут готовы и впоследствии выполнят мой процесс, используя его execв этом scriptразделе. Для ожидания я использую такие инструменты, как psи curl, потому что я забыл о «первой PID-вещи» и, похоже, перепутал Upstarts execс тем из оболочки, которая выполняет script.

Один пример конфигурации:

script waitForPostgres() { while [ true ] do # http://superuser.com/questions/597549/grep-fails-in-upstart-script if ps ax | grep "[p]ostgres: wal writer process" > /dev/null then break fi  sleep 10s done }  waitForPostgres  cd "$basePath"  CLASSPATH=$basePath/lib for i in `ls $basePath/lib/*.jar` do CLASSPATH=$CLASSPATH:$i done export CLASSPATH  exec java [...] end script

Материал waitForPostgresновый, и, насколько я понимаю, все остальное встроено в оболочку и без waitForPostgresпервого запуска и, следовательно, отслеживаемого процесса java. Но с моей дополнительной функцией я подозреваю, что Upstart отслеживает psвместо этого, и это, очевидно, не то, что я хочу.

Так, что PID отслеживается в этом примере, что из ps, grepили javaи почему?

И если не javaотслеживается, есть какие-нибудь идеи для обхода, чтобы отслеживать этот последний PID вместо первого?

Спасибо!

1

1 ответ на вопрос

0
Thorsten Schöning

I found the answer using some slightly different search terms: expect stop

Unfortunately, this means Upstart detects the first invocation of sed as the first PID

Additionally the answer for a workaround is nearby, pre-start, which is exactly designed for such purpose. Didn't thought about that, even though I've read it before in the docs...

I've found an interesting proposal as well: Possibility to tell explicitly what PID to track

Because of some problems with one of my services I had another look in how it behaves with Upstart and found the following: My "script" stanza is still calling binaries like "dirname", "readlink" and "ls", to not need to hard code some working dir, build some Java classpath and such. The important part is that those are no shell built-ins and therefore should be tracked by Upstart, because "readlink" is the first binary executed in "start". But this is not the case, those PIDs seem to be ignored and Upstart instead tracks the PID of the "exec java ..." command I really want to see tracked. I verified that by calling "service ... status" and comparing the output to "ps axf | grep ..." and both PIDs match. I can properly restart the service and the former found PID is removed and start the service and ps and service ... status report the same PID again.

Two possible explanations: Because "dirname" and Co. are used as command substitution, Upstart recognizes the created subshells by it's own created shell for the "script" stanza and ignores those PIDs by purpose. Else "exec" may return a PID which overrides any former recognized PID. I doubt the latter and think subshells are simply ignored, which is a very nice feature then.

Похожие вопросы