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.
Related
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've, somehow, managed to play with LUA on my local machine (Windows). Now I tried to put that on my dev server (Debian 9 with Apache 2.4.25 with PHP 7.0.27-0+deb9u1 and Lua 5.3.3).
After hours, dozens of errors and thousands of StackOverflow's pages read, I have finally been able to manually compile and build PECL lua-2.0.5 and successfully made apache module.
I used $ a2enmod lua. Now, on phpinfo() I see mod_lua along others Loaded Modules.
I can run lua scripts from cli. No problem here.
I can't use lua from PHP scripts:
Fatal error: Uncaught Error: Class 'Lua' not found in [...]
I can't use lua through Apache as well (through http://domain/path/to.lua), even after editing /etc/apache2/apache2.conf with new lines:
LoadModule lua_module modules/mod_lua.so
<Files "*.lua">
SetHandler lua-script
</Files>
None of the 4 line made any noticeable difference.
Running Lua scripts directly through Apache (from URL) is optional. But I really need to be able to interpret Lua from my PHP scripts. But even with mod_lua displayed in Loaded Modules in phpinfo(), PHP can't find class Lua. Why?
After building the extension it has to be enabled, some install scriptss do it for you.
depending on your OS the php.ini to do it could vary in mine (ubuntu 16) are
/etc/php/7.0/apache2/php.ini
/etc/php/7.0/CLI/php.ini
if it has multiple config options you can/should make a dedicated extensionname.ini under /etc/php/7.0/{CLI|apache2}/conf.d
shortcut from commandline
$ php -dextension=/path/to/extension.so
or
$ phpenmod extensionname
this one can be found as php5enmod for php5
edit: in your case as you noticed the line to add to the .ini is extension=lua.so
I'm installing php7.0-fpm on a Debian server. Do I also need to install the libapache2-mod-php7.0 package? The Debian package page for php7.0-fpm seems ambiguous to me. It says,
This package provides the Fast Process Manager interpreter that runs
as a daemon and receives Fast/CGI requests. Note that MOST Apache
users probably want the libapache2-mod-php7.0 package.
Does this mean most Apache users want the libapache2 package instead of php7.0-fpm or does it mean that most users also want to install the libapache package? What is the exact difference between what each of these packages does?
If you would like to use mod_php directly from Apache, then you want to use libapache2 package. This package requires that Apache run in single thread mode (Aka PreFork MPM). If you would like to use PHP with Nginx or Apache's threaded Worker MPM (with fastcgi), then you will want to use the FPM package. This has the advantage of using threads and recycling of php worker processes which, generally speaking, will yield far better performance.
I think the note "that MOST Apache users probably want the libapache2-mod-php7.0 package." is basically there because it is much easier to setup Apache for mod_php than it is for FastCGI so users using Apache tend to follow that approche. Setting up FPM with Nginx is far simpler and Nginx does a more efficient job of proxying the requests to the FPM process. If you are only using the web server to provide PHP execution and dont need some of the Apache specific bells and whistles, then you will probably be better off using Nginx in the long run.
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().
I am working to build a small email client inside a web application. After doing some research I attempted to use the imap function. I got an error saying I was calling an undefined function, so again I researched and uncommented extension=php_imap.dll.
I then found I had to update php with the imap function and I did so. Now, the imap functions works in php interactive inside Terminal, but I can't get it to work in the browser. I'm assuming I have to somehow load it in the Apache Config files but I can't seem to find how to do so.
Any Ideas?
You'll need to restart Apache to reload the PHP module with the new configuration. The command line PHP starts a new PHP instance each time with the latest configuration, whereas the PHP extension running in Apache is separate, and only loads new configuration setting when Apache itself is restarted.
Assuming you're running on Windows based on the .dll extension, so apachectl restart or apache2ctl restart may work, or the installer you used may have a tray app or other GUI tool that can do it for you.
If running on Linux sudo service apache2 restart or sudo service httpd restart depending on distribution.