Точность синхронизации Cronjob -запланированное время как параметр
Похоже, что ключевой ключ к сообщениям журнала заключается в том, что зонды, зарегистрированные как имеющие «прото 6», завершаются успешно, а те, которые регистрируются как имеющие «прото 17», терпят неудачу. 6 и 17 оказываются номерами транспортных IP-протоколов, представляющих TCP и UDP соответственно.
Хотя NFS традиционно обслуживается через UDP, обслуживание через TCP поддерживается большинством стеков, и в этом случае сервер всегда был настроен на обслуживание NFS только через TCP. Однако это не представляло проблемы до тех пор, пока на сервере не произошло -еще не охарактеризованное изменение, которое привело к тому, что трафик nfs/udp впоследствии молча отбрасывался вместо того, чтобы отклоняться с соответствующим ответом ICMP. Это вполне могло быть вызвано изменением брандмауэра, но на данный момент я не могу исключить изменение уровня приложения -на сервере.
В любом случае, я решил проблему на стороне клиента, добавив proto=tcpк параметрам монтирования каждой затронутой файловой системы в файле карты autofs. Autofs был достаточно умен, чтобы отказаться от проверки вкуса UDP -, как только эта опция была на месте. Проблема не только решена, но производительность монтирования теперь кажется даже немного лучше, чем до начала проблемы с тайм-аутом.
Просто проверив свой собственный системный журнал, я вижу, что задания cron обычно начинаются через 1 секунду после минуты (Ubuntu 20.04 ). (Например, :десять минут пятого срабатывает в05:10:01). В моей системе это довольно стабильно, но я бы не стал этого гарантировать.
При большой нагрузке это может быть хуже, потому что даже если cronjob запустится в нужное время, чрезвычайно большая нагрузка может задержать excve более чем на секунду. Но тогда такая экстремальная нагрузка настолько замедлит ваш скрипт, что время запуска станет практически бессмысленным.
Cron может и иногда пропускает задания, например, если система выключена, он никогда не догонит их. Я был бы особенно осторожен с этим примечанием в руководстве :
.Note that this means that non-existent times, such as "missing hours" during daylight savings conversion, will never match, causing jobs scheduled during the "missing times" not to be run. Similarly, times that occur more than once (again, during daylight savings conversion) will cause matching jobs to be run twice.
Убедитесь, что ваш код не сломается, если он будет выполняться по адресу 05 :10 :02 вместо 05 :10 :01.
Не существует элегантного способа заставить cron сообщать вам, какое задание запущено. Вы можете настроить множество одинаковых заданий для запуска в разное время, каждое задание может передавать время в качестве аргумента. Я вижу два варианта:
Настройте crontab с большим количеством записей
Проверьте примечания ниже.
Да, в сутках 1440 минут, поэтому, если вам нужен crontab для запуска этого поминутно, вам может понадобиться скрипт для создания crontab:
#!/bin/bash
for hour in {0..23} ; do
for minute in {0..59} ; do
echo "${minute} ${hour} * * * root /path/to/script.sh ${hour}:${minute}:01"
done
done > /etc/cron.d/my-job
У вас получится что-то вроде этого:
01 00 * * * root my-job 00:01:01
02 00 * * * root my-job 00:02:01
03 00 * * * root my-job 00:03:01
...
Создайте скрипт-оболочку для поиска ближайшего ожидаемого запуска
Возможно, лучше создать скрипт-оболочку, который проверяет текущее время и находит ближайшую запись. Если ваше задание настроено на запуск каждые 15 минут, вы можете использовать приведенный здесь пример:
#!/bin/bash
curdate=`date "+%s"`
run_time=$(($curdate - ($curdate % (15 * 60))))
run_time_arg=$(date -d"@$run_time" "+%H:%M:%S")
/path/to/script.sh $run_time_arg
Обратите внимание, что здесь используется поведение, характерное для GNU date, и оно может работать не во всех реализациях