Mixailo28 фев 2011 в 09:48

Простая защита от двойного запуска заданий cron

2 мин

26K

Настройка Linux *

+39

Комментарии 71

Sliver 28 фев 2011 в 09:52

man 1 flock
функций даже побольше, есть в стандартных конфигурациях в линуксе

Mixailo 28 фев 2011 в 10:00

Прекрасно, а дальше что? Самому еще раз написать эту утилиту? Она как раз флок и использует.

blabla 28 фев 2011 в 10:13

flock(1) это и есть утилита.

Mixailo 28 фев 2011 в 10:22

И правда.

Harkonnen 1 мар 2011 в 16:06

PHP вариант:

Harkonnen 1 мар 2011 в 16:08

// Сохранение в $lock_file обязательно, иначе handle помрёт и файл автоматом закроется
if(!flock($lock_file = fopen("my_script.lock", 'w'), LOCK_EX | LOCK_NB))
  die("Already runninng\n");

Mixailo 1 мар 2011 в 17:54

А вот за это спасибо: замены для lockrun меня лично не особо интересуют, а для скриптов идея хороша. Возьму на заметку.

netp 31 мар 2011 в 19:16

Огромное спасибо! Очень помогло!

Urevic 28 фев 2011 в 21:06

Ого, а я как дурак для этого скрипт на шелле использовал, вот такой: code.reddit.com/browser/scripts/saferun.sh

Я туда правда добавил еще проверку load average, чтобы некоторые скрипты могли подождать если в момент, когда крон их решил запустить уже и так нагрузка высокая. Но проверку на существование процесса надо будет на flock переделать на досуге.

Sliver 28 фев 2011 в 10:13

man 2 flock — совсем не тоже самое, что man 1 flock.
Второе — уже утилита.

Mixailo 28 фев 2011 в 10:26

Нашел на линуксовом сервере. На freebsd найти не удалось, оно там есть?

Sliver 28 фев 2011 в 10:30

на сколько я знаю, нету.
для BSD пойдёт :)

Mixailo 28 фев 2011 в 10:39

Я тут над flock экспериментирую — никак не могу заставить его ругаться при выходе. Это возможно?

Sliver 28 фев 2011 в 10:46

Он выставляет статус, можно на него ругаться вручную через $?

Mixailo 28 фев 2011 в 10:51

То есть ему еще обертку писать?

Sliver 28 фев 2011 в 11:01

Зависит от ситуации.
Часто бывает проще написать
$ flock -n /tmp/lock -c mycommand || echo Fail
чем что-то качать, собирать и ставить.

Mixailo 28 фев 2011 в 11:03

Ну в общем да. Правда, у меня-таки фря на сервере.

Mixailo 28 фев 2011 в 10:55

Если обертку, то получится, что flock больше все-таки для встраивания в шелл-скрипты, а lockrun для самостоятельного использования. Я прав?

Sliver 28 фев 2011 в 11:08

Так можно сказать, но обычно приходится использовать то, что уже стоит на сервере.
Качают и ставят — когда совсем нечем заменить. или нечем заняться 8)

Mixailo 28 фев 2011 в 11:13

Отвыкли в наше время качать и ставить-то! %)

НЛО прилетело и опубликовало эту надпись здесь

sfoid 28 фев 2011 в 20:49

На FreeBSD — lockf

Mixailo 28 фев 2011 в 21:25

О. А пример использования в описанном контексте не подкинете?

sfoid 28 фев 2011 в 22:15

* * * * * /usr/local/bin/lockrun --lockfile=/tmp/megacache.lockrun — /path/to/megacache/generator

* * * * * lockf /tmp/megacache.lockrun /path/to/megacache/generator

Mixailo 1 мар 2011 в 07:25

[mixailo@DTG1127 ~]$ lockf pid.lock sleep 60 &
[1] 69177
[mixailo@DTG1127 ~]$ lockf pid.lock sleep 60 &
[2] 69352

Не то что-то.

whiteglasses 1 мар 2011 в 11:41

Почитайте man. Там написано, что по умолчанию, lockf будет бесконечно ждать освобождения лок-файла.

У вас в примере вторая команда ждёт выполнения первой для начала своей работы.
А если поставит нулевое время ожидания:

[root@bsd ~]# lockf -t 0 pid.lock sleep 60 &
[1] 65999
[root@bsd ~]# lockf -t 0 pid.lock sleep 60
lockf: pid.lock: already locked

Mixailo 1 мар 2011 в 13:02

А, вот оно что.

bobermaniac 28 фев 2011 в 10:22

Вроде же в линуксе есть нормальные именованые мютексы, которые могут использоваться для этой задачи куда удобнее и эффективнее, чем файлы. Я бы понял, если бы решение было на PHP, но вы используете С (кстати, программы на С не зовутся скриптами) — почему не мютексы?

Mixailo 28 фев 2011 в 10:27

Я не автор скрипта, поэтому не могу ответить вам на этот вопрос.

whiteglasses 1 мар 2011 в 09:34

Ну, файлы — это Unix way. Это даёт возможность для просмотра установленных блокировок использовать ls (dir в windows).

Mixailo 1 мар 2011 в 10:21

В этом что-то есть, хотя родной линуксовый flock за собой файл не удаляет.

bobermaniac 1 мар 2011 в 14:50

Я еще не слышал, чтобы Unix way-ем называли использованием неподходящих инструментов при наличии подходящих.

whiteglasses 1 мар 2011 в 15:13

А чем он неподходящий? Кроме того, что мьютекс, условно говоря, находится в пространстве имён недоступном через файловый API.

bobermaniac 1 мар 2011 в 15:39

В Win32 мютекс от приложения, которое умерло не своей смертью, умирает вместе с ним (точнее, переходит в состояние abadonned) и в результате становятся не нужны экзорцизмы, связанные с удалением файла в случае некорректного завершения работы.

adminimus 1 мар 2011 в 16:21

>не нужны экзорцизмы, связанные с удалением файла в случае некорректного завершения работы.

они и в юниксах не нужны

whiteglasses 1 мар 2011 в 16:33

Это да. Но если есть (я не смотрел) простой способ определить открыт ли кем-то файл, то это решает проблему.

whiteglasses 1 мар 2011 в 16:34

Мне концепция Plan 9 покоя не даёт :)

bobermaniac 1 мар 2011 в 17:31

Есть, для этого нужно всего лишь открыть файл эксклюзивно (FILE_SHARE_NONE, или аналоги). Только экзорцизмы с файлами мне все равно непонятны. Файл должен служить для того, для чего предназначен.

НЛО прилетело и опубликовало эту надпись здесь

Mixailo 28 фев 2011 в 10:46

У меня по дефолту такое:

mixailo@db:~$ echo $PATH

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

mixailo@db:~$ cat /etc/lsb-release

DISTRIB_ID=Ubuntu

DISTRIB_RELEASE=10.04

DISTRIB_CODENAME=lucid

DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS"

НЛО прилетело и опубликовало эту надпись здесь

Mixailo 28 фев 2011 в 10:52

flock тоже %)

alex_www 1 мар 2011 в 04:10

Это не так важно, важно что бы при запущеной программе лок на файл был экслюзивный.

segoon 28 фев 2011 в 12:28

Менее надёжно, но более популярно:

ln -s $$ lock-file || exit

trap "rm -f lock-file" EXIT

trap "trap - EXIT; rm -f lock-file" HUP INT QUIT

Если произошёл коллапс и файл-таки остался, то вместо "|| exit" можно осуществлять проверку существования процесса.

segoon 28 фев 2011 в 12:31

Плюс в том, что если cleanup не отработал, то произошло что-то плохое и это дело лучше разгрести руками.

flashvoid 1 мар 2011 в 05:05

Вау. А что делает последняя строчка?
Трап на попытку прибить скрипт ставит трап на EXIT и если получает exit то… вот дальше непонял.

segoon 1 мар 2011 в 21:46

Ай, бага ручного ввода, надо было копипастить :( в последней строчке должен быть exit в самом конце обработчика.

Обработчик (на стандартные сигналы завершения, можно при желании пополнить список) сбрасывает хук на выход, освобождает файл и выходит (в этот момент хук на выход уже сброшен, так что файл 2й раз не удаляется).

gribozavr 28 фев 2011 в 14:56

apt-cache show lockfile-progs

cron, между прочим, recommends.

Пример использования в /etc/cron.daily/standard

giner 28 фев 2011 в 17:46

Спасибо за поднятую тему. Узнал про flock!

Mixailo 28 фев 2011 в 18:25

Я тоже %) Только мне бестолку — у меня фряха на сервере.

rolltin 28 фев 2011 в 20:34

Port: flock-3.4_1
Path: /usr/ports/sysutils/flock
Info: Assert/wait for advisory locks with flock(2)
Maint: ports@FreeBSD.org
B-deps: mkcmd-8.14 msrc0-0.7

adminimus 1 мар 2011 в 16:22

тогда вам man lockf :)

Mixailo 1 мар 2011 в 16:42

Упоминалось еще вчера (пруф).
Хотя я, в общем-то, и не претендовал на то, что описанное решение самое лучшее или единственное.

adminimus 1 мар 2011 в 17:02

я видел. Просто не заметил, что там тоже были вы :)
Собственно, ничего страшного. Про хорошую вещь можно и повторить

egorinsk 28 фев 2011 в 21:25

Линуксоиды не умеют мьютексы?

Porfel 1 мар 2011 в 00:27

Я тут немного отрекламирую «замену крона»: http://search.cpan.org/~kohts/snaked-0.07/lib/snaked.pm
Кому-то может показаться, что это «изобретание велосипеда», но на самом деле — штука очень удобная и умеет справляться с описанной в топике задачей.

НЛО прилетело и опубликовало эту надпись здесь

akzhan 1 мар 2011 в 02:24

Я давно для таких целей использую runit.

Просто run-скрипт задаю как

#!/bin/sh

exec 2>&1

sleep exec do periodic task

non7top 1 мар 2011 в 04:08

pidof -s -o '%PPID' -x $( basename $0 ) > /dev/null 2>&1 && exit

phikus 1 мар 2011 в 06:31

А что не так с классическим
*/5 * * * * pgrep -f my_command &>/dev/null || my_command
применительно к конкретной ситуации описанной в начале?

segoon 2 мар 2011 в 11:02

Строго говоря, race condition'ом — два pgrep'а проверяют, что команда не запущена, и оба синхронно весело запускают два экземпляра.

Throwable 1 мар 2011 в 07:45

А чем плох mktemp? Проверяем не создан ли временный файл, если нет, создаем и запускаем скрипт. Файл прибивается автоматически при завершении скрипта.

Mixailo 1 мар 2011 в 07:59

Ничем, скорее всего, не плохо любое решение, к которому вы привыкли.
Я вот к lockrun привык.

phikus 1 мар 2011 в 08:48

>Чем плох?
дополнительными не дающими 100% гарантии костылями для обработки аварийного завершения скрипта?

opium 1 мар 2011 в 15:19

По моему вполне хватает создания файла и его удаления после выполнения скрипта, так в большинстве скриптов реализовано в линуксе.

Mixailo 1 мар 2011 в 15:27

Выше уже писали, что внезапная смерть скрипта создает проблемы в виде неудаленного файла. Можно проверять пид на существование, но это не дает 100% гарантии.