Что на самом деле возвращает PS?(Разные значения в зависимости от того, как это называется) - PullRequest
1 голос
/ 04 июня 2019

У меня есть скрипт, содержащий этот фрагмент:

#!/bin/bash
set +e
if [ -O "myprog.pid" ]; then
    PID=`/bin/cat myprog.pid`
    if /bin/ps -p ${PID}; then
      echo "Already running" >> myprog.log
      exit 0
    else
      echo "Old pidfile found" >> myprog.log
    fi
else
    echo "No pidfile found" >> myprog.log
fi
echo $$ > myprog.pid

Этот файл вызывается сторожевым скриптом callmyprog, который выглядит следующим образом:

#!/bin/bash
myprog &

Кажется, проблема с if /bin/ps -p ${PID}. Проблема проявляется таким образом. Если я вручную вызываю myprog, когда он работает, я получаю сообщение «Уже запущен», как и должно быть. То же самое происходит, когда я вручную запускаю скрипт callmyprog. Но когда сторожевой таймер запускает его, я вместо этого получаю "Старый pidfile найден".

Я проверил вывод ps, и во всех случаях он находит процесс. Когда я вызываю myprog вручную - либо напрямую, либо через callmyprog, я получаю код возврата 0, но когда сторожевой таймер вызывает его, я получаю код возврата 1. Я добавил отладочные распечатки в приведенные выше фрагменты для печати в основном все, но я действительно не вижу, в чем проблема. Во всех случаях это выглядит примерно так в журнале, когда из скрипта запускается команда ps:

$ ps -p 1
  PID TTY          TIME CMD
    1 ?        01:06:36 systemd

Единственная разница в том, что возвращаемое значение отличается. Я проверил код выхода с кодом, подобным этому:

/bin/ps -p ${PID}
echo $? >> myprog.log

Что может быть причиной здесь? Почему код возврата зависит от того, как я вызываю скрипт? Я пытался скачать исходный код для ps, но мне было сложно понять.

Мне удалось "решить" проблему с помощью некрасивого хака. Я набрал ps -p $PID | wc -l и проверил, что количество строк было не менее 2, но это похоже на уродливый взлом, и я действительно хочу понять, в чем здесь проблема.

Ответ на комментарий ниже:

Оригинальный скрипт содержит абсолютные пути, поэтому это не проблема каталога. Для ps псевдоним отсутствует. which ps дает /bin/ps. Сценарии выполняются от имени пользователя root, поэтому я не вижу, как это может быть проблемой с правами доступа.

...