Я пытаюсь запустить длинный процесс php, и он заканчивается ошибкой внутреннего сервера 500. Он отлично работает около 8 минут. Я перезагрузил компьютер после изменения настроек php.
Конфигурация PHP:
max_execution_time: 3600
Примерно через 10 минут ps ax | grep php:
19007? С 0:08 / usr / bin / php /home/gypsy/public_html/index.php
Я установил для ignore_user_abort значение true.
Процесс застревает в 00:08 (8-я минута) и больше не выполняется.
Журнал ошибок Apache показывает ошибку:
Истекло время ожидания сценария перед возвратом заголовков: index.php
Кажется, почему-то max_execution_time не работает. Любое предложение было бы большим подспорьем.
Я смог обнаружить проблему. Это брандмауэр блокировал процесс. сервер использует iptables с configserver в качестве брандмауэра. Отключение брандмауэра работает нормально. Но я не уверен, какие настройки следует изменить, чтобы разрешить длительный процесс в брандмауэре.
Всякий раз, когда я вижу "заголовки" - ошибки, я проверяю,
Перед любым местом возможного сбоя и / или пересылки кода может иметь место. В крайнем случае, иногда можно выполнить следующие этапы сценария:
var_dump($runtimeStuffInfo);die('argh!');
и сузьте код области, в которой возникают проблемы. Вы не совсем говорите, что пытается сделать ваш «8-минутный сценарий», но по моему опыту, наиболее стабильным подходом было бы придерживаться CLI для таких вещей:
В идеале вы можете войти на свой сервер через SSH и запустить сценарий из командной строки (желательно через nohup, чтобы вам не приходилось беспокоиться, если соединение разрывается) - таким образом вы также всегда будете видеть, где находится ваш сценарий останавливается (в случае, если он все еще работает), так как вы можете регистрировать каждый бит сразу, когда он выводится на консоль.
Если у вас нет разрешений на вход через SSH, вы все равно можете попробовать exec ('nohup php long_running_job.php > /some/writable/directory/with766/your_job.log') для запуска вашей работы на одной странице PHP (например, http://example.com/startjob.php), а затем вы анализируете вывод вашего cronjob из your_job.log на другой странице скрипта (например, http://example.com/jobresults.php).
В случае, если даже все вышеперечисленное не приведет вас к цели, я бы разделил работу на более мелкие части работы, которые завершатся задолго до того, как возникнет проблема с тайм-аутом, и затем просто вызову их по очереди.
FCGI - обработчик apache? Если это так, то вам нужно установить FcgidIOTimeout и FcgidBusyTimeout на гораздо более высокое значение. Вы можете поместить эти директивы в конфигурационный файл apache (или, в некоторых случаях, в fcgi.conf или php.conf) после загрузки модуля fcgi. Вы можете найти дополнительную информацию в документации apache fcgi http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Как насчет set_time_limit (3600);
В начале вашего сценария? Это сработает?