Вопросы Теги

крон, каждую минуту тараните проблемы

Что-то вроде этого должно добиться цели: curl -d param="$(cat file1.txt)" ...

3
14.09.2016, 04:24
3 ответа

Вот простое решение для сценария удара; вероятно, можно сделать то же в cron.php сценарии. Это на самом деле проверяет на процессы, которые работают слишком долго; для автоматизированной системы это - вероятно, хорошая идея.

#!/bin/bash

# Exit if process is already running
if test -e /tmp/wordpress-job.pid; then
  # Check if the pid that was stored in /tmp/wordpress-job.pid does exist
  if ps ax -o pid= | grep $(cat /tmp/wordpress-job.pid ) &> /dev/null; then
    exit 0
  fi
fi

# Create the file that marks this process as running
echo $$ > /tmp/wordpress-job.pid

# Some extra security check to prevent the pid file
# to survive.
trap "rm -f /tmp/wordpress-job.pid" EXIT TERM INT HUP 

# Start the long-running process in the background
sleep 3600 & # long-running process

# Sleep some time before trying to kill that process
sleep 300

# Kill job if it takes longer than it should
kill %1

# Delete the file that marks this process as running
rm -f /tmp/wordpress-job.pid

Необходимо заменить "сон 3600" php командной строкой и изменить 300 ниже на максимальное время, которое сценарию нужно позволить выполнить.

1
27.01.2020, 21:32
  • 1
    , которому я верю, существует состояние состязания, если другой процесс создает/tmp/wordpress-job.pid промежуточный тест и эхо. Более безопасный путь состоял бы в том, чтобы создать/tmp/wordpress-job. файл $$ и затем попытаться создать жесткую ссылку на/tmp/wordpress-job.pid - ссылка перестанет работать, если/tmp/wordpress-job.pid уже будет существовать, и это является атомарным. –  Paul Tomblin 02.04.2012, 20:45
  • 2
    я не думаю, что это необходимо. В конце концов, процесс только запускается однажды в минуту. Но сценарий мог, конечно, быть изменен, чтобы быть на безопасной стороне. –  daniel kullmann 02.04.2012, 22:49

Заставьте свою crontab запись выполнить это:

if mv /var/run/my-php-job.pending /var/run/my-php-job.running 2>/dev/null; then
  echo $$ >|/var/run/my-php-job.running   # optional
  … # run the job
  : >|/var/run/my-php-job.running         # optional
  mv /var/run/my-php-job.running /var/run/my-php-job.pending
fi

Вставьте это @reboot запись crontab:

rm -f /var/run/my-php-job.running
touch /var/run/my-php-job.pending

Название файла служит блокировкой. В то время как это .running, существует рабочее задание, и следующее задание не запустится. Когда это .pending, рабочее задание запускается и переключается на .running.

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

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

0
27.01.2020, 21:32

Существуют специальные утилиты для предотвращения параллельных выполнений: скопление в util-linux, lockf в системах BSD, халтуре в NetBSD и с INN и cnews пакетами.

С наиболее вероятным случаем (Linux) называют что-то подобным:

flock -w 60 /somedir/lockfile cron.php

Рецепты в других ответах произведены альтернативы скопления своими силами и полезны только в случае отсутствия такого инструмента.

OTOH можно иметь дело с таким привязывать программу непосредственно, но необходимо повторить все детали тщательно, иначе можно создать состояние состязания.

0
27.01.2020, 21:32

Теги

Похожие вопросы