Таймаут исполнения РНР скрипта на сервере.

Дело вот в чем. Написал я для себя простенький скрипт, который просматривает всю базу галер у ТГП на предмет нерабочих линков. Ну и грубо говоря сносит нерабочие линки. Потом отчет на мыло присылает. Запускать предполагалось Кроном раз в сутки.
Так вот - проявилась следующая неожиданная проблема: операция проверки каждого линка занимает некоторое время, и в результате скрипт прекращает свое выполнение видимо по наступлению какого-то таймаута. При попытке запуска локально на Денвере он ругается:
"Fatal error: Maximum execution time of 30 seconds exceeded".
при этом не успевая проверить даже десяток линков.

Это можно как-то побороть или я изначально выбрал неправильную статегию написания подобного скрипта?

В самом начале скрипта ставь строчку <?php set_time_limit(600);?> где 600 - время исполнения в секундах... 0 - выполнять бесконечно, пока невыполнится или сервер неупадет

Спасибо, оценил.
Пробую.

Создай файл .htaccess следующего содержания:
php_value max_execution_time 300
и поместить его в каталог со скриптом (300 - это время выполнения скрипта в секундах, вместо него можно указать другое значение).

Вариант с увеличением времени выполнения скрипта не корректен с точки зрения безопасности и надежности работы сервера.

Данные задачи решаются путем запуска крона, например, каждые 5 минут. За один раз идет проверка фиксированного кол-ва линков.

A d u l t писал:

Вариант с увеличением времени выполнения скрипта не корректен с точки зрения безопасности и надежности работы сервера. Данные задачи решаются путем запуска крона, например, каждые 5 минут. За один раз идет проверка фиксированного кол-ва линков.

а где тут могут возникнуть проблемы с безопасностью? ходит себе скрипт по урлам, никого не трогает...
у меня ни разу не было проблем со скриптами, что крутились по пол часа...
2топикстартер:
есть маза задачу пускать форками... то бишь pcntl_fork(); пускай с десяток потоков, в 10 раз быстрее работать будет. ну и по желанию сэт_тайм_лимит(0)ж
зы: при многопоточности не забываем лочить файлы и/или таблицы!

Во-первых, не советую ставить на рабочем сервере примочку pcntl к пхп. Она переколбашивает все системные вызовы (exec,system,mail) таким образом, что там где должен был вернуться результат true, возвращается false и там где процесс должен был вернуть 0, возвращается 255.

Во-вторых, вариант с увеличением времени выполнения скрипта не корректен с точки зрения безопасности и надежности работы сервера ТОЛЬКО в случае глобального увеличения таймаута в php.ini, а при увеличении таймаута конкретного скрипта не вижу ничего болезненного (если афтар знает что делает)

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

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

Могу взять тестером системы:
http://www.dfservice.com/site-monitor/index.html.ru.htm

Последняя версия работает без использования крон(и трафика тоже) и в несколько потоков.

Pentarh писал:

Во-первых, не советую ставить на рабочем сервере примочку pcntl к пхп. Она переколбашивает все системные вызовы (exec,system,mail) таким образом, что там где должен был вернуться результат true, возвращается false и там где процесс должен был вернуть 0, возвращается 255.

Оппа. А я думаю, в чем дело, какого хера по статусу не удается результат вызова проверить. Бум знать на будущее.
Кстати, с обработчиком сигналов в том же pcntl не работал? А то есть ощущение, что нихера он не обрабатывает.

Xrenoder писал:

Оппа. А я думаю, в чем дело, какого хера по статусу не удается результат вызова проверить. Бум знать на будущее. Кстати, с обработчиком сигналов в том же pcntl не работал? А то есть ощущение, что нихера он не обрабатывает.

Я тоже долго думал в чем дело, потом накопал в гуглгрупс что это такой прикол pcntl. Причем разработчики не помню как аргументируют, но багом это не считают. Наоборот, типа фишка

С обрабочиком сигналов работал. Вот кусок кода из утилитки-демона, которая мониторит мускуль и в случае чего поднимает. Здесь задача при любом выходе убить свой pid-файл. Повесил обработчики:

Код:

function sig_handler($signo) {     global $mypid;     switch ($signo) {             case SIGTERM:             case SIGINT:                 // handle shutdown tasks                 @unlink($mypid);                 syslog(LOG_NOTICE,"Cautch term signal. Exiting.");                 exit("Cautch term signal\n");                 break;             default:                 break;     } } pcntl_signal(SIGTERM, "sig_handler"); pcntl_signal(SIGINT, "sig_handler"); register_shutdown_function("sig_handler",SIGTERM);

Все работает, только вот когда делаю 'kill pid' то пид нифига не убивается, хотя есть обработчик на SIG_TERM

Pentarh писал:

Я тоже долго думал в чем дело, потом накопал в гуглгрупс что это такой прикол pcntl. Причем разработчики не помню как аргументируют, но багом это не считают. Наоборот, типа фишка С обрабочиком сигналов работал. Вот кусок кода из утилитки-демона, которая мониторит мускуль и в случае чего поднимает. Здесь задача при любом выходе убить свой pid-файл. Повесил обработчики: Код: function sig_handler($signo) {     global $mypid;     switch ($signo) {             case SIGTERM:             case SIGINT:                 // handle shutdown tasks                 @unlink($mypid);                 syslog(LOG_NOTICE,"Cautch term signal. Exiting.");                 exit("Cautch term signal\n");                 break;             default:                 break;     } } pcntl_signal(SIGTERM, "sig_handler"); pcntl_signal(SIGINT, "sig_handler"); register_shutdown_function("sig_handler",SIGTERM); Все работает, только вот когда делаю 'kill pid' то пид нифига не убивается, хотя есть обработчик на SIG_TERM

А какие сигналы у тебя проверено обрабатываются? INT? У меня не ловило TERM и ABRT, после чего я плюнул на это дело и пошел в обход.

Как видишь, TERM, INT

TERM = kill
INT = Ctrl-C

Pentarh писал:

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

Вот про если можно поподробней, вылетает скрипт при запуске через web

Код:

ignore_user_abort (1) set_time_limit (1000)

Если в браузер, то до конца работает.
И вылетает без ошибок, наверно апач прибиавет или еще что ?
Какие еще причины могут быть ?
Я уже запарился, может дело в этой буферизации ?
ob_implicit_flush () это ?

Дело в том что апач убивает процесс если тот долго ничего не выводит в поток. По этому для тебя решением будет логгирование работы скрипта.

Скажем, отпарсил галерку и выбрасываешь в поток строку, отключая буферизацию:

Код:

echo "Gallery $url done <br>\n"; flush(); ob_flush();

тогда апач будет видеть что скрипт "живой" и не будет его убивать. А таймлимит оставь.

2xrenoder: я подумал мож у тебя значение константы SIGTERM php не соответствует значению системной константы TERM. Посмотри "man 1 kill", там для твоей системы должны быть численные значения этих констант.

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