mod_php issue on Ubuntu

muscas

New member
Joined
Nov 14, 2021
Messages
2
I've installed DirectAdmin on a fresh Ubuntu 20.04 VPS and selected PHP 8 as mod_php.

Compiling PHP manually (select build in the Directadmin web console), Apache works and serves PHP pages.

If I then do a ./build rewrite_confs the mod_php setting seems to get disabled, and Apache fails to start. To fix I rebuild PHP, and it all works again.

possible bug?
 
YUP WHILE MOD_PHP is way to old and other problems you don't want.
So very important advice!

Stop using mod_php!

Just to add on these answers is that, mod_php is the oldest and slowest method available in HTTPD server to use PHP. It is not recommended, unless you are running old versions of Apache HTTPD and PHP. PHP-FPM and proxy_cgi are the preferred methods.
mod_php is a PHP interpreter.
From docs, one important catch of mod_php is,
"mod_php is not thread safe and forces you to stick with the prefork mpm (multi process, no threads), which is the slowest possible configuration"
2016:
For servers launched after this announcement dated August 23rd, 2016, PHP-FPM has been enabled by default. For new server instances, mod_PHP has been retired by default
 
Last edited:
oldest and slowest method available in HTTPD
Nope! Well... I don't know where you read that but that is certainly not true, old yes, slow really not. It all depends on what you're running and mod_php and php-fpm are the 2 most used ways to run php. But it's certainly safe and good to use, at least if you use mod_ruid2 in combination with it.
Old doesn't mean it's not good.

There are some downsides to mod_php for example you can't use multiple php versions, it uses more memory and it does not support http/2.

2019:
In theory, mod_php is the fastest achievable. With mod_php the web server and interpreter directly communicate, they share the same resources and memory space. With ext-fpm you have separate processes that communicate not as directly and that must duplicate resources.
It just depends where you read.

So it's not dangerous, it's quite fast and you can still use it very good, in combination with mod_ruid2.

However, to be more flexible and modern, to be able to use http/2 and to be able to run more php versions (which will be nice for your customers), you might better choose to run php-fpm. Which is indeed often used by default nowadays.
 
There are some downsides to mod_php for example you can't use multiple php versions, it uses more memory and it does not support http/2.

2019:
With mod_php the web server and interpreter directly communicate, they share the same resources and memory space. With ext-fpm you have separate processes that communicate not as directly and that must duplicate resources.

It just depends where you read.
Or HOW you use / read it hihi ;)

So mod_php " they share the same resources and memory space" therefore you need then extra to be on somewhat more safe site , but on shared server it should be a nogo. in my reading and mind.
 
The reason behind using mod_php has to do with this and its not a shared server as it just manages this one application.
 
but on shared server it should be a nogo. in my reading and mind.
I think you read it the wrong way. We used this for many years on shared servers and before php-fpm a few years ago it was also default here at DA.
As you know when I had issues with php-fpm and PHP getting error 50 codes, I changed back to mod_php with mod_ruid2 and things went smoothly and the error almost did not occur anymore.

No need to use bold characters. It's -your- opinion. Php-fpm has advantages nowadays, but that is no reason to call mod_php with mod_ruid2 unsafe or slow, because it's certainly is not.
 
No need to use bold characters. It's -your- opinion. P
Sorry i use bold in more easy way not to be "angry" or strongly .....

i mean yes with extra as modruid , but php-fmp shouldn't give errors normaly , if changed updated from a situation before yup it can be hard to look / find where while you also have applications itself...
 
Back
Top