Я работаю над планировщиком командной строки, потому что мне нужно запускать несколько команд через несколько минут друг за другом в разное время.
public static function set ($dir, $operation, $arguments = [], $options = [], $timeToWait)
{
$argumentstring = '';
$optionstring = '';
foreach($arguments as $argument)
{
$argumentstring .= $argument.' ';
}
if ($options)
{
foreach ($options as $key => $option)
{
$optionstring .= '--' . $key . '=\"' . $option . '\" ';
}
}
$command = $operation. ' ' . $argumentstring . ' ' . $optionstring;
return $string = exec('echo php '.$dir.'/./prices '.$command.' | /usr/bin/at -M now + '.$timeToWait. ' min');
}
Называется как
Schedule::set(getcwd(), 'put:acknowledge', ['Customer' => database_connector::getUserId(), 'ReportId' => ReportIdDeclaration::getReportID(), [], 5);
Сначала cron запускает первый процесс, который затем планирует другие команды, в зависимости от ответа API. Я должен запускать эти команды каждые две минуты, так что cron
как at
довольно часто увольняются. Хотя я знаю, что cron работает (и команды в файле работают так, как предполагается при вызове вручную), некоторые задания не выполняются / не выполняются.
Поскольку я не работал с at
с таким количеством рабочих мест, я под вопросом at
настолько надежный, насколько мне нужно. Или у моего кода есть недостаток, которого я не вижу.
Так вот в чем смысл моего вопроса, имеет at
быть признанным надежным на огромном количестве заданий и должен ли я контролировать свой исходный код на наличие ошибок, или at
просто чтобы не считаться достаточно надежным для работы в чисто программно выполненной среде?
Мы не знаем, насколько надежным вам нужно быть в at, однако то, что вы описываете, похоже, является чем-то вроде анти-паттерна для использования в.
Если вам нужно, чтобы задания выполнялись в последовательности, тогда они должны быть связаны в сценарии с единой точкой входа.
Хотя at обычно запускает задачи с точностью до 1 секунды, нет никаких гарантий, что задача всегда будет выполняться в течение 1 секунды от расписания. Если вам нужен этот уровень уверенности, то вам нужна операционная система реального времени.
Некоторые версии ‘cron’ и ‘at’ не будут запускать задания, если нагрузка превышает определенный порог. Помимо этого сценария, я никогда не знал, что «at» может принять работу, которая (в конце концов) не была запущена atd.
Конечно, более поздние системы могут не использовать atd, и crond-systemd поддерживает эту функцию (работает ли она и является ли это хорошей идеей, это очень длинный аргумент).
Код, который вы показали нам здесь, не проверяет код возврата от вызова ‘at’.
Других решений пока нет …