php-fpm virtualmin feature request

This is something that Jamie has been looking into, though we don't have a status on all that yet.

It's under consideration, but due to the overhead of supporting new execution modes is unlikely to come any time soon unless there is a huge benefit from using php-fm over fcgid.

+1 - & with nginx ;)

oh what's that fcgi process already started by the nginx virtualmin module... ooh.. maybe somebody's done this.....

There is more chance of this happening for Nginx only, as it would replace the custom-built PHP multiprocess manager we already have.

Just adding my feature request (which was created before this one, but no response yet, lol).

https://www.virtualmin.com/node/22583

I believe (that is I read) one major benefit of FPM compared to FCGID would be the ability to use cache tools like APC efficiently (e.g. is APCis cache is shared, which is not possible with FCGID). That could speedup web sites significantly. Ubuntu 12.04 repos contain FPM fortunately.

Not to mention that APC will be integrated into PHP 6, PHP-FPM is the natural way to go...

thanks, i had seen that, but i am not confident enough to run non standard configs on production servers...

This would be a great feature, but I am not very optimistic. Only three users have supported this request so far :-)

Hi,

It would appear that PHP 5.3.3 comes bundled with php-fpm.

http://php.net/manual/en/install.fpm.php

and

http://php-fpm.org/

Not sure if this information helps in supporting the case or not.

-Peter

+2 .. this is one very importan function for my company .. we do Drupal development .. we tried to create one server with apache mod-ruid which is as fast as php-fpm .. but many things have gone wrong ... lots of manual work scripting is needed ... I try to setup one server with php-fpm manualy. Generaly on heavier drupal e-commerce sites there is 1-2 seconds difference in single page load !!

This is information for Jamie:

PHP-FPM is required for APC and other caching solutions.

To set things up, a single PHP-FPM process runs as root.

This process listens on multiple different ports like 9001, 9002, 9003 etc. Each port is set up to run as a specific user/group. This is all set up in the php-fpm config. Here's an example setup:

So that takes care of the security issues. Scripts will only be running as the appropriate user and cannot execute as root.

Next, make NGINX use the proper user-specific fastcgi handler based on virtual domain:

What this achieves:

• PHP-FPM manages the job of spawning PHP workers as required.
• Workers are spawned running as the appropriate users, thereby giving great security.
• The workers it spawns are very effective; they share memory and loaded PHP modules. This avoids memory bloat and gives faster process spawn times. Memory is only shared per-user, so security is strong. A user cannot read the caches of another user, for instance.
• This last point was the most important, because it means that bytecode caching modules like APC will work. Those modules require a single, shared cache. If PHP is running as mod_fcgi or regular fastcgi (as is the current default), you end up with 1 cache PER PHP process instead, which quickly explodes your entire server (100 connections with a 32 mb cache would require 3200 mb of RAM), and doesn't utilize the cache properly since each worker has its own cache and there will be lots of cache misses.

The latter point is why people want PHP-FPM. Being able to cache with bytecode caches like APC would give sites an average of 3-10x faster PHP execution, since there is no longer any need to re-compile every PHP script on every page load (which is akin to stopping a car's engine at every stoplight).

Actually implementing this in Virtualmin is ultra-easy. It just requires awareness of how to modify the php-fpm config files to add each new virtualserver, and setting the appropriate port in NGINX.

There is one major issue hindering adoption though: CentOS/RHEL doesn't build their PHP with FPM support (they don't do "--enable-fpm"), so an alternative repository would be required for installing a PHP binary with FPM support. This comes with a whole suite of security issues (you should never be on the latest bleeding-edge PHP version if you want a secure server), so personally I just accepted that I can't run APC as it is today. But maybe there will be a day that RHEL adds the simple "--enable-fpm" flag, we can dream... I think the only reason they haven't enabled it is because they're not aware that the config option has been added to PHP's build options as of 5.3.

Thanks for the info - php_fm support is still on our todo list, although lack of good distribution support makes it troublesome to support as we will have to implement fcgid as well..

Indeed. The distribution support is the major issue, otherwise I would be running it today. As it is, I'm not going to compromise security by jumping on the bleeding edge just for faster PHP execution. The risks are too great.

The FPM implementation was finalized a year ago http://php-fpm.org with PHP 5.4, which means that we might have to wait for RHEL 7/CentOS 7, when they're likely to switch to PHP 5.4 or higher.

I don't have any time, but I briefly considered solving this by writing a simple PHP module which would work without the stupid requirement of having to run every PHP worker within the same shared address space, basically as follows:

• Whenever the PHP interpreter requests a file, hook the call and see if we have it cached and if so, retrieve the cached bytecode, unless the file has been modified on disk, in which case we allow recompilation to take place.

• Whenever PHP finishes compiling a file, we store it in a single, shared memcached daemon (http://memcached.org), which all PHP workers communicate with using IPC.

• This daemon stores the compiled binary data for us in a global manner, thereby working with every method of running PHP, whether that be CLI, CGI, FastCGI, mod_php, or whatever. Doesn't even matter how many threads you are running. No shared memory is required for PHP or its modules.

• It would only do bytecode caching, not bytecode optimization. The compilation is the slow part and storing compiled results is what speeds up web applications by 3-10x. Further bytecode optimization only accounts for 1-5% or so speedup and is an acceptable loss compared to optimizing caches like APC.

• Thanks to only caching bytecode, it wouldn't need awareness of how to optimize around PHP's version-specific quirks and would work with every version of PHP.

Why haven't I done this? No time or enough inclination! :-)

But yeah, something like this is what would be required if people want bytecode caching today, without PHP-FPM...

Here is a good spot to stay up to date on the stability of the entire PHP 5.4/php-fpm/apc stack:

http://stackoverflow.com/a/10109553/139040

From what I gather the "combo" seems ready for production.

yes it is ready but no official support from redhat/centos so that is what v irtualmin is waiting for... cant have a feature that only some people use

yes, but php-fpm (and thus apc) can be safely implemented with the CentOS officially supplied PHP 5.3.3.

there is no denying the advantages of using apc (to the point it is soon coming built into php)

unfortunately not, eddie.

yes, php 5.3.3 code has support for fpm but you must build it with

./configure --enable-fpm

and if you type "php -i" you see that redhat build php 5.3.3 without fpm:

Build Date => Jul 3 2012 16:50:56 Configure Command => './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--without-sqlite' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--enable-force-cgi-redirect' '--enable-pcntl' '--with-imap=shared' '--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbregex' '--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' '--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' '--with-ldap-sasl' '--with-mysql=shared,/usr' '--with-mysqli=shared,/usr/lib64/mysql/mysql_config' '--enable-dom=shared' '--with-pgsql=shared' '--enable-wddx=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' '--with-xsl=shared,/usr' '--enable-xmlreader=shared' '--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi' '--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-mysql=shared,/usr/lib64/mysql/mysql_config' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--with-sqlite3=shared,/usr' '--enable-json=shared' '--enable-zip=shared' '--without-readline' '--with-libedit' '--with-pspell=shared' '--enable-phar=shared' '--with-tidy=shared,/usr' '--enable-sysvmsg=shared' '--enable-sysvshm=shared' '--enable-sysvsem=shared' '--enable-posix=shared' '--with-unixODBC=shared,/usr' '--enable-fileinfo=shared' '--enable-intl=shared' '--with-icu-dir=/usr' '--with-enchant=shared,/usr' '--with-recode=shared,/usr'

but when doing that php becomes detached from virtualmin and has to be managed on its own, correct? I can't do that... it is a production server and things need to be within the specs of the control panel (even if the fact that I can't use php-fpm/apc means spending an extra $20/month on RAM)

to get php-fpm you would need to get the redhat php 5.3.3 sources + all their versions of all dependency libraries (not sure where to find this, but centos manages so you certainly can find it somewhere)

then you would have to compile with the options listed above + the "--enable-fpm" option

then you would have to manage php manually somehow because virtualmin doesnt understand its php-fpm concept of running a single daemon that listens on multiple ports, one port per user/site

and then you would have to have a webserver that supports talking to php on different ports per site, that would be nginx, i dont know if apache can do it.

and all of that gives you a system that you must manually patch over and over whenever redhat fixes security issues in php 5.3.3. and you need lots of work to set up each domain for this system.

i wouldnt bother just for APC.

maybe if i host just 1 site, maaaybe. but as i constantly keep adding sites, i cant do all that php-fpm config manually for each site. i doubt you want that either...

i guess you could email redhat and ask that they compile with "--enable-fpm" in their version but i doubt they will because it was still experimental (not final code) back in php 5.3.3.

wait for rhel/centos 7 when they have php 5.4 or 5.5 and they will most likely enable fpm.

Yeah, whenever it comes to manually building PHP, we'd recommend against that for a variety of reasons.

We'll review PHP FPM support in the future, when it's included in the distro's PHP packages by default... RHEL7 is scheduled for release later this year, we'll see what options they're enabling by default in PHP.

@andrey: exactly, the security issues are the main reason why i dont recommend it.. not to mention all the extra work!

i guess it would be a good idea to contact redhat though, and let them know we want the feature in rhel 7. their devs may have a mailing list or something, i have no idea how to reach the right people other than the mailing lists.

but php-fpm would be a great feature and it would be a big shame if they aren't aware of it and forget to compile support for it by default.

https://www.redhat.com/mailman/listinfo/

i can see that their desktop (non-server) distro, fedora, has had issues with php-fpm even as late as php 5.4.7: https://bugzilla.redhat.com/show_bug.cgi?id=846858 (so it definitely waas not ready for prime time back in php 5.3.3, which is what rhel6.3 uses)

but rhel7 with php 5.4.11 (the current stable, maybe if we are lucky 5.5 becomes the stable before rhel7) should have it enabled by default, because it is finally mature enough..

btw, php 5.5 went alpha in dec 2012 so chances are we will see php 5.4.x in rhel7 unless php has a really fast release schedul... but even if we only get 5.4.11, it would at least support php-fpm!

why would you "not bother just for APC"? I can care less if I'm using FastCGI or modfCGId... what matters most to me is being able to use APC...

well you won't get APC without a LOT of work, so good luck if you choose to go down that road.

I would be happy to move this discussion elsewhere if you don't mind. But I have already installed and ran APC w/o messing up Virtualmin. The problem was that, due to the way fcgid handles requests, there wasn't one cache per php file, which partially defeated the purpose of APC. So I am not clear why it is that much work. What I perceive as a lot work, under my current setup, is is php-fpm.

everyone knows you can enable APC. the problem is that you can have an unlimited number of CGI processes per apache site and they do not share cache. mod_fcgid spawns a php instance for every request that needs to be serviced.

having 1 APC per process means that you waste a LOT of RAM and get no cache hits. a CMS like wordpress needs about 10 MB of APC cache.

since mod_fcgid launches 1 process per request, it means that each request (user connection) uses 10mb of APC RAM and shares no cache with any of the other requests, and dies after the request is over, losing the cache.

there's just about zero caching going on when you use MOD_FCGId. but you get to enjoy wasting a lot of RAM for nothing!

things are better if you use the nginx webserver instead; it doesn't spawn php fcgi processes on its own, so it only has the 4 children, and cache usage will be better, but still not shared among the 4 php processes of course. still, 4 longlived caches (for 4 children) is better than hundreds of shortlived caches.

so, either switch to nginx, or stop using APC. if apache's fastcgi option can be set up without spawning more php processes than the 4 initial children, then that would also work.

php-fpm is included in CentOS 6.

Go ahead and check on a server without additional repo's:

Available Packages Name : php-fpm Arch : x86_64 Version : 5.3.3 Release : 22.el6 Size : 1.1 M Repo : base Summary : PHP FastCGI Process Manager URL : http://www.php.net/ License : PHP Description : PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI : implementation with some additional features useful for sites of : any size, especially busier sites.

I've been running this on a few sites alongside the normal way of doing it and it's been running fine. Please consider supporting this. The APC overhead alone can be gigabytes of memory

I can also confirm that PHP-FPM is available via CentOS Base repo.

The question is: does this implementation run with standard Apache or does it need Nginx?

The above discussion is very outdated.

PHP-FPM is DANGEROUS and should NOT BE USED by anyone, except people that: 1) Only run their own sites on the server (no other users), and 2) Don't care that their entire server is rooted if any one of their sites are hacked.

For the details that explain the reality of these sensationalist claims, read post #13 here:

https://virtualmin.com/node/25437#comment-114031

Note that literally everything that needs to be known is contained in the post that I have linked to, and it's not in any way a debatable issue. PHP-FPM is dangerous, for the very clear reasons outlined. Some of the danger can be lessened through various methods (such as wrapping it in SELinux), but at its core PHP-FPM is always going to remain an extremely dangerous and hackable way of running PHP that will never be allowed on servers where security is important. PHP-FPM was not designed for shared hosting, and implies that you trust every user on the server and that you don't care about all of the other security and configurability issues that it comes with.

Coincidentally, the thread I just linked to contains the best available method for running APC acceleration with PHP 5.3.3 (not PHP-FPM) using true, isolated per-user opcode caches, solving all memory and isolation issues in one fell swoop and setting up a perfect shared hosting environment - but the thread is a very long read, requires deep understanding of Virtualmin and Nginx or Apache internals, and is only recommended for professionals that want to optimize server performance. My apologies in advance to anyone that attempts to read the thread for that purpose. It was only intended for Jamie Cameron's eyes and is not a general-purpose guide of any kind.

Interesting ! But your link is not available. Must be marked as private.

"the thread I just linked to contains the best available method for running APC acceleration with PHP 5.3.3 (not PHP-FPM) using true, isolated per-user opcode caches, solving all memory and isolation issues in one fell swoop and setting up a perfect shared hosting environment - but the thread is a very long read, requires deep understanding of Virtualmin and Nginx or Apache internals, and is only recommended for professionals that want to optimize server performance."

Is what you're referring to similar to Zend OpCache which is included with PHP 5.5 and available as an add-on for 5.3 and 5.4 ?

Hello everybody,

We are experimenting quite a bit with various ways to improve the Virtualmin LAMP platform and, as PHP-FPM is one of the most promising upgrades, we did some testing. So below is some more info about PHP-FPM vs mod_fcgid (the default PHP execution mode in Virtualmin). We did all the testing with Zend OPCache (as this is the better option in our opinion), but it applies and works the same with APC.

First, what are the strengths and weaknesses of mod_fcgid

1. Strength: Already working with Virtualmin
2. Strength: Very good isolation - all processes work as their own user
3. Strength: Relatively good scaling (rising more php-cgi processes when needed and killing them when not needed)
4. Weakness: Works well with OPCache and APC, but each php-cgi process keeps its own cache which is great RAM waste
5. Weakness: Problematic graceful restarts - not only kills all processes and loses all cache but also waits only 1 sec for the php-cgi processes to exit gracefully then kills them forcefully. No way to control that. Scripts that are running during graceful often die with error
6. Weakness: not supported anymore. Latest version is more than 1 year old, looks like Apache will abandon it soon

What about PHP-FPM?

1. Weakness: Not working with Virtualmin. Actually making it working with Virtualmin is quite easy, see below for explanation
2. Strength: Very good isolation. All PHP-FPM pools (domains) work as their own user (as it is with mod_fcgid). The OPCache is shared, but not accessible from another user, so no security leaks here. We did tested it with OPCache. We didn't test the user cache in APC though, but I do recommend that you don't use the user cache in APC. OPCache is the project with brighter future anyway (and as our tests show it works better and can replace completely APC). Cannot have custom php.ini, but custom options can be applied via the pool configuration. Same or a bit worse than mod_fcgid
3. Strength: Very good scaling. Actually there are 3 different scaling models (2 make sense in shared environment). Good and fast scaling. Same or a bit better than mod_fcgid
4. Strength: Works well with OPCache and APC and shared the cache. Also shares the shared PHP libraries, saves a lot of RAM and also saves CPU (no need to compile again for the newly spawned processes during scaling). Much better than mod_fcgid
5. Fair: Graceful restarts are really graceful (the time to wait for the processes to exit is controlled with an option), no errors due to not finished processes. Unfortunately the OPCache is flushed upon graceful restart, which then makes a spike on the CPU (it is technically possible to keep the cache but they decided to avoid the complexity of this solution). Better than mod_fcgid
6. Strength: Good support, by the PHP team, is included in the official PHP package

How we can have PHP-FPM with Virtualmin? PHP-FPM is available as standard package both for CentOS and Ubuntu, in order to make it work with Apache 2.2 mod_fastcgi can be used from the REMI or EPEL repo, for Apache 2.4 mod_proxy (fastcgi) is the preferred option. In order to make it work with the standard Virtualmin installation (Apache 2.2, PHP 5.3.3) just the php-fpm package needs to be installed from the base repo and mod_fastcgi from the EPEL/REMI repo. If adopted as a standard option later, the mod_fastcgi can be copied at the Virtualmin repo for automated installation. in Centos 7 Apache 2.4 is the standard httpd, so no external packages are needed.

We were able to install PHP-FPM side by side with normal Virtualmin installaiton (some dimains work with mod_fcgid some with PHP-FPM) by manually editing their virtual host definition and adding the corresponding php-fpm conf file. I can provide complete guide on how to do it here. What is needed in order for Virtualmin to start using PHP-FPM is to edit few of the files responsible for the domain creation.

If a domain is using PHP-FPM execution mode here is what is different from mod_fcgid mode: - adding 4 lines in the virtualhost definition and removing 4 - adding a pool.conf file with the actual username.group and home dir in the PHP-FPM conf dir for each domain - changing the graceful restart command to also reload the PHP-FPM config - when editing the custom PHP options (per domain), change them in the pool configuration instead of in the custom php.ini

Conclusion: With adding PHP-FPM support to Virtualmin a much better RAM a bit better CPU effectiveness will be achieved. Also, I presume PHP-FPM + OPCache will be the better standard execution mode for CentOS7 (the same for Ubuntu).

I would definitely support PHP-FPM as an option in Virtualmin, we will provide the whole info we have so far, we will help testing and we can also provide code if you think it is appropriate.

Let me know.

Thanks for all your comments! I'll review them, and the current state of PHP-FPM, and get back with you.

There have been a lot of requests for PHP-FPM, we definitely understand that there is interest in the community in having support for that.

One of the larger concerns is in the difficulty of supporting a new PHP Execution Mode. Along with adding the code to handle that, one of the larger issues is that each of the 100+ Install Scripts that come with Virtualmin Pro could behave differently under a different PHP Execution Mode, requiring additional customization to it.

I've been wondering if it might be possible to offer some sort of means of "unofficially" offering support for it.

We're just exploring the topic to see if it may be any simpler to offer support for this now than it had been in the most -- thank you all for your comments and support.

A suggestion. To provide PHP-FPM with a status of Available and Unsupported, for now, Upgrade status to Supported Fully - 3-6 months from now? - estimated time it'd take to test install the 100+ install scripts that come with Virtualmin Pro.

@Mostafa

PHP-FPM + OPCache does not allow reading other user's cache, that was confirmed both by the PHP community and our tests. It is possible though to list the cached files through the OPCAche API (together with some statistics about the cache usage), but this can be limited for a special admin area via config option (to be available for the server admin only).

Also, yes, we have read you blog post and basically we do confirm it. PHP-FPM + Apache 2.2 + mod_fastcgi is also a confirmed solution.

It makes sense if PHP-FPM execution mode is introduced as "experimental" for few months to let the community test it. Really I don't see reason for any script to behave differently under mod_fcgid and PHP-FPM, but, yes you will need to test all of them (with an "experimental" PHP-FPM large amount of the testing process will be provided by the community).

Maybe you are aware, the PHP community already announced that PHP-FPM will be the officially supported process manager (it already is since 5.3.3), also they announced that the Zend OPCache (also OPCache, previously Zend Optimizer+) will be adopted as a standard in the PHP project itself (not APC). With CentOS7 it is clear, Apache 2.4 + PHP-FPM + OPCache will be the "standard" very soon. IMHO it makes sense to move in this direction (implementing, testing) soon.

@gpetrov

can you provide the lines needed to make it work ? what need to be changed to make it manually work for now..

I can join test group for php-fpm.

Count me in for testing

Big plus for me , supporting FPM.

Also want to test out if possible.

Would definitely want built in support for this.

+1

any news about this?

Thanks for all your input!

We unfortunately don't have any new news regarding this quite yet, but it is still on the table.

Another +1 from me for php-fpm support. Such a pain to manually configure each server.

Pleeeaase add support for integration between nginx and php-fpm more practical way to please virtualmin some can tell me if this plugin: https://github.com/Real-Gecko/virtualmin-nginx-fpm solves everything in nginx issue with php-fpm !?

herculesnetwork Real-Gecko plugin works but have limitations: take a look at issues here: https://github.com/Real-Gecko/virtualmin-nginx-fpm/issues

I believe I saw that some distribution now enables FPM by default. This is becoming an issue more and more.

Good news - the next Virtualmin release will include support for PHP-FPM as a built-in execution mode.

Jamie...some questions please:

• what's up with existing virtual servers? Properly tested?

• may be Apache 2.4 maintained with fpm?

• does it work with mpm worker or event without change?

• is the virtual host httpd conf updated (if needed) according to that?

• may be previous rules in the conf conflicting if not properly removed or are they ignored?

thank you very much!

• If you upgrade Virtualmin to a version with FPM support, existing domains will stay with their current PHP execution mode (but can be changed).

• We only support the Apache and PHP-FPM packages provided by CentOS, Debian and Ubuntu family distributions.

• The existing httpd.conf is not touched unless you choose to change the PHP mode for a domain.

Thanks, that is really good news! Can't wait to activate PHP-FPM in the next version.

Is it just installing php-fpm packages, selecting it as PHP execution mode (and optionally tweak the configs)?

Yes, all you should need to do is install the php-fpm package, click "Re-Check Configuration" in Virtualmin to ensure it is properly detected, and then select it as an execution mode for whichever domains you want to use it.

on xenial fully up to date running php 7, I installed php-fpm via webmin. then re-checked config in virtualmin. i still get only http://i.imgur.com/fY0Lrns.png

also installed php7.0-fpm, but it didn't change the above.

eddieb I think you have to wait for the next virtualmin release, is it right JamieCameron?

Thanks Kintaro, you are correct. Webmin was updated on the 29th, after Jamie's post from the 22nd, but Virtualmin is still in the November release.

Jamie, should I remove php-fpm and php7.0-fpm? Both installed from the official ubuntu mirror repos. will virtualmin use these or will they come from the virtualmin repo?

You can leave those installed - Virtualmin will use the distro-provided FPM packages (in fact, it relies on them).

in which version is this active ? i can't get it to work on my servers i have this problem https://www.virtualmin.com/node/44325#comment-769405

Webmin version 1.831 Virtualmin version 5.05

ok i deleted all the alias, ran the check configuration, but there still is no php-fpm and i have both php-fpm and php7.0-fpm installed om a debian with dotdeb packages for 7.0

i even put in /usr/sbin/php-fpm7.0 in the php version and it still doesn't seem to detect it or activate it.

So can anyone help how to get this active ?

Version 5.06 will contain the FPM feature.

is there an eta on that release ? ;)

When it's done. ;-)

Wait this feature too, from 2012 year :) After upgrade - php-fcgi to php-fpm will be updated automatically or we must do some manual modifications?

Is it possible to operate more than one php-fpm instance? So you could use different php versions per subdirectory?

And in the process list you should see at first glance all active pools.

greetings Frank

https://virtualmin.com/comment/771317#comment-771317

go! go! go! :D