I'm trying to set up a server environment where I would like to have php-fpm (7.0.0RC7) running along with nginx and have multi-threading option for command line. Hence I compiled php myself with zts enabled and got it running with my nginx server.
Problem is that when I enable pthreads extension, php-fpm would not start. Running commands such as 'php threads.php' (file consuming multiple threads), works fine though.
Is it possible to have a separate php.ini for php-fpm service? Or have a particular extension turned on/off for php-fpm?
Any pointers would be much appreciated!
From the manual page for configuration files:
If php-SAPI.ini exists (where SAPI is the SAPI in use, so, for example, php-cli.ini or php-apache.ini), it is used instead of php.ini. The SAPI name can be determined with php_sapi_name().
Related
I have a new server with CentOS 8, and I wanna have LAMP on it. In order to integrate PHP with Apache, I can remember there are two solutions: CLI and Apache module. But all howtos that I found are using php-fpm (which apparently is the CLI config with Apache).
I wanna know is there a way to config PHP as an Apache module on CentOS? If so, which package I should install using dnf?
One more thing, I can remember it was recommended to use PHP as an Apache module rather than using it as CLI. Is that still correct?
First thing - php-cli is meant for console operation without knowledge of HTTP request, HTTP server env variables and so on. It is used for CLI tasks like scripts run by CRON.
What you need is to have mod_php package installed. Then you have to enable (and configure) it within apache configuration.
According to this article the metapackage php should already include mod_php, so it should suffice to enable it.
The module can be enabled interactively using a2enmod or by adding config directives manually, like:
LoadModule php7_module /usr/lib/apache2/modules/libphp7.3.so
The example is not from Centos, so YMMV.
By php-cli, you probably meant php-cgi.
php-cli is meant for running scripts from within terminal, not to be invoked from web server.
mod_php is not threadsafe if used in threaded MPM like event.
For best performance you should try FPM, which is separate pool of workers that could be invoked via socket, regardless of actual MPM used by Apache.
I'm getting this PHP Warning:
Module 'pcntl' already loaded in Unknown on line 0
But it is only enabled for Apache. Enabled it on /etc/php/7.2/apache2/conf.d/20-pcntl.ini:
extension=pcntl.so
I don't have it enabled on CLI. Checked with:
I don't have a /etc/php/7.2/cli/conf.d/20-pcntl.ini file
Grep command grep -R extension=pcntl.so /etc/php/7.2 only returns the file on apache2 folder
If I disable this extension on Apache's .ini, it won't load on Apache but loads on Cli.
If I enable this extension on Apache's .ini, I get the module already loaded warning.
I'm need to enable PCNTL on Apache to use Spatie\Async library.
It's a Ubuntu 14 server.
Sometimes extensions are compiled into PHP rather than loaded as separate modules. Before fiddling with the PHP.ini files, you should probably run a quick PHP script to see what modules are loaded:
<?php
var_dump(get_loaded_extensions());
You should also beware of PHP directives like disable_functions which may be disabling the pcntl functions. On my Ubuntu workstation, the pcntl functions are disabled with this directive:
/etc/php5/apache2/php.ini:disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority
I suggest you try a broader grep search to see if pcntl gets mentioned in other places:
grep -ir pcntl.so /etc/php/7.2
I don't have a /etc/php/7.2/cli/conf.d/20-pcntl.ini file
That seems a bit weird to me. You might try searching for more php.ini files there:
sudo find /etc -name "php.ini"
You should also check to make sure that you aren't running a different PHP from the command line than you are with apache. Under certain circumstances (which regrettably happen more often that you might think) your CLI PHP is different than your Apache PHP. This article discusses that issue in more detail.
If I disable this extension on Apache's .ini, it won't load on Apache but loads on Cli.
That actually sounds reasonable to me. If I had to guess, I would say that the wise Ubuntu/Debian package manager folks decided it would be unwise to allow pcntl_x functions to run in an apache environment, especially given this stark and ancient warning. I don't recall if that warning is outdated now or not. I would refer you to this other thread where I asked some related questions and was told I should use PHP-FPM with apache in event mode.
All that said, I have had some tremendous success writing "multithreaded" applications in PHP (technically not multithreaded but rather multiprocessing) using pcntl_fork and posix_setsid and the like.
To summarize, I'm guessing that PCNTL is already loaded both on apache and cli and the wise Ubuntu devs probably disabled the pcntl functions in the php.ini.
I know this is long after the original post, but I faced a similar problem. I'm working on a AWS Linux AMI and pnctl seems to be pre-installed into php-cli (not loaded via php.ini)
The problem is Spatie async checks your PHP Runtime (PHP-FPM) to see if the pnctl and posix modules are loaded, which by default aren't even though they are available in php-cli which it actually uses when you create Spatie Async Pools.
My solution was to actually modify the php-fpm service to run with extension=pnctl.so
systemctl edit php-fpm
It will create an override file in /etc/systemd/system/
Modify the file by changing
ExecStart=/usr/sbin/php-fpm --nodaemonize to ExecStart=/usr/sbin/php-fpm -d extension=pctnl.so--nodaemonize and save that
Then restart your nginx and php-fpm services and pnctl should be active for PHP-FPM
i have installed php on windows just for having opportunity running php commands.
One of those commands required from me enabling few extensions (mbstring, openssl). I have enabled them in php.ini, but still it cant see it because php is not reloaded. I dont have any webservers on windows (no IIS, Apache, Nginx). How can i just reload php and php.ini without any webservers?
Thanks!
Use php.exe --ini to display what configuration files are being used and edit the correct php.ini file.
I am using Laravel 3 for a project, and I've made a little cronjob script, and when I moved to the new server it keeps saying:
Warning: ob_start(): function 'mb_output_handler' not found or invalid function name
and
Notice: ob_start(): failed to create buffer
Any idea how to fix this?
The new server is Ubuntu? Are your development server and the "new server" the same OS? Same PHP versions?
It's possible the two servers are completely different!
Can you show your cronjob? (Does it attempt to use a specific php binary via a #!/usr/bin/env php call ?
One possibility for Ubuntu:
PHP run in CLI can be different from being run in Apache, and especially is likely different if you're using php5-fpm with Nginx.
They each can have their own php.ini and different extensions loaded.
As you said, you're using Ubuntu Server. If you're using php 5.5, you may note a few things in /etc/php5:
/etc/php5/mods-available # All mods available / installed
/etc/php5/cli/php.ini # php.ini for CLI-called php5
/etc/php5/cli/conf.d # Directory of symlinks to extensions in mods-available!
/etc/php5/apache2/php.ini # php.ini for Apache-run php5
/etc/php5/apache2/conf.d # Symlinks to mods-available extensions
So, php in CLI vs Apache2 vs PHP-FPM can all have different extensions loaded and separated php.ini's installed.
Perhaps the cli-based one (likely what the cronjob is using) may be a different version of PHP (!) or loading a different .ini file and/or set of extensions.
We are having almost the same issue as this person:
OCI8 functions not found when run by apache with php5
The difference between their issue and ours is that we only have one php.ini (/etc/php.ini). We are running PHP 5.3.5 with Apache 2.2.3 on CentOS 5.5. As you can see, their question was never really answered but I hope y'all can help up with ours. Thanks!
I have found the cause of the issue but I do not know how to permenantly solve it. Apparently, our test server is using SELinux set to "Enforce". Setting it to "Permissive" allows Apache/PHP to run the oci8 extension. My boss, however wants SELinux set back to "Enforce" for which I do not blame her. I'm going to look into creating an exception for Oracle/oci8.
Re. SELinux and OCI8 when running as an Apache module
Suggested solution from http://old.nabble.com/php-with-oci8-td16460446.html
you can customize your policy to allow this access using audit2allow
# grep http /var/log/audit/audit.log | audit2allow -M myhttp
# semodule -i myhttp.pp
This should allow you to run these oracle apps with SELinux in enforcing
mode.
There's also a thread about this on the oracle forums
Ensure that you have ORACLE_HOME, ORACLE_SID and LD_LIBRARY_PATH in the Apache envvars. Remember that Apache is running as a daemon, so it doesn't necessarily have access to the same environment variables as when you run your PHP scripts from the command line.
ORACLE_HOME=/u01/app/oracle/product/10.1
ORACLE_SID=orcl
export ORACLE_HOME ORACLE_SID
export LD_LIBRARY_PATH=${ORACLE_HOME}/lib:${LD_LIBRARY_PATH}
Depending where your database server is and how you connect to it you may also want to set TWO_TASK or TNS_ADMIN. To ensure the correct character set is used, you may also want to set NLS_LANG.
EDIT
I normally build PHP from source, so I have full control:
Assuming that the standard Oracle Client is running on the server, then my ./configure includes:
--with-pdo-oci=$ORACLE_HOME
On the couple of occasions when I've needed to build for the Oracle instant client, I've used
--with-pdo-oci=instantclient,/usr,10.2.0.3
in my ./configure line
Note that I use PDO_OCI rather than OCI8, but the ./configure should be similar
The other step that I take when deploying to a new server is to ensure that the apache user/group (as defined by the User and Group directives in httpd.conf... my apache runs as user "daemon") will have read and execute privilege to the files under ORACLE_HOME