Я запускаю сценарий Python, который я создал, используя start-stop-daemon. Он отлично работает во всех случаях, кроме тех случаев, когда я забыл, что уже запустил. Он создает новый процесс, но не может автоматически убить старые процессы.
Вот полный сценарий:
PYTHONPATH=/usr/lib/python2.4
# path to app
APP_PATH=/var/spool/EARS
# path to paster bin
DAEMON=/var/spool/EARS/pymilter_test8.py
# startup args
#DAEMON_OPTS=" serve --log-file <my logfile> --server-name=main production.ini"
# script name
NAME=EARS_milter.sh
# app name
DESC='EARS_milter'
# pylons user
RUN_AS=postfix
PID_FILE=/var/run/milter.pid
############### END EDIT ME ##################
test -x $DAEMON || exit 0
set -e
case "$1" in
start)
echo -n "Starting $DESC: "
start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --make-pidfile --exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
start-stop-daemon --stop --pidfile $PID_FILE
echo "$NAME."
;;
restart|force-reload)
echo -n "Restarting $DESC: "
start-stop-daemon --stop --pidfile $PID_FILE
sleep 1
start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --make-pidfile --exec $DAEMON -- $DAEMON_OPTS
echo "$NAME."
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
Есть ли способ проверить это? Я пробовал переключатель -S пока безуспешно.
Спасибо.
Недавно у меня возникла проблема, когда я запускал сервер базы данных (Crate), используя start-stop-daemon. База данных была запущена с bash сценарий, который затем запустился java в отдельном процессе. Это было проблемой, потому что реальный сервер всегда указывался под вторым PID. Когда я заставил сам сервер создать файл PID, я обнаружил, что start-stop-daemon все равно не распознал бы, что сервер уже работал, когда я использовал --pidfile аргумент. Однако когда я использовал --startas вместо того --exec для стартового звонка это, казалось, решило проблемы для меня и start-stop-daemon снова смог правильно управлять серверным процессом.
Вы должны убедиться, что, по крайней мере, файл PID верен, поскольку сервер разветвления, как и я, будет использовать другой рабочий PID, чем у процесса, который его запускает. Пока вы отлаживаете, используя -t флаг полезен, так как вы можете вручную запустить start-stop-daemon команды в каждом случае и следить за тем, что он будет делать.
$PID_FILE будет содержать идентификатор процесса только последнего запущенного экземпляра, поэтому будет убит только этот экземпляр.
Что-то, что вы могли бы сделать, чтобы решить эту проблему, - это grep PID запущенных экземпляров вашего демона и завершить их, используя kill.
... или просто проверьте, есть ли другой запущенный экземпляр вашего скрипта, прежде чем вызывать start-stop-daemon.
Создается и запускается интерпретатор Python, но start-stop-daemon проверяет наличие процесса с именем pymilter_test8.py и явно не могу найти.
Вы можете использовать файл блокировки в /var/lock. Попросите демона проверить файл блокировки перед его запуском и вывести из строя ошибку, если файл блокировки существует. Если это не произойдет, он создаст файл блокировки. Таким образом, два экземпляра не могут работать одновременно.
Единственная проблема заключается в том, что если он выйдет из строя, не имея возможности навести порядок, вам придется вручную удалить файл блокировки. Не большая проблема. Местоположение файла блокировки должно быть в сообщении об ошибке, создаваемом, когда он не запускается.
В начальном случае вы бы поместили что-то вроде этого:
if [ -f /var/lock/filename.lck ]; then
echo "Lock file already present at /var/lock/filename.lck. Aborting"
exit 1
else
touch /var/lock/filename.lck
fi
А затем в случае остановки примерно так:
if [ -f /var/lock/filename.lck ]; then
rm /var/lock/filename.lck
fi
Это включает в себя редактирование, выходящее за рамки обычного раздела редактирования конфигурации, но оно должно работать.