Как предотвратить повторный запуск cron-скрипта в Linux

Epsiloncool, 391 просмотр

Имеется долгоработающий скрипт, который запускается от cron'а. Если этот скрипт находит много данных, то он уходит в вычисления на довольно длительный период. Это его нормальное состояние, главное тут - не запустить вторую копию этого же скрипта (которая в нормальном состоянии обязательно запустится при следующем старте cron'а), то есть, проверить наличие работающего скрипта и если он уже есть, тупо завершать выполнение второй копии.

Нужно придумать fail-safe версию, то есть, чтобы не получилось такого, что где-то после перезагрузки или сбоя висит флаг, который не даёт запускать скрипт даже при отсутствии уже работающего скрипта.

Интересно именно Linux-style решение этой проблемы.

Примечание:
В способах решений со всякими lock- и pid- файлами мне непонятно одно: как обеспечивается защита от сбоя? А именно - если скрипт, установивший lock/pid, вдруг внезапно завершится, не удалив этот lock/pid, то как нам догадаться, что скрипт-таки завершился, а не ещё работает?

Примечание:
NetRain, спасибо, я попробую организовать такую проверку через pid и процессы :) Вообще у меня была другая идея - открывать сокет на listen по определённому порту, как известно, два сокета на одном и том же порту открыть не удастся. Но твоя идея с pid мне нравится, поскольку не содержит привязки к сети.

Ответы:

для последующего сравнения

Я бы модифицировал скрипт таким образом, чтобы при загрузке он проверял наличие копии процесса.
Но можно на bash'е написать скрипт-загрузчик, который:
1. Дернет ps и поищет там уже запущенный процесс (по команде запуска или по считанному из файла заранее сохраненному pid процесса)
2. Если процесс нашелся, завершает bash-скрипт
3. Если процесса нет, запускаем новый, возможно, запомнив его pid где-нибудь (в файле, например) для последующих проверок на шаге 1 наличия такого процесса.

NC1

Мне кажется, проблема неверно сформулирована. "Linux-style решение" -- это когда проблема просто не возникает. То есть сам скрипт будет достаточно умным, чтобы не запускаться "в два ствола". Например, скрипт исполняет команду top и ищет себя в данных, которые она возвращает. Если находит больше одного упоминания о себе, любимом, завершает работу. Если находит ровно одно -- делает то, что нужно сделать.

index0h

.lock файл.

для последующего сравнения

> Прим. 1
Создаем pid-файл при запуске скрипта. В pid-файле ессно хранится сам pid.
В случае сбоя и необходимости перезапуска (и при повторном запуске по cron'у) — смотрим, есть ли файл (если нет — значит все ок). Если файл есть, читаем pid оттуда и смотрим, есть ли процесс с таким pid'ом сейчас (для этого подойдет вывод ps, например). Если такого процесса нет — все ок, запускаемся и работаем. Если есть — можно завершаться, но на всякий случай надо посмотреть, какой командой он запущен (опять же ps нам скажет). Если команда похожа на нашу и содержит имя нашего скрипта — это наш скрипт. Остается проверить статус этого процесса — если T или Z, значит процесс сам завершается (и мы можем работать) или процесс завис (его можно убить) соответственно — в этом случае можно продолжать работу и переходить к исполнению логики нашего скрипта.

10 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.