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

Лучший способ в оболочке состоит в том, чтобы использовать скопление (1)

(
  flock -x -w 5 99
  ## Do your stuff here
) 99>/path/to/my.lock

На самом деле, flock -n может использоваться вместо lckdo*, таким образом, Вы будете использовать код от разработчиков ядра.

Основываясь на примере womble, Вы записали бы что-то как:

* * * * * flock -n /some/lockfile command_to_run_every_minute

BTW, смотря на код, весь из flock, lockrun, и lckdo сделайте ту же самую вещь, таким образом, это - просто вопрос, которого является самым легко доступным Вам.

Вы не указали, хотите ли Вы, чтобы сценарий ожидал предыдущего выполнения для завершения или нет. "Я не хочу, чтобы задания запустили "укладку" друг по другу", я предполагаю, что Вы подразумеваете, что хотите, чтобы сценарий вышел, уже работая,

Так, если Вы надеваете, хотят зависеть от lckdo или подобный, можно сделать это:

PIDFILE=/tmp/`basename $0`.pid

if [ -f $PIDFILE ]; then
  if ps -p `cat $PIDFILE` > /dev/null 2>&1; then
      echo "$0 already running!"
      exit
  fi
fi
echo $$ > $PIDFILE

trap 'rm -f "$PIDFILE" >/dev/null 2>&1' EXIT HUP KILL INT QUIT TERM

# do the work

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

Lockfiles используются initscripts и многими другими приложениями и утилитами в системах Unix.

Это могло бы также быть знаком, что Вы делаете неправильную вещь. Если Ваши задания выполняют это тесно и что часто, возможно, необходимо считать de-cronning этим и создание его программа стиля демона.

Ваш демон крона не должен вызывать задания, если предыдущие экземпляры их все еще работают. Я - разработчик одного демона крона dcron, и мы конкретно пытаемся предотвратить это. Я не знаю, как крон Vixie или другие демоны обрабатывают это.

Я создал одну банку для решения такой проблемы, как запуск дублирующих крон может быть java или shell cron. Просто передайте имя cron в Duplicates.CloseSessions ("Demo.jar"), который будет искать и убивать existng pid для этого cron, кроме текущего. Я реализовал метод для этого. Строка proname=ManagementFactory.getRuntimeMXBean().getName(); Строка pid=proname.split("@")[0]; System.out.println("Current PID: "+pid);

            Process proc = Runtime.getRuntime().exec(new String[]{"bash","-c"," ps aux | grep "+cronname+" | awk '{print $2}' "});

            BufferedReader stdInput = new BufferedReader(new InputStreamReader(proc.getInputStream()));
            String s = null;
            String killid="";

            while ((s = stdInput.readLine()) != null ) {                                        
                if(s.equals(pid)==false)
                {
                    killid=killid+s+" ";    
                }
            }

А затем снова убить строку killid командой shell

Я бы рекомендовал использовать команду run-one - это намного проще, чем иметь дело с блокировками. Из документации:

run-one - это сценарий-оболочка, который запускает не более одного уникального экземпляра некоторой команды с уникальным набором аргументов. Это часто бывает полезно с cronjobs, когда вы хотите, чтобы одновременно выполнялось не более одной копии.

run-this-one точно такой же, как run-one, за исключением того, что он будет использовать pgrep и kill для поиска и уничтожения любые запущенные процессы, принадлежащие пользователю и сопоставление целевых команд и аргументов. Обратите внимание, что run-this-one будет блокироваться при попытке убить соответствующие процессы, пока все соответствующие процессы не работают.

run-one-always работает точно так же, как run-one, за исключением того, что возрождает "COMMAND [ARGS]" каждый раз, когда COMMAND завершается (ноль или ненулевое значение).

keep-one-running - это псевдоним для run-one-always.

run-one-until-success работает точно так же, как и запускать один постоянно, за исключением что он возрождает "COMMAND [ARGS]", пока COMMAND не завершится успешно (т. е. выходит из нуля).

run-one-until-failure работает точно так же, как run-one-always, за исключением что он воспроизводит "КОМАНДА [ARGS]" до тех пор, пока КОМАНДА не завершится с ошибкой (т. е. выход ненулевой).

Ответ @Philip Reynolds в любом случае начнет выполнение кода после 5 секунд ожидания без получения блокировки. После Flock, похоже, не работает , я изменил ответ @Philip Reynolds на

(
  flock -w 5 -x 99 || exit 1
  ## Do your stuff here
) 99>/path/to/my.lock

, чтобы код никогда не выполнялся одновременно. Вместо этого после 5 секунд ожидания процесс завершится с 1, если к тому времени он не получит блокировку.

Теперь, когда systemd отсутствует, есть еще один механизм планирования в системах Linux:

A systemd.timer

В /etc/systemd/system/myjob.service или ~ / .config / systemd / user / myjob.service :

[Service]
ExecStart=/usr/local/bin/myjob

В /etc/systemd/system/myjob.timer или ~ / .config / systemd / user /myjob.timer:

[Timer]
OnCalendar=minutely

[Install]
WantedBy=timers.target

Если сервисный модуль уже активирован, когда таймер в следующий раз активируется, то другой экземпляр сервиса будет , а не запущен.

Альтернатива, которая запускает задание один раз при загрузке и через одну минуту после завершения каждого запуска:

[Timer]
OnBootSec=1m
OnUnitInactiveSec=1m 

[Install]
WantedBy=timers.target