php reload php ini
How to force reloading php.ini file?
I configured a web server last week, it worked fine.
Today I request its homepage, I see a timezone error, as it should be configured into my php.ini file.
I try a phpinfo(); on my webserver, it gives me:
But no php.ini file loaded.
I investigate, the php file exists and has very large permissions:
Of course I restart my server a dozen of time.
What can I do more to resolve my problem?
4 Answers 4
To force a reload of the php.ini you should restart apache.
Try sudo service apache2 restart from the command line. Or sudo /etc/init.d/apache2 restart
TL;DR; If you’re still having trouble after restarting apache or nginx, also try restarting the php-fpm service.
The answers here don’t always satisfy the requirement to force a reload of the php.ini file. On numerous occasions I’ve taken these steps to be rewarded with no update, only to find the solution I need after also restarting the php-fpm service. So if restarting apache or nginx doesn’t trigger a php.ini update although you know the files are updated, try restarting php-fpm as well.
To restart the service:
Note: prepend sudo if not root
Using SysV Init scripts directly:
Using service wrapper script
Using Upstart (e.g. ubuntu):
Using systemd (newer servers):
Or whatever the equivalent is on your system.
The above commands taken directly from this server fault answer
Пробуем preload (PHP 7.4) и RoadRunner
Мы часто пишем и говорим о производительности PHP: как мы ей занимаемся в целом, как мы сэкономили 1 млн долларов при переходе на PHP 7.0, а также переводим разные материалы на эту тему. Это вызвано тем, что аудитория наших продуктов растёт, а масштабирование PHP-бэкенда при помощи железа сопряжено со значительными затратами — у нас 600 серверов с PHP-FPM. Поэтому инвестирование времени в оптимизацию для нас выгодно.
Прежде мы говорили в основном об обычных и уже устоявшихся способах работы с производительностью. Но сообщество PHP не дремлет! В PHP 8 появится JIT, в PHP 7.4 — preload, а за пределами core-разработки PHP развиваются фреймворки, подразумевающие работу PHP как демона. Пора поэкспериментировать с чем-то новым и посмотреть, что это может нам дать.
Так как до релиза PHP 8 ещё далеко, а асинхронные фреймворки плохо подходят для наших задач (почему — расскажу ниже), сегодня остановимся на preload, который появится в PHP 7.4, и фреймворке для демонизации PHP — RoadRunner.
Это текстовая версия моего доклада с Badoo PHP Meetup #3. Видео всех выступлений мы собрали в этом посте.
PHP-FPM, Apache mod_php и подобные способы запуска PHP-скриптов и обработки запросов (на которых работает подавляющее большинство сайтов и сервисов; для простоты я буду называть их «классическим» PHP) работают по принципам shared-nothing в широком смысле этого термина:
Как это могло бы выглядеть, если бы мы вышли за рамки «классического» PHP? Например, наш скрипт мог бы запускаться вне зависимости от запроса, производить инициализацию и иметь внутри себя цикл выполнения запросов, уже внутри которого он ждал бы следующий, обрабатывал его и повторял цикл, не очищая окружение (дальше я буду называть это решение «PHP как демон»).
Производительность такого решения потенциально значительно выше, чем у «классического» PHP. Но обычно увеличение производительности не даётся бесплатно — за него приходится платить какую-то цену. Давайте разберёмся, что это может быть в нашем случае.
Вообще может не только закончиться память — могут произойти какие-то другие ошибки, которые приведут к смерти процесса. С такими проблемами «классический» PHP справляется автоматически. В случае же запуска PHP как демона нам нужно как-то следить за этим демоном, перезапускать его, если он упал.
Если подытожить, то для «классического» PHP (PHP-FPM, Apache mod_php и подобных) проще писать код — он освобождает нас от целого ряда проблем и ошибок. Но за это мы платим производительностью.
Из примеров выше мы видим, что в некоторых частях кода на обработку каждого запроса «классического» PHP тратит ресурсы, которые можно было бы не тратить (или тратить однократно). Это следующие области:
Preload
Из трёх пунктов, перечисленных выше, preload призван бороться с первым — оверхедом при подключении файлов. На первый взгляд это может показаться странным и бессмысленным, ведь в PHP уже есть OPcache, который был создан именно для этой цели. Для понимания сути давайте попрофилируем при помощи perf реальный код, над которым включён OPcache, у которого hit rate равен 100%.
Несмотря на OPcache, мы видим, что persistent_compile_file занимает 5,84% времени выполнения запросов.
Для того чтобы разобраться, почему так происходит, мы можем посмотреть исходники zend_accel_load_script. Из них видно, что, несмотря на наличие OPcache, при каждом вызове include/require копируются сигнатуры классов и функций из общей памяти в память процесса-воркера, а также делается различная вспомогательная работа. И эта работа должна быть сделана для каждого запроса, так как по его окончании память процесса-воркера очищается.
Это усугубляется большим количеством вызовов include/require, которое мы обычно производим за один запрос. Например, Symfony 4 подключает порядка 310 файлов до выполнения первой полезной строчки кода. Иногда это происходит неявно: чтобы создать инстанс класса A, приведённого ниже, PHP выполнит автозагрузку всех остальных классов (B, C, D, E, F, G). И особенно в этом плане выделяются зависимости Composer’а, объявляющие функции: чтобы гарантировать, что эти функции будут доступны во время выполнения пользовательского кода, Composer вынужден всегда подключать их вне зависимости от использования, так как в PHP отсутствует автозагрузка функций и они не могут быть подгружены в момент вызова.
Как работает preload
Preload имеет одну-единственную основную настройку opcache.preload, в которую передаётся путь до PHP-скрипта. Этот скрипт будет выполнен однократно при запуске PHP-FPM/Apache/и т. п., а все сигнатуры классов, методов и функций, которые будут объявлены в этом файле, станут доступны всем скриптам, обрабатывающим запросы, с первой строчки их выполнения (важное замечание: это не относится к переменным и глобальным константам — их значения обнулятся после окончания фазы preload). Больше не нужно делать вызовы include/require и копировать сигнатуры функций/классов из общей памяти в память процесса: все они объявляются immutable и за счёт этого все процессы могут ссылаться на один и тот же участок памяти, содержащий их.
Обычно нужные нам классы и функции лежат в разных файлах и объединять их в один preload-скрипт неудобно. Но этого делать и не нужно: так как preload — это обычный PHP-скрипт, мы можем просто использовать include/require или opcache_compile_file() из preload-скрипта для всех нужных нам файлов. Кроме того, так как все эти файлы будут подгружены единожды, PHP сможет произвести дополнительные оптимизации, которые невозможно было сделать, пока мы по отдельности подключали эти файлы в момент выполнения запроса. PHP делает оптимизации только в рамках каждого отдельного файла, но в случае с preload — для всего кода, подгруженного в фазе preload.
Бенчмарки preload
Для того чтобы продемонстрировать на практике пользу от preload, я взял один CPU-bound endpoint Badoo. Для нашего бэкенда в целом характерна CPU-bound-нагрузка. Этот факт является ответом на вопрос, почему мы не рассматривали асинхронные фреймворки: они не дают никакого преимущества в случае CPU-bound-нагрузки и при этом ещё больше усложняют код (его нужно писать иначе), а также для работы с сетью, диском и прочим требуются специальные асинхронные драйвера.
Чтобы в полной мере оценить пользу от preload, для эксперимента я загрузил с помощью него вообще все файлы, которые необходимы тестируемому скрипту во время работы, и нагрузил его подобием обычной production-нагрузки при помощи wrk2 — более продвинутого аналога Apache Benchmark, но такого же простого.
Чтобы попробовать preload, нужно сначала перейти на PHP 7.4 (у нас сейчас PHP 7.2). Я замерил производительность PHP 7.2, PHP 7.4 без preload и PHP 7.4 с preload. Получилась вот такая картина:
Таким образом, переход c PHP 7.2 на PHP 7.4 даёт +10% к производительности на нашем endpoint’е, а preload даёт ещё 10% сверху.
В случае с preload результаты будут сильно зависеть от количества подключаемых файлов и сложности исполняемой логики: если подключается много файлов, а логика простая, preload даст больше, чем если файлов мало, а логика сложная.
Нюансы preload
У того, что увеличивает производительность, обычно есть обратная сторона. У preload есть множество нюансов, которые я приведу ниже. Их все нужно учитывать, но только один (первый) может быть принципиальным.
Изменение — перезапуск
Так как все preload-файлы компилируются только при запуске, помечаются как immutable и не перекомпилируются в дальнейшем, единственный способ применить изменения в этих файлах — перезапустить (reload или restart) PHP-FPM/Apache/и т. п.
В случае reload PHP старается произвести перезапуск максимально аккуратно: запросы пользователей не будут оборваны, но тем не менее, пока идёт preload-фаза, все новые запросы будут ждать её завершения. Если в preload будет не много кода, это может не доставить проблем, но если попытаться загрузить всё приложение, то это чревато значительным увеличением времени ответа во время перезапуска.
Также у перезапуска (вне зависимости от того, reload это или restart) есть важная особенность — в результате этого действия очищается OPcache. То есть все запросы после него будут работать с холодным опкод-кешем, что может увеличить время ответа ещё больше.
Неопределённые символы
К счастью, preload содержит достаточно инструментов для понимания того, получилось разрезолвить что-то или нет. Во-первых, это warning-сообщения с информацией о том, что не удалось подгрузить и почему:
Во-вторых, preload добавляет отдельную секцию в результат функции opcache_get_status(), в которой видно, что было успешно загружено в фазе preload:
Оптимизация полей/констант класса
Как я писал выше, preload резолвит значения полей/констант класса и сохраняет их. Это позволяет оптимизировать код: во время обработки запроса данные уже готовы и их не нужно выводить из других данных. Но это может приводить к неочевидным результатам, которые демонстрирует следующий пример:
Получается контринтуитивная ситуация: казалось бы, константы должны быть равны, так как одной из них присваивалось значение другой, но на деле это оказывается не так. Связано это с тем, что глобальные константы, в отличие от констант/полей класса, принудительно очищаются после окончания фазы preload, в то время как константы/поля класса — резолвятся и сохраняются. Это приводит к тому, что во время выполнения запроса нам приходится определять глобальную константу заново, в результате чего она может получить другое значение.
Cannot redeclare someFunc()
В случае с классами ситуация простая: обычно мы не подключаем их в явном виде, а пользуемся автолоадером. Это означает, что если класс определён в фазе preload, то во время запроса автолоадер просто не выполнится и мы не будем пытаться подключить этот класс второй раз.
С функциями ситуация иная: мы должны подключать их явно. Это может привести к ситуации, когда мы в preload-скрипте подключим все необходимые файлы с функциями, а во время запроса попытаемся сделать это снова (типичный пример — загрузчик Composer’а: он всегда будет пытаться подключить все файлы с функциями). В таком случае мы получим ошибку: функция уже была определена и переопределить её нельзя.
Решить эту проблему можно по-разному. В случае с Composer’ом можно, например, подключить вообще всё в preload-фазе, а во время запросов не подключать вообще ничего, что относится к Composer’у. Другое решение — не подключать файлы с функциями напрямую, а делать это через прокси-файл с проверкой на function_exists(), как, например, делает Guzzle HTTP.
PHP 7.4 ещё официально не вышел (пока)
Этот нюанс станет неактуальным через какое-то время, но пока версия PHP 7.4 ещё официально не вышла и команда PHP в release notes явно пишет: «Please DO NOT use this version in production, it is an early test version». Во время наших экспериментов с preload мы наткнулись на несколько багов, сами фиксили их и кое-что даже отправили в апстрим. Чтобы избежать неожиданностей, лучше дождаться официального релиза.
RoadRunner
RoadRunner — это демон, написанный на Go, который, с одной стороны, создаёт PHP-воркеры и следит за ними (запускает/завершает/перезапускает по мере необходимости), а с другой — принимает запросы и передаёт их на выполнение этим воркерам. В этом смысле его работа ничем не отличается от работы PHP-FPM (где тоже есть мастер-процесс, который следит за воркерами). Но отличия всё-таки есть. Ключевое заключается в том, что RoadRunner не обнуляет состояние скрипта после окончания выполнения запроса.
Таким образом, если вспомнить наш список того, на что тратятся ресурсы в случае «классического» PHP, RoadRunner позволяет бороться со всеми пунктами (preload, как мы помним, — только с первым):
Мы будем пытаться наш текущий endpoint, который мы тестировали с preload, без модификаций запустить на RoadRunner, нагружать его и измерять производительность. Без модификаций — потому что в противном случае бенчмарк будет не совсем честным.
Давайте попробуем адаптировать Hello World-пример для этого.
Во-первых, как я писал выше, мы не хотим, чтобы воркер падал в случае ошибки. Для этого нам нужно всё обернуть в глобальный try..catch. Во-вторых, поскольку наш скрипт ничего не знает о Zend Diactoros, для ответа нам нужно будет его результаты сконвертировать. Для этого воспользуемся ob_- функциями. В-третьих, наш скрипт ничего не знает о сущности PSR-7 запроса. Решение — заполнить стандартное PHP-окружение из этих сущностей. И в-четвёртых, наш скрипт рассчитывает на то, что запрос умрёт и всё состояние очистится. Поэтому с RoadRunner нам нужно будет эту очистку делать самостоятельно.
Таким образом, изначальный Hello World-вариант превращается примерно в такой:
Бенчмарки RoadRunner
Ну что, пришло время запускать бенчмарки.
Результаты не соответствуют ожиданиям: RoadRunner позволяет нивелировать больше факторов, вызывающих потери производительности, чем preload, но результаты в итоге оказываются хуже. Давайте разбираться, почему так происходит, как всегда, запустив для этого perf.
В результатах perf мы видим phar_compile_file. Это вызвано тем, что мы подключаем некоторые файлы во время выполнения скрипта и, так как OPcache не включён (RoadRunner запускает скрипты как CLI, где OPcache по умолчанию выключен), эти файлы компилируются заново при каждом запросе.
Отредактируем конфигурацию RoadRunner — включим OPcache:
Эти результаты уже больше похожи на то, что мы ожидали увидеть: RoadRunner начал показывать бОльшую производительность, чем preload. Но, возможно, нам удастся получить ещё больше!
В perf вроде бы нет больше ничего необычного — давайте посмотрим на PHP-код. Самый простой способ профилировать его — это использовать phpspy: он не требует никакой модификации PHP-кода — нужно просто запустить его в консоли. Сделаем это и построим flame graph:
Так как логику нашего приложения мы договорились не модифицировать для чистоты эксперимента, нас интересует ветка стеков, связанная с работой RoadRunner:
Основная часть её сводится к вызову fread(), с этим вряд ли что-то можно сделать. Но мы видим какие-то ещё ветки в \Spiral\RoadRunner\PSR7Client::acceptRequest(), кроме самого fread. Понять их смысл можно, заглянув в исходный код:
Становится понятно, что RoadRunner по рассериализованному массиву пытается создать объект PSR-7-совместимого запроса. Если ваш фреймворк работает с PSR-7-объектами запросов напрямую (например, Symfony не работает), то это вполне оправданно. В остальных случаях PSR-7 становится лишним звеном перед тем, как запрос будет сконвертирован в то, с чем может работать ваше приложение. Давайте уберём это промежуточное звено и посмотрим на результаты снова:
Тестируемый скрипт был достаточно лёгким, поэтому удалось выжать ещё весомую долю производительности — +17% по сравнению с чистым PHP (напомню, что preload даёт +10% на том же скрипте).
Нюансы RoadRunner
В целом использование RoadRunner — это более серьёзное изменение, чем просто включение preload, поэтому нюансы здесь ещё более значимые.
Во-первых, RoadRunner, по сути, запускает PHP-код в режиме демона, а это значит, что он подвержен всем проблемам, о которых я писал в начале статьи: появляется новый класс ошибок, которые можно допустить, код становится сложнее писать и отлаживать.
Во-вторых, если мы хотим выжать из RoadRunner максимум, то недостаточно просто запустить «классический» код на нём — нужно изначально писать код под него. В таком случае мы избежим хаков с перегоном запроса/ответа между форматами RoadRunner и приложения; возможно, мы сразу будем писать код так, чтобы ему не потребовалась очистка в конце запроса, а также сможем в большем объёме использовать возможности общей памяти между запросами, например что-то кешируя в ней.
В-третьих, все результаты были получены на нашем конкретном endpoint’е, который, возможно, не лучший кандидат для запуска под RoadRunner. На других скриптах возможны абсолютно другие результаты.
Заключение
Итак, мы рассмотрели архитектуру «классического» PHP, разобрались с тем, как ей может помочь preload и чем от неё отличается архитектура RoadRunner.
PHP в «классическом» варианте использования (PHP-FPM, Apache mod_php и другие) помогает упростить разработку и избежать ряда проблем. В случае если бэкенд не имеет каких-то особых требований к производительности, это самый эффективный способ разработки из рассмотренных. Кроме того, придумано множество способов выжать из этого решения максимум производительности, к которым уже добавился preload и скоро добавится JIT.
Если изначально понятно, что бэкенд будет нагружен, возможно, имеет смысл сразу смотреть в сторону RoadRunner, так как он потенциально может дать ещё больше производительности.
Ещё раз приведу результаты, полученные в ходе наших экспериментов (повторюсь: с большой долей вероятности прирост будет разный в зависимости от приложения):
RoadRunner мы пока не нашли эффективного применения, но теперь знаем, как он работает и чего от него можно ожидать, и можем его применить в будущем, если это потребуется.
Как перезагрузить службу php7.0-fpm / php5.0-fpm
Я являюсь новым пользователем системы Linux и Unix. Я хочу перезагрузить или перезапустить службу PHP-fpm. Как перезапустить PHP-fpm? Как перезапустить php7.0-fpm на сервере Ubuntu Linux 16.04 LTS?
PHP-FPM — это простой и надежный менеджер процессов FastCGI для PHP. Вы можете использовать его с Apache, Nginx и другими веб-серверами. Он включает в себя множество дополнительных функций. Посмотрим, как остановить или перезапустить или перезагрузить PHP-FPM после обновления файла php.ini.
Как отредактировать файл php.ini или www.conf?
Чтобы изменить php.ini:
Чтобы отредактировать файл конфигурации php-fpm:
После редактирования сохраните и закройте файл. Теперь вам нужно запустить команду в соответствии с версией дистрибутива Linux / Unix после редактирования файла.
Запустите php-fpm на CentOS / RHEL 7
Остановить php-fpm CentOS / RHEL 7
Перезагрузить php-fpm CentOS / RHEL 7
Перезапустите php-fpm CentOS / RHEL 7
Запуск / остановка / перезапуск / перезагрузка php-fpm на CentOS / RHEL 6.x или старше
Введите следующую команду:
Как запустить / остановить / перезагрузить / перезапустить php5-fpm (версия php 5.x) на Ubuntu / Debian Linux
ИЛИ, если вы используете дистрибутив на основе systemd, такой как Ubuntu Linux 16.04+ LTS или Debian Linux 8.x +:
Как запустить / остановить / перезагрузить php7.0-fpm (php version 7.x) на Ubuntu / Debian Linux
ИЛИ, если вы используете дистрибутив на основе systemd, такой как Ubuntu Linux 16.04+ LTS или Debian Linux 8.x +:
How to reload/restart php7.0-fpm / php5.0-fpm service
How do I edit php.ini or www.conf file?
To edit php.ini type:
$ sudo vi /etc/php5/php.ini
OR
$ sudo vi /etc/php/7.0/fpm/php.ini
To edit php-fpm config file:
$ sudo vi /etc/php/7.0/fpm/php-fpm.conf
$ sudo vi /etc/php/7.0/fpm/pool.d/www.conf
Once edited, save and close the file. Now you need to run command as per your Linux/Unix distro version after editing the file.
Start php-fpm on CentOS/RHEL 7
$ sudo systemctl start php-fpm
Stop php-fpm CentOS/RHEL 7
$ sudo systemctl stop php-fpm
Reload php-fpm CentOS/RHEL 7
$ sudo systemctl reload php-fpm
Restart php-fpm CentOS/RHEL 7
$ sudo systemctl restart php-fpm
Start/stop/restart/reload php-fpm on CentOS/RHEL 6.x or older
Type the following command:
$ sudo service php-fpm start #
$ sudo service php-fpm stop #
$ sudo service php-fpm restart #
$ sudo service php-fpm reload #
How to start/stop/restart/reload php5-fpm (php version 5.x) on Ubuntu/Debian Linux
$ sudo service php5-fpm start
$ sudo service php5-fpm stop
$ sudo service php5-fpm restart #
$ sudo service php5-fpm reload #
OR if you are using systemd based distro such as Ubuntu Linux 16.04+ LTS or Debian Linux 8.x+:
$ sudo systemctl start php7.0-fpm.service
$ sudo systemctl stop php5-fpm.service
$ sudo systemctl restart php5-fpm.service #
$ sudo systemctl reload php5-fpm.service #
How to start/stop/restart/reload php7.0-fpm (php version 7.x) on Ubuntu/Debian Linux
$ sudo service php7.0-fpmstart
$ sudo service php7.0-fpm stop
$ sudo service php7.0-fpm restart #
$ sudo service php7.0-fpm reload #
OR if you are using systemd based distro such as Ubuntu Linux 16.04+ LTS or Debian Linux 8.x+:
$ sudo systemctl start php7.0-fpm.service
$ sudo systemctl stop php7.0-fpm.service
$ sudo systemctl restart php7.0-fpm.service #
$ sudo systemctl reload php7.0-fpm.service #
The syntax is:
# /etc/init.d/php-fpm start
# /etc/init.d/php-fpm stop
# /etc/init.d/php-fpm restart #
The syntax is
# /usr/local/etc/rc.d/php-fpm start
# /usr/local/etc/rc.d/php-fpm stop
# /usr/local/etc/rc.d/php-fpm reload #
# /usr/local/etc/rc.d/php-fpm restart #
OR use the service command:
# service php-fpm start
# service php-fpm stop
# service php-fpm restart
# service php-fpm reload
🐧 Get the latest tutorials on Linux, Open Source & DevOps via
Конфигурация времени выполнения
Содержание
User Contributed Notes 14 notes
For those people who want to use the PHPRC environment variable:
You have to specify the path to the directory containing your php.ini, not the direct path to the php.ini.
Example (php.ini resides in /your/path/php.ini):
right:
export PHPRC=/your/path
Be sure to use double quotes in the php.ini file. For instance:
(lines broken for readability)
this will work:
# xdebug debugging
zend_extension=»/usr/local/php5/lib/php/extensions
/no-debug-non-zts-20060613/xdebug.so»
this won’t:
# xdebug debugging
zend_extension=’/usr/local/php5/lib/php/extensions
/no-debug-non-zts-20060613/xdebug.so’
You’ll get this error:
Failed loading ‘/usr/local/php5/lib/php/extensions/
no-debug-non-zts-20060613/xdebug.so’: (null)
So. double quotes are the way! I know this is obvious, but it’s a good thing to remember for the php.ini file.
In order to get PHP 5.2 stable running on Windows Server 2003 x64 (IIS 6.0), I discovered three things (in addition to the other comments above):
* Some PHP web applications make use of the SCRIPT_NAME server variable which is not available under CGI. You have to use php5isapi.dll, which is a 32 bit dll, so you have to run IIS in 32 bit mode. Confer http://support.microsoft.com/kb/894435. This applies to all ISAPI extensions and not just ASP.NET.
* It appears you must leave the doc_root entry in php.ini blank. At least, that is what finally made my installation work. (Note that others have suggested to set it to e.g. C:\inetpub\wwwroot or equivalent. That won’t work if your server hosts more than one domain, each placed in a separate directory.)
* If you are e.g. using MySQL you will have to edit php.ini. In order for it to be found, you must set the PHPRC system environment variable or the registry entry. Note that if you edit the registry using regedit.exe, the PHP key should be placed under the [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node] key. This happens automatically if you set it using a 32 bit legacy application.
About Apache 2.0 module:
For whatever reason, the Windows installer for PHP/5.2.3 tries to set the PHPIniDir directive using «\\» as directory separator:
PHPIniDir «C:\\Archivos de programa\\PHP\\»
It didn’t work for me until I edited httpd.conf and replaced it with «/»:
PHPIniDir «C:/Archivos de programa/PHP/»
To run separate apache and php processes on centos (at least) without
having to compile and install separate versions for every instance
this should work:
Install apache and php with yum.
This will give you (for the first instance):
/etc/httpd/*, /etc/sysconfig/httpd, /etc/init.d/httpd, /etc/php.ini
and /etc/php.d/*.
Copy all this stuff to:
/etc/httpd2/*, /etc/sysconfig/httpd2, /etc/init.d/httpd2, /etc/php2.ini
and /etc/php2.d/*.
Edit the apache config files in /etc/httpd2/* to reflect the new
ports you want to have this apache listen on (don’t forget ssl.conf
under conf.d) and any other differing settings, like log file
destinations and virtualhosts.
Edit the php2.ini for any specific settings you want the other php
instance to have.
To have a completely separate php in this new apache instance with its own
modules included, edit /etc/sysconfig/httpd2 and add the following:
PHPRC=/etc/php2.ini
export PHPRC
PHP_INI_SCAN_DIR=/etc/php2.d
export PHP_INI_SCAN_DIR
This will set the environment variables for the second apache/php
instance before it is started.
Then edit /etc/init.d/httpd2 and change all references to httpd
(like lockfile, pidfile and sysconfig) to httpd2. Don’t touch the
executable name, though 🙂
.. so this apache can find its own configuration file.
Please try this: set Apache2.2 service Startup Type to MANUAL. If not, it does not see to reload php.ini, no matter how many times you stop and start.
For windows with limited file permission (Windows XP)
1. Install Apache in your folder profile «C:\Documents and Settings\your_profile»
2. Add the following directives to you httpd.conf
PHPINIDir «C:\Documents and Settings\your_profile\php»
LoadModule php5_module «C:\Documents and Settings\your_profile\php\php5apache2_2.dll»
3. Edit the following directive to you php.ini
extension_dir = «C:\Documents and Settings\your_profile\php\ext»
4. Move the file libmysql.dll from C:\Documents and Settings\your_profile\php\ to C:\Documents and Settings\your_profile\php\ext\
5. Restart httpd using command line
w2k, apache 1.3.29, php 5.2.6: c:\php\php.ini was not found until the environment variable PHPRC was set to «c:\php», even though php was used as a module, not CGI.
just adding c:\php to the path was not adequate.
phpinfo() still shows «Configuration File (php.ini) Path» to be C:\WINNT, but «Loaded Configuration File» now correctly displays «C:\php\php.ini».
initially the problem appeared to be simply that the mysql extension was not loading; in fact, the problem was more fundamental (php.ini not found) but because php will still work with defaults, this was not obvious.
Run php 4 and php 5.2.x on the same machine with IIS 6.0 as ISAPI.
1. Extract the ZIP packages of both php 4 & php 5 (not the Windows Installer) to c:\php4 & c:\php5 respectively
2. Setup the corresponding php.ini files in c:\php4 and c:\php5
3. Add the Web Service Extensions for php4 and php5. For php4 use c:\php4\sapi\php4isapi.dll, php5 use c:\php5\php5isapi.dll
4. Add the following registry keys:
5. Add c:\php4 to the PATH environment variable.
6. Associate each web site in IIS with the corresponding php version.
Note: That should work, test with phpinfo() in each site. You may need to refer to the php documentation if we missed any other settings.
Setting php.ini location for PHP working as Apache module (without use SetEnv directive in httpd.conf):
Before start Apache, set the PHPRC environment variable to the path where php.ini should be loaded, for example:
PHPRC=/etc/php4/apache-another-path
export PHPRC
In Debian we can do this way:
In /etc/init.d/apache (the script that loads apache web server) we have this line: