Вопрос 1 . После установки php5-fpm в директории /etc/php5/fpm/ лежит файл php.ini . В этот файл я добавил несуществующую команду, добавил руский тект, перезапустил php5-fpm - и он нифига не ругнулся. Отсюда делаем вывод, что этот файл php-fpm не читает. Тогда для чего нужен этот файл и как его подключить ?

Вопрос 2 . Согласно вот этой статье: https://docs.newrelic.com/docs/agents/php-agent/configuration/php-directory-ini-settings
php-fpm позволяет прописывать php-настройки 3 способами:

1) директивы php_value / php_admin_value / php_flag / php_admin_flag в конфигурационном файле пула /pool.d/pool.conf
2) использование классических ini-файлов в директориях сайта (в которых запускаются php-скрипты) - аналог Apache'вских
3) директива fastcgi_param PHP_VALUE... в конфигурационном файле веб-сервера
.htaccess .

Первый вариант НЕКОШЕРНЫЙ по той причине, что FPM при запуске проверяет только синтаксис своих директив, успешно "проглатывая" и упразднённые php-опции, и вообще не существующие. И корректность значений не проверяет. Т.е. получается, что прописываем php-настройки "вслепую", без всякого контроля. так очень легко допустить ошибку и о ней ничего известно не будет. Тогда как классический fcgi-php при запуске проверяет семантику директив (корректность, существование) + допустимость значений.

Второй вариант - тоже НЕ ГОДИТСЯ, т.к. добавляет лишнюю нагрузку на сервер (чтение и парсинг локального конфига)
Ну а 3-й вариант - имеет те же проблемы, что и 1-й.

Единственный приемлемый вариант - подключение классического ini-файла, но так, чтобы при запуске php-fpm проверял корректность директив (опций) и их значений. Как этот сделать ?

авторПервый вариант НЕКОШЕРНЫЙ по той причине, что FPM при запуске проверяет только синтаксис своих директив, успешно "проглатывая" и упразднённые php-опции, и вообще не существующие. И корректность значений не проверяет. Т.е. получается, что прописываем php-настройки "вслепую", без всякого контроля. так очень легко допустить ошибку и о ней ничего известно не будет. Тогда как классический fcgi-php при запуске проверяет семантику директив (корректность, существование) + допустимость значений.Всё-таки, на упразднённые и несуществующие php-опции php-fpm ругается (чтобы писались логи php-fpm , в конфигурационном файле пула нужно включить опцию catch_workers_output = yes , по умолчанию отключена): ERROR: Unable to set php_admin_value ...

Но тип значений (число/строка или булевское значение) - не проверяет. Т.е. можно спокойно прописать php_value для булевских значений и php_flag для строк и чисел (и вообще, любые недопустимые значения прописать) - php-fpm промолчит и никаких ошибок и предупреждений не сгенерирует.

нет. нужно на этапе запуска php-fpm

авторНо тип значений (число/строка или булевское значение) - не проверяет. Т.е. можно спокойно прописать php_value для булевских значений и php_flag для строк и чисел (и вообще, любые недопустимые значения прописать) - php-fpm промолчит и никаких ошибок и предупреждений не сгенерирует. Офигеть. Булевский тип в php - это и 0/1 , и "0"/"1" , и True/False , и On/Off . Вот для этих 4 случаев какую директиву использовать - php_[admin_]value или php_[admin_]flag ?

Например, cgi.fix_pathinfo имеет булевский тип, но в описании идёт речь о значениях 0 и 1:
http://php.net/manual/ru/ini.core.php#ini.cgi.fix-pathinfo

register_globals тоже имеет булевский тип, но в описании идёт речь о значениях On и Off
http://php.net/manual/ru/ini.core.php#ini.register-globals

session.cookie_httponly имеет значение по умолчанию "" , при этом тип - булевский:
http://php.net/manual/ru/session.configuration.php#ini.session.cookie-httponly

И вообще, в справке про булевский тип написано: константы True и False . Если предположить, что значением этих констант являются числа 0 и 1, то куда "вписать" значения On, Off, "", "0", "1" ?

авторНе в PHP, а в конфигах его. И не только в его конфигах, а и во многих других.Опечатка. Хотел написать "в php-fpm" (имея ввиду его конфиги).

Так какую директиву использовать для каждого из этих "булевских" значений - ..._value или ..._flag ?
- 0/1
- "0"/"1"
- True/False
- On/Off

авторДокументация даёт на этот вопрос однозначный ответ:Только эта самая документация не говорит о том, что понимать под "логическим значением" в контексте рассматриваемых директив.

Пустая строка - это "логическое значение" ?
Строка "1" - это "логическое значение" ?

session.cookie_httponly имеет значение по умолчанию "", при этом тип - булевский:
http://php.net/manual/ru/session.configuration.php#ini.session.cookie-httponly

Всё-таки, php.ini применяется (либо путь указывается при компиляции, либо прописан в параметрах запуска сервиса /usr/lib/systemd/system/php-fpm.service ). Но на наличие ошибок в этом файле реагирует очень слабо. В частности, при указании несуществующей опции никаких ошибок в логи не выводит (в т.ч. в syslog ).

Что касается собственных настроек php-fpm , то ведёт он себя не совсем надёжно:
- Если вместо php_value указать php_flag , то будет сгенерирована критическая ошибка " invalid boolean value "
- Если вместо php_flag указать php_value , то никаких ошибок и предупреждений получено не будет, при этом значение будет корректно считано как булевское (понимает и "on"/"off", и "0"/"1")
- Если вместо php_admin_... указать php_... (без " admin "), то никаких ошибок и предупреждений получено не будет, но и значение присвоено тоже не будет
- Если использовать php_admin_... с опцией типа " PHP_INI_ALL ", то никаких проблем не возникает (единственная штатная ситуация из четырёх перечисленных)

автор- Если вместо php_admin_... указать php_... (без "admin"), то никаких ошибок и предупреждений получено не будет, но и значение присвоено тоже не будетТ.е. при настройке php в конфигурационный файлах php-fpm необходимо тщательно следить за типом опции ( PHP_INI_ALL , PHP_INI_SYSTEM и пр.).

Более того, в общем случае даже наличие некоторой настройки в phpinfo вовсе не гарантирует, что эта настройка применяется. Наличие некоторой настройки в phpinfo говорит лишь о корректном считывании её php-интепретатором ( php-fpm ), но не о применении. Пример тому - некоторые http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1237934&msg=19876966] opcache -настройки (например, opcache.interned_strings_buffer ) .

авторТут хотелось бы уточнить один момент. Вывод phpinfo() Вы смотрите в отдельном тестовом скрипте или непосредственно в том скрипте, где обнаружили, что настройки не применились? В отдельном.

авторСам механизм fpm, если правильно понимаю его внутреннюю кухню, запускает отдельный новый процесс или, вернее, пачку процессов php, которые на старте прочитывают и отрабатывают конфиг. Далее каждый процесс должен отработать какое-то количество запросов и завершить своё существование. На смену приходит новый процесс с новой инициализацией. Вполне логично, что уже запущенный процесс может не изменить на лету некоторые свои настройки, особенно те, которые применимы только при запуске. Полагаю, для чистоты тестирования после замены конфига ранее существовавшие процессы php должны быть гарантировано прибиты, чтоб не нарваться на старичка-долгожителя со старыми настройками. При перезагрузке сервиса php-fpm выполняется физическое уничтожение и пересоздание главного и всех дочерних (рабочих) процессов.
Поэтому, описанная вами ситуация исключена.

Вообще, когда я писал, что " наличие некоторой настройки в phpinfo вовсе не гарантирует, что эта настройка применяется ", подразумевал вот это странное поведение - с некоторыми настройками opcache (в частности, opcache.interned_strings_buffer ).

Могу предположить что озвученное утверждение верно только для модулей, а не для ядра php . Т.е. предполагаю, что в случае с опцией opcache.interned_strings_buffer модуль opcache её не применяет, если она объявлена в конфигурационном файле php-fpm . Такая избирательность возможна в одном из следующих случаев:

а) модуль opcache считывает opcache -настройки самостоятельно (а не берёт из числа тех, что прочитал движок php ), причём из php.ini считывает все opcache -настройки, а из http.conf и конфигурационного файла пула - только те, что имеют тип PHP_INI_ALL ;

б) модуль opcache самостоятельно opcache -настройки не читает, а берёт их из числа тех, что прочитал движок php , при этом:
- opcache -настройки типа PHP_INI_ALL берёт из числа прочитанных движком php в самом конце, когда php уже прочитал все настройки - и php.ini , и конфигурационный файл пула;
- opcache -настройки типа PHP_INI_SYSTEM берёт из числа прочитанных движком php чуть ранее - в тот момент когда php прочитал php.ini , но ещё не успел прочитать конфигурационный файл пула (если сначала читается php.ini , затем http.conf и конфигурационный файл пула)

Здесь в понятие "движок php" ещё следует включить и механизм взаимодействия мастер-процесса php-fpm с дочерними (рабочими) процессами в плане чтения и обмена настройками. Если каждый из дочерних (рабочих) процессов самостоятельно читает настройки из php.ini , то мастер-процесс php-fpm должен им как-то передавать те php-настройки, которые были заданы в конфигурационном файле пула (к конфигурационному файлу пула, очевидно, имеет доступ только сам мастер-процесс php-fpm ). Если же php.ini читает сам мастер процесс php-fpm , то он должен передавать все прочитанные настройки своим дочерним (рабочим) процессам ( php.ini + наложение поверх них тех настроек, что указаны в конфигурационном файле пула).