Как правильно дергать php скрипт кроном?

В скрипт добавьте:

set_time_limit(0);ignore_user_abort(1);

Можно использовать php-cli, если в скрипте не используются всякие переменные окружения веб-сервера.

Используются относительные пути, относительно каталога веб-сервера.

Можно сочинить что-то вроде

cd /путь/до/скрипта && /usr/local/bin/php ./скрипт.php  > /dev/null 2>&1

дергаю так

Solmyr, правильно - не дергать, а запускать /usr/bin/php. В этом случае при стандартной настройке на типичном VPS ограничение времени выполнения снято вообще.

Но из-за того что программисты не могут писать правильные скрипты для cron все повсеместно "дергают".

Почему не могут ? да посчитайте сами каким должен быть правильный скрипт для Cron :

- Знает, что cron исполняет задачи из корня файловой системы и переходит в рабочий каталог.

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

- Если эффективные пользователи различаются, то делает соответствующий chmod для файлов и каталогов.

- Не выводит ничего на стандартный вывод, а пишет в логи. Любой вывод считается ошибкой и cron отправляет его на email администратору для анализа. И этого следует, что он либо идеально написан и не выводит предупреждения php, либо гасит их, если уж они вылезают.

Статистически, с первого раза никто из наших подрядчиков не писал правильный скрипт.

И я не придираюсь. Просто в cron так задумано. Эти пункты вполне обычны для задач cron.

А что "правильно" для вас ?

Я ставлю для крон-скриптов атрибут executed, и пишу первой строкой #!/bin/php -q

А дальше из крона просто

*/5 * * * * ~/scripts/need-script.php 2>&1>/dev/null | mail -E -s "ОШИБКА bla-bla" my_email@mail.ru

В этом случае нет ограниченй по времени, не задействуется веб-сервер, в случае ошибки я пишу в самом скрипте вывод текста ошибки в stderr, и только если stderr не пустое, то мне прийдет письмо (опция -E)

Но согласен с предыдущим участником - есть некоторые особенности именно cli-скриптов.

Потому что скрипт должен взаимодействовать с ядром CMS, нативными для этой CMS методами. А переделывать CMS для того чтобы некоторым программистам скрипты казались "правильными" - это чересчур. Программирование ради программирования любят только программисты.

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

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

по крайней мере была демка где фильтр на перле на потоке посылал нотификации в браузер минут 10 пока гиг файл грузился...

Все перечисленные пункты вполне уживаются с CMS. Чтобы их доделать нужно просто прочитать man cron чуть больше.