Насколько надежным является «at»

Question

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

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); 

Во-первых, хрон запускает первый процесс, который после этого расписания другие команды, в зависимости от ответа API. Я должен запускать эти команды каждые две минуты, так что cron как at нередко увольняются. Хотя я знаю, что cron работает (и команды в файле работают так, как предполагается при вызове вручную), некоторые из заданий не выполняются/не выполняются.

Поскольку я не работал с at с таким количеством заданий, я имею в виду, если at такой же надежный, насколько мне нужно. Или у моего кода есть недостаток, которого я не вижу.

Итак, это вопрос к моему вопросу, имеет at, который будет считаться надежным на огромном количестве заданий и должен ли я контролировать исходный код для ошибок или at просто не должен считаться достаточно надежным для работы в чисто программно исполняемой среде?

Answer 1

Мы не знаем, насколько надежно вам нужно «на», но то, что вы описываете, похоже, является анти-шаблоном для использования.

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

В то время как «at» обычно запускает задачи с гранулярностью с точностью до 1 секунды, нет никаких гарантий, что задача всегда будет выполняться в течение 1 секунды от графика. Если вам нужен этот уровень уверенности, вам нужна операционная система реального времени.

Некоторые версии 'cron' и 'at' не будут запускать задания, если нагрузка превышает определенный порог. Помимо этого сценария, я никогда не знал «в» принять работу, которая не была (в конечном итоге) запущена atd.

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

Код, который вы нам показали, не проверяет код возврата от вызова 'at'.