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
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
The Problem:
Exactly as it says. My phpinfo.php file contains the following:
<?php phpinfo(); ?>
The file itself is located in /var/www/html/info.php.
What I did (prior to the problem):
I erased all installations of PHP, oci8, and what not. I'm not sure if I did a good job - basically, I typed in yum history and then undid every install relating to PHP.
This was so I could have a clean system (supposedly), before trying all the PHP stuff again, without resorting to a reformat - I had Oracle 11g and apache already setup there.
Take note, before this complete wipeout, said file up there was working fine.
To install PHP with oci8, I followed a guide here, with some differences, but I'll list it down, just the same.
yum install php-pear
yum install php-devel
pear download pecl/oci8
tar xvzf oci8-2.0.6.tgz
cd oci8-2.0.6
phpize
./configure --with-oci8=$ORACLE_HOME
make
make install
setsebool -P httpd_execmem 1
Afterwards, I added the following at the very end of /etc/php.ini file:
[OCI8]
extension=oci8.so
Then, I restarted apache via service httpd restart.
And then, I encountered the problem.
The System:
Fedora 19 x86_64
Oracle 11g
Apache 2.4.6
What I tried:
I thought at first it was Konqueror's problem. Fiddling with the View settings sometimes fixed it - most of the time, it did nothing.
So I installed Google Chrome, which displayed the same thing.
At this point I went, what the heck, I just installed php via yum install php. Maybe php-pear or php-devel on its own is not enough to run a php file.
No dice. All I wanted was to start over and install PHP with oci8 from scratch.
It appears PHP itself has a problem, and I'm stuck. A bit of research online says something about the tags, that php can't run <?.... ?>, as opposed to <?php ..... ?>, but as you can see with my phpinfo example, it didn't help much.
Other Information:
I get this from PHP's error log. I'm not sure if it means anything, as I recall seeing something like this back before I nuked my system, but perhaps they can be of some use.
AH01276: Cannot serve directory /var/www/html/: No matching
DirectoryIndex (index.html,index.php) found, and server-generated
directory index forbidden by Options directive
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
They don't seem to appear in the error log at any predictable frequency - loading up any PHP file or restarting apache are the only two things I've done.
It's not the browser. Probably, you don't have php module activated in your Apache. Look at your httpd.conf, and put the following lines there:
# Load the PHP module:
LoadModule php5_module lib/httpd/modules/libphp5.so
# Tell Apache to feed all *.php files through PHP. If you'd like to
# parse PHP embedded in files with different extensions, comment out
# these lines and see the example below.
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
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.
I want to try the ZeroMQ, and I write two php file, service.php and client.php.
I use the linux terminal to run service php /web/test/service.php,it's ok, terminal print a "waiting for client connecting...".
but, I request my client.php through chrome explorer,error happened, I check my error.log,there is message "php fatal error: class 'ZMQContext' not found........"
and I use command php -m to check my php extension, zmq is already in that list.
The problem is that the ZMQ module is loaded in the PHP CLI (Command Line Interface) but it's not loaded into Apache. Therefore, service.php runs smoothly from the Command Line but client.php can't use ZMQContext because Apache does not load ZMQ.
There are two different .ini-files. These probably are (but can be different, depending on your distro):
/etc/php5/apache2/php.ini for Apache
/etc/php5/cli/php.ini for CLI
However, all .ini files from the /etc/php5/conf.d/ directory are loaded into both Apache and the CLI.
See also: PHP - An external Class/library is accessible from apache but not from phpunit (the exact opposite of your problem)
Check which php.ini files are loaded
Checking (with phpinfo) which php.ini files are loaded when requested via nginx (which probably means via php-fpm) - will almost certainly reveal that it loads different ini files than the cli. Assuming php-fpm usage, the following ini files are probably loaded:
/etc/php5/fpm/php.ini
/etc/php5/fpm/conf.d/*
and no zmq.ini file listed.
Loading zmq for php-fpm
Follow the instructions for installing zmq on php, and create an ini file for zeromq (or copy the one from /etc/php5/cli/conf.d/ since evidently it's loaded for cli usage):
# /etc/php5/conf.d/zeromq.ini
extension=zmq.so
Then restart php-fpm
sudo /etc/init.d/php5-fpm restart
And zeromq should be available for use.
A really easy way to solve this issue is to enable ZMQ globally (cli + Apache) with phpenmod
For example with php5
php5enmod zmq
service apache2 restart