Единственным постоянным недостатком является то, что использование flock
дополнительных затрат. Помимо очевидного аспекта необходимости открывать и блокировать файл, у вас также есть тот факт, что будет задействован другой процесс (или, по крайней мере, дополнительный исполняемый файл и вызов exec()
если вы используете --no опция --no-fork
), и есть некоторые дополнительные затраты на очистку (потому что ОС должна снять блокировку, когда она автоматически закрывает файл).
Есть также несколько других действительно ситуативно-специфических недостатков для блокировки заданий cron, таких как этот (это не исчерпывающий список):
- Если вам нужны эксклюзивные блокировки, вам нужен доступный для записи путь к файловой системе, в противном случае команда
flock
всегда будет неудачной. Это означает, что:
- Если вы не будете осторожны, ошибка файловой системы может полностью остановить выполнение ваших заданий cron (если это приведет к тому, что путь, который вы используете для блокировок, будет перемонтирован только для чтения).
- На некоторых жестко защищенных устройствах вам может потребоваться предоставить дополнительные разрешения для заданий cron, чтобы они могли работать.
- В некоторых случаях вы на самом деле хотите, чтобы новым экземпляром задания cron был тот, который продолжается, а не старый. Лучший пример, который я могу привести для этого, - высокочастотное задание cron, которое выполняется каждые несколько минут для синхронизации файлов с другой системой, где ожидание завершения предыдущего экземпляра может задержать самые последние обновления на произвольно долгое время. Если вместо этого у вас есть задание cron, которое уничтожает все свои старые копии при запуске, вы все равно можете прогрессировать, и последние изменения с большей вероятностью будут распространены быстрее.