Странным образом зависают PHP скрипты (suPHP)

а) max_execution_time это условно-физическое время которое скрипт выполняет непосредственно работу, а не внешнее время его выполнения. В него не входят вызовы sleep(), задержки получения файлов по сети типа file_get_contents(), задержки получения данных из базы mysqli_query, чтение файлов fread, вызовы всяких системных команд типа ffmpeg и прочее. В общем на max_execution_time как на убийцу полагаться нельзя.

http://php.net/manual/ru/function.set-time-limit.php

б) Если используется register_shutdown_function или ob_start , то эти функции которые были назначены к вызову через них - будут выполнены не то что "помимо" max_execution_time , но даже как раз в ситуации когда "время жизни" скрипта истекло и он как раз по этой причине был "какбэзавершен".

Простое решение - прибивать процесс пхп "внешне" - выставьте лимиты в апаче (Timeout директива), это кстати в любом случае невредно бы сделать. Неправильно, когда скрипты висят сутками.

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

edogs,

Таймаут установлен в 150. Если говорить про сам апач....

Насчет max_execution - почитал, перечитал и таки вы правы.

Однако как я уже писал выше, на чем "замирает скрипт" не совсем ясно, потому как ситуация выглядит так, что скрипт как бы висит а лога к нему нет, т.е он дошел до конца по сути работы скрипта... стало быть сработал unlink() в конце выполнения сценария.....

Теперь появилось предположение, что у нас с дебагом не совсем все хорошо происходит, начали копать немного в другую сторону, сейчас более детально будем разбирать что делает сам CURL в процессе конекта и.т.п, потому что к нему передаются TIMOUT но они судя по всему не работают..... или как-то так....

Еще гипотезы?

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

Если у Вас multi_curl, то он безбожно глючит почти в каждой из версий php так или иначе, использовать curl можно только однопоточно.

Кроме того, в курле куча таймаутов, посмотрите - может какой-то не выставили?

И в идеале скармливать курлу не доменное имя, а IP-шник, с dns в некоторых случаях он как-то неадекватно работает, когда много обращений идет - вдруг перестает понимать куда стучать или повисает (опять же, не на всех версиях php).

А вообще лично мы сторонники не curl-а, а обычного wget-а. Скормил ему php скриптом список файлов на скачку, подождал пока они скачаются и дальше обрабатывай как хочешь. Curl как-то неадекватен, да и вообще качалка файлов на php странная идея.

Если уверены что скрипт доходит до конца - попробуйте как раз обратиться к register_shutdown_function или ob_start - она сработает после завершения скрипта и возможно даст какую-то информацию. Только учтите, что к моменту начала ее работы - окружение скрипта (текущая директория в частности, права владельца) может оказаться уже не тем, что при запуске, поэтому заранее озаботьтесь абсолютными путями для логов и правами в файлах куда их писать.

Записать strace/ktrace можно?

Или может strace -f -p <pid> что-то и так показывает?

Немного внимания и станет понятно , что я и есть хостер.

Таймауты выставлены в принципе все которые известны. Не совсем понимаю, чем может быть чревато "подвисание" курла.... с одной стороны если включить сюда логику про max_execution_time, то становится ясно, что пока курл "задумался" этот счетчик типа не щелкает, однако если не указывать курлу таймауты... по какой же причине не срабатывает таймаут веб сервера.... который по идее должен порвать с клиентом связь и как следствие убить дочерние процессы в виде php .... ? Так же не понимаю, должны же быть какие-то системные таймауты, которые рано или поздно за 6 суток дадут понять курлу что отрезолвить имя не удалось или подключение не удалось в принципе.....

А кто вам сказал что какие-то файлы качаются? Пожалуйста, читайте внимательно, что я пишу.

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

---------- Добавлено 21.07.2015 в 02:25 ----------

Есть рут, записать можно в принципе все, на сейчас зависших процессов нет, как только появятся , попробую strace натравить, однако в случае php .... че он там покажет то... ? 🙄

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

Покажет точно на чем виснет, чего ждет. Не раз мне помогал на чужих скриптах.

а всякие register_shutdown_function прогер не использует случаем?

Скорей всего набор функций кодера жрет чего-то слишком много, нужно в код глядеть, если есть похожие функции, то переадресовать их по указателям и вызывать когда нужно, как ведет себя ОЗУ при выполнении набора функций?

Ну покажите что-ли gdb -p <pid> , а потом вывод bt.

bt - это backtrace, список системных вызовов.

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

Нет, не используются.

---------- Добавлено 21.07.2015 в 12:14 ----------

В том то и фишка, единственное, что может ждать это CURL.... все остальное это штатный набор минимальных функций типа preg_replace.... и.т.п... Изучаем пока поведение курла.

---------- Добавлено 21.07.2015 в 12:15 ----------

За последние сутки пока висяков не нашлось, как только появятся , буду их трейсить и gdb тоже натравлю. tnx.

Регулярность зависания как таковая отсутствует, я даже предполагаю, что зависание может образовываться в совокупности с нагрузками на сервере но подтвердить это пока не удается, графики нагрузки говорят о том, что её нет... ))))