1

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

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

Я использую раздел script для создания classpath для моего "демона" и недавно добавил, что некоторые ожидают, пока Postgres и / или некоторые веб-приложения будут готовы и впоследствии выполнят мой процесс, используя exec в этом разделе script . Для ожидания я использовать такие инструменты , как ps и curl потому что я забыл про "первого PID вещь" и , кажется, путают выскочка 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

Я нашел ответ, используя несколько разные условия поиска: expect stop

К сожалению, это означает, что Upstart обнаруживает первый вызов sed в качестве первого PID

Кроме того, ответ для обходного пути находится поблизости, pre-start , который специально предназначен для этой цели. Не думал об этом, хотя я читал это раньше в документах ...

Я также нашел интересное предложение: возможность явно указать, какой PID отслеживать

Из-за некоторых проблем с одним из моих сервисов я по-другому посмотрел, как он работает с Upstart, и обнаружил следующее: мой раздел "script" все еще вызывает двоичные файлы, такие как "dirname", "readlink" и "ls", чтобы не нуждаться в жесткий код, какой-то рабочий каталог, сборка Java-пути к классам и тому подобное. Важным моментом является то, что они не являются встроенными модулями оболочки и поэтому должны отслеживаться программой Upstart, поскольку readlink - это первый двоичный файл, выполняемый при запуске. Но это не тот случай, эти PID, кажется, игнорируются, и Upstart вместо этого отслеживает PID команды "exec java ...", которую я действительно хочу видеть отслеженной. Я проверил это, вызвав «service ... status» и сравнив выходные данные с «ps axf | grep ...», и оба PID совпадают. Я могу правильно перезапустить службу, и ранее найденный PID будет удален и запустить службу, а ps и service ... сообщат о состоянии того же PID снова.

Два возможных объяснения: поскольку "dirname" и Co. используются в качестве подстановки команд, Upstart распознает созданные субоболочки собственной созданной оболочкой для раздела "script" и игнорирует эти PID по назначению. В противном случае exec может вернуть PID, который переопределяет любой ранее распознанный PID. Я сомневаюсь в последнем и думаю, что подоболочки просто игнорируются, что является очень хорошей особенностью.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .