~ # /etc/init.d/php-fpm start * Testing PHP FastCGI Process Manager configuration ... [31-Aug-2016 16:39:08] ERROR: failed to open error_log (/var/log/php-fpm/php-fpm.log): No such file or directory (2) [31-Aug-2016 16:39:08] ERROR: failed to post process the configuration [31-Aug-2016 16:39:08] ERROR: FPM initialization failed ~ # mkdir /var/log/php-fpm ~ # /etc/init.d/php-fpm start * Testing PHP FastCGI Process Manager configuration ... [ ok ] * Starting PHP FastCGI Process Manager ... The init script should check if the directory exist
I personally don't see how to reliably do this. The config is read from /etc/php/fpm-$(eselect php show fpm)/php-fpm.conf but error_log is not required to be defined and is in more of an "ini" format which OpenRC cannot parse afaik.
Did you change the error_log setting in your php.ini for php-fpm? I made the default error_log point to some place that exists in bug #572002, but since the setting is part of php.ini, the init script doesn't know about it. If you change it to a path under a non-existent directory, then for now, you have to create the parent directory yourself. The only way I can think of to work around that would be to have the init script learn to read php.ini. That gets tricky because if you ask PHP what the value of error_log is and it's using the compiled-in default, it returns the empty string. I can do something like, php -c /etc/php/fpm-php7.0/php.ini -r 'echo dirname(ini_get("error_log"));' and then create the directory after checking to make sure that it's non-empty. But, that requires the php CLI, and you're allowed to build php-fpm without the CLI... I'm open to ideas...
(In reply to Michael Orlitzky from comment #2) > Did you change the error_log setting in your php.ini for php-fpm? I made the > default error_log point to some place that exists in bug #572002, but since > the setting is part of php.ini, the init script doesn't know about it. If > you change it to a path under a non-existent directory, then for now, you > have to create the parent directory yourself. Michael, I believe this about php-fpm.conf which has it's own error_log setting for php-fpm alone. Unrelated to any pool or php.ini setting.
(In reply to Michael Orlitzky from comment #2) > Did you change the error_log setting in your php.ini for php-fpm? I confirm what Brian said in the comment #3
(In reply to Brian Evans from comment #3) > (In reply to Michael Orlitzky from comment #2) > > Did you change the error_log setting in your php.ini for php-fpm? I made the > > default error_log point to some place that exists in bug #572002, but since > > the setting is part of php.ini, the init script doesn't know about it. If > > you change it to a path under a non-existent directory, then for now, you > > have to create the parent directory yourself. > > Michael, > > I believe this about php-fpm.conf which has it's own error_log setting for > php-fpm alone. Unrelated to any pool or php.ini setting. Oops, change "php.ini" to "php-fpm.conf" everywhere in my comment then =) The syntax is the same though, so we have the same parsing problem. And this still works, php -c /etc/php/fpm-php7.0/php-fpm.conf -r 'echo dirname(ini_get("error_log"));' but we can't rely on the CLI being there.
Any ideas? Without a way to parse php-fpm.conf from the init script, we can't fix this there.
I really think it's better if we don't try to be clever about this. I've recently come across some vulnerabilities in other packages that resulted from parsing a config file in the init script. Here, basically, we would read the php-fpm.conf file, and then call "checkpath -d -m755" on its log directory. But for that to be safe, we need to know that the target directory should be world readable/traversable. Only root can write to php-fpm.conf out-of-the-box, so there's no real privilege escalation, but it could still be surprising and therefore dangerous to call checkpath as root on a path contained in some config file. If, for example, a web host allows developers to modify the PHP configuration -- that would give them root. We don't try to accommodate any other changes in php-fpm.conf; we won't create the FPM user/group for you, or create the socket directory for you... so this is consistent as well. I think the simplest and least-surprising thing to do is say "if you change error_log, you have to make sure the target directory exists."