Mixailo Feb 28 2011 at 12:48

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

2 min

25K

Configuring Linux*

+39

Comments 71

Sliver Feb 28 2011 at 12:52

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

Mixailo Feb 28 2011 at 13:00

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

-7

blabla Feb 28 2011 at 13:13

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

Mixailo Feb 28 2011 at 13:22

И правда.

Harkonnen Mar 1 2011 at 19:06

PHP вариант:

Harkonnen Mar 1 2011 at 19:08

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

Mixailo Mar 1 2011 at 20:54

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

netp Mar 31 2011 at 23:16

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

Urevic Mar 1 2011 at 00:06

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

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

Sliver Feb 28 2011 at 13:13

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

Mixailo Feb 28 2011 at 13:26

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

-2

Sliver Feb 28 2011 at 13:30

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

Mixailo Feb 28 2011 at 13:39

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

-2

Sliver Feb 28 2011 at 13:46

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

Mixailo Feb 28 2011 at 13:51

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

-2

Sliver Feb 28 2011 at 14:01

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

Mixailo Feb 28 2011 at 14:03

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

-1

Mixailo Feb 28 2011 at 13:55

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

-1

Sliver Feb 28 2011 at 14:08

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

Mixailo Feb 28 2011 at 14:13

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

UFO just landed and posted this here

sfoid Feb 28 2011 at 23:49

На FreeBSD — lockf

Mixailo Mar 1 2011 at 00:25

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

sfoid Mar 1 2011 at 01:15

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

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

Mixailo Mar 1 2011 at 10:25

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

Не то что-то.

whiteglasses Mar 1 2011 at 14: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 Mar 1 2011 at 16:02

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

bobermaniac Feb 28 2011 at 13:22

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

-2

Mixailo Feb 28 2011 at 13:27

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

-3

whiteglasses Mar 1 2011 at 12:34

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

Mixailo Mar 1 2011 at 13:21

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

-1

bobermaniac Mar 1 2011 at 17:50

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

whiteglasses Mar 1 2011 at 18:13

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

bobermaniac Mar 1 2011 at 18:39

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

-1

adminimus Mar 1 2011 at 19:21

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

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

whiteglasses Mar 1 2011 at 19:33

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

whiteglasses Mar 1 2011 at 19:34

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

bobermaniac Mar 1 2011 at 20:31

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

UFO just landed and posted this here

Mixailo Feb 28 2011 at 13: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"

UFO just landed and posted this here

Mixailo Feb 28 2011 at 13:52

flock тоже %)

alex_www Mar 1 2011 at 07:10

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

segoon Feb 28 2011 at 15:28

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

ln -s $$ lock-file || exit

trap "rm -f lock-file" EXIT

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

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

segoon Feb 28 2011 at 15:31

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

flashvoid Mar 1 2011 at 08:05

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

segoon Mar 2 2011 at 00:46

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

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

gribozavr Feb 28 2011 at 17:56

apt-cache show lockfile-progs

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

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

giner Feb 28 2011 at 20:46

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

Mixailo Feb 28 2011 at 21:25

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

-1

rolltin Feb 28 2011 at 23: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 Mar 1 2011 at 19:22

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

Mixailo Mar 1 2011 at 19:42

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

adminimus Mar 1 2011 at 20:02

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

egorinsk Mar 1 2011 at 00:25

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

-4

Porfel Mar 1 2011 at 03:27

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

UFO just landed and posted this here

akzhan Mar 1 2011 at 05:24

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

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

#!/bin/sh

exec 2>&1

sleep exec do periodic task

non7top Mar 1 2011 at 07:08

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

phikus Mar 1 2011 at 09:31

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

segoon Mar 2 2011 at 14:02

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

Throwable Mar 1 2011 at 10:45

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

Mixailo Mar 1 2011 at 10:59

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

phikus Mar 1 2011 at 11:48

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

opium Mar 1 2011 at 18:19

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

Mixailo Mar 1 2011 at 18:27

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