LINUX.ORG.RU
ФорумAdmin

Cron и слежение за не повторением.


0

0

Правда тему загнул? Но по другому описать это я не знаю как. В общем проблема такая. Крон запускает каждые 3 минуты перенос файлов из одного места в другое. Но период выполнения этой операции может быть разным. Что получается. Крон запускает операцию и пока та еще выполняется, крон запускает еще раз ту же операцию и так повторяет с периодом в три минуты. Можно как-то указать крону что бы он не запускал второй и последующие потоки если один уже работает?


напиши шел скрипт который будет проверять, не запущенна ли еще одна копия

hizel ★★★★★
()

А что мешает из крона заупскать скрипт, который себя проверит по pid файлу например и сам отвалится.

дело крона "пнуть", дело скрипта корректно отработать

pidNum=""

[ -f "..../dummy.pid" ] && pidNum=`cat dummy.pd`

# выход так как предположительно есть реальный процесс [ ! -z "$pidNum" ] && [ -d /proc/$pidNum ] && exit 1

# чистим убитый например по -9 процесс [ ! -z "$pidNum" ] && [ ! -d /proc/$pidNum ] && rm -f ...../dummy.pid

# что то там стартует

real_maverick ★★★
()
Ответ на: комментарий от real_maverick

чЪорт - некорректное форматирование:

pidNum=""

[ -f "..../dummy.pid" ] && pidNum=`cat dummy.pd`

# выход так как предположительно есть реальный процесс

[ ! -z "$pidNum" ] && [ -d /proc/$pidNum ] && exit 1

# чистим убитый например по -9 процесс

[ ! -z "$pidNum" ] && [ ! -d /proc/$pidNum ] && rm -f ...../dummy.pid

# что то там стартует

real_maverick ★★★
()

Может вам вобще отказаться от crond для данной задачи, а написать, а-ля, демона на bash?

#!/bin/bash
while : ; do
   запуск скрипта
   sleep 180
done

TRAP на сигналы по вкусу.

mky ★★★★★
()

используй pid-файлы.

drull ★☆☆☆
()
Ответ на: комментарий от mky

и после ребута тачки судорожно вспоминать что там надо было руками запускать... Это помимо того что репортов на почту не будет.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

>и после ребута тачки судорожно вспоминать что там надо было руками запускать...

крон может запускать скрипты при загрузке - @reboot

Dimanc ★★
()
$ strings /usr/sbin/crond | grep delayed
Job execution of per-minute job scheduled for %.2u:%.2u delayed into subsequent minute %.2u:%.2u. Skipping job run.

Вывод: пиши */3 в начале строки, и будет тебе счастье.

DonkeyHot ★★★★★
()
Ответ на: комментарий от Dimanc

так я о том же. пусть регулярными запусками занимется крон.

true_admin ★★★★★
()
Ответ на: комментарий от mky

Самый простой способ, как мне кажется, без использования файлов-флагов-блокировок это запуск скрипта из /etc/inittab как respawn, а в конце скрипта поставить sleep 180, чтобы регулировать минимальную паузу между запусками скрипта.

sdio ★★★★★
()

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

ansky ★★★★★
()
Ответ на: комментарий от sdio

Будет ли счастье?

>Счастья не «будет» ...

... оно «было» и «есть» :) Что характерно, в changelog-е vixie-cron-а не удалось найти время его появления, похоже оно там было с самого начала.

DonkeyHot ★★★★★
()
Ответ на: комментарий от true_admin

>Я в мане убунтовского такого не вижу

Я в мане тоже не вижу. «Use the source, Luke».

DonkeyHot ★★★★★
()
Ответ на: комментарий от sdio

vixie cron 3.0pl1-106

Странная версия крона в Debian Squeeze

sdio ★★★★★
()
Ответ на: комментарий от true_admin

Если мы говорим, что скрипт это демон, то его и оформить надо соответсвенно, записать в /etc/inittab (как уже сказали) или в /etc/rc.d/* (/etc/init.d/*).

lock-файлы и lock-pid файлы нужно чистить после неожиданного ребута системы или писать скрипт так, что бы он регулярно обновлял lock-файл.

Я точно не знаю задачу топикстартера, но, подозреваю, что переодичность 3 мин исходно создана искусственно, чтобы скрипт успевал выполняться.

mky ★★★★★
()
Ответ на: комментарий от DonkeyHot

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

Спасибо за бдительность.

DonkeyHot ★★★★★
()
Ответ на: комментарий от mky

> lock-файлы и lock-pid файлы нужно чистить после неожиданного ребута системы

поэтому их и кладут в /tmp. И, если использовать flock, то он работает не по принципу «если есть файл то есть блокировка» а через flock() который после ребута уберётся(man 2 flock).

или писать скрипт так, что бы он регулярно обновлял lock-файл.

в этом нет необходимости. Надо просто запускать через flock -w 0 /tmp/mylock progname . Тут, правда, есть несколько нюансов. Например, лок будут удерживать все форкнутые процессы итп. Фряшный аналог поприятнее работает.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

При загрузке /tmp автоматически очищается не во всех системах.

Про «man 1 flock» я плохого не говорил, мне не понравилось «man lockfile-progs», потому что, например, есть такое http://www.tin.org/bin/man.cgi?section=1&topic=lockfile-progs , хотя может вы подразумевали другую man-страницу.

mky ★★★★★
()
Ответ на: комментарий от mky

Да, согласен, херовые утилиты посоветовал. Только вот flock не делает блокировки с O_CLOEXEC :(. Впрочем, патч сделать несложно.

true_admin ★★★★★
()

Всё делается просто

#!/usr/bin/env bash

pidfile=«/tmp/cpulimit.run»
if [ -e $pidfile ]
then
exit 0
fi
echo $$| cat > $pidfile

trap 'rm — «$pidfile»' EXIT

echo «`date `: starting the Loop..» >> /tmp/cpuloop.status

/usr/bin/dojob

--------------

а в кронтабе пиши хоть
* * * * * /path/to/loop


P.S. как тут форматированием пользоваться?

truf
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.