I am trying to get fastcgi working on a new Ubuntu 16.04 instance running on Amazon. I have swapped php7 for php5.6. I can configure a site to run under mod_php but (so far) not under mod_fcgid. I have a test subdomain set up with just an index.php containing phpinfo();. I get a 500 Internal Server error, and the error log reads:
[Wed Aug 23 18:52:04.610166 2017] [fcgid:warn] [pid 29822] (104)Connection reset by peer: [client 184.186.226.189:50206] mod_fcgid: error reading data from FastCGI server
[Wed Aug 23 18:52:04.610217 2017] [core:error] [pid 29822] [client 184.186.226.189:50206] End of script output before headers: index.php
The following PHP versions are available : 5.6.31 (/usr/bin/php), 5.6.31 (/usr/bin/php5.6)
So, FastCGI seems to be ready to go. I have googled and searched through the forums here, and most frequently there are references to file permissions and timeout. To be sure everything is readable I've set everything to 777 and it still fails. I've set FcgidBusyTimeout 3600 in my .
I note that in fastcgi, each site has it's own php.ini above web root, which in this case would be located at /home/phpinfo/etc/php.ini. The file is there, it's a symlink to /home/phpinfo/etc/php5.6/php.ini, which is NOT present. Not sure if that's a problem or if it just uses default values in that case.
Not sure what else to look for.
A solution doesn't jump out at me, but here's some pointers:
phpinfo()and see if it works).Try switching execution modes from mod_fcgid to php-fpm and back, or perhaps to-from cgi. I don't remember when those config files are generated.
Also, why not php-fpm? It's actually got some benefits over fcgid (opcache can be shared across processes owned by the user), and is a simpler configuration, so less prone to problems like this. It's about the same performance as mod_fcgid, as well (faster for some workloads, slower for some, but very similar).
--
Check out the forum guidelines!
Thank you.
1) I started with public_html with default at 755 and index.php at 644, and now have reset them to those values. Still get 500.
2) As I said above, that's exactly what I have. Actually I had a closing tag too and have now taken that out. Still get 500.
3) hhhhoooowwwww do I switch to php-fpm? I've always been a php_mod user but I am ready to move on, if I can make this work. I've been reading up on the differences but relating to Virtualmin I don't see it. I've confirmed that php5.6-fpm is installed on my server but there isn't anything identified as fpm in my apache module configuration, nor anywhere else I see.
● php5.6-fpm.service - The PHP 5.6 FastCGI Process Manager Loaded: loaded (/lib/systemd/system/php5.6-fpm.service; enabled; vendor prese Active: active (running) since Fri 2017-08-18 22:16:06 UTC; 5 days ago Docs: man:php-fpm5.6(8) Main PID: 1186 (php-fpm5.6) Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/se Tasks: 3 Memory: 17.4M CPU: 16.974s CGroup: /system.slice/php5.6-fpm.service ├─1186 php-fpm: master process (/etc/php/5.6/fpm/php-fpm.conf)
├─1484 php-fpm: pool www
└─1485 php-fpm: pool www
Warning: Journal has been rotated since unit was started. Log output is incomple lines 1-15/15 (END)
Update to the latest virtualmin-config package and try running:
# virtualmin config-system --include ApacheThere were a couple of fixes related to running PHP under fcgid....I don't think any of them were causing 500 errors though, so I'm not super hopeful. This isn't a problem I've seen, so I'm not sure where to start looking for the cause.
Note that Server Templates apply to new virtual servers, and not to existing ones. To change an existing virtual host to use PHP-FPM, you'd go to Server Configuration->Website Options->PHP script execution mode.
Switching back and forth between execution types and testing, and checking logs during each test, can help narrow down where the problem is, and will like also generate the missing php.ini. If it doesn't re-appear after doing that, we'll need to copy one in manually. There's probably changes that Virtualmin does to the file, so I dunno if copying it unchanged over from /etc would do the trick. I'll have to look into it.
--
Check out the forum guidelines!
Thanks, slight progress....
I tried to run # virtualmin config-system --include Apache on the command line but it's not found. I tried searching for a package and found none. I tried googling your command above and there was no trace. Is it correct? In any case, I have virtualmin in my sources list and it's up to date. That includes a package for awstats that got updated this morning.
While I still have mod_php disabled, I switched between cgi, fcgid and fpm, ending back at fpm. After all that, a /etc/php5/php.ini was created, it appears to be a default and not a copy of my main php.ini as I'd expect. But I tried the site and I still get a 500 error. Then I recalled that the symlink pointed to /etc/php5.6/php.ini, which still didn't exist, so I copied the php5 one to make it /etc/php5.6/php.ini. Still no luck, still 500 error.
Next?
Oh, you're running a pre-Virtualmin 6 installation. Sorry, I thought we were dealing with a new issue that I fixed in the installer recently. You don't need that command for this. We'll have to troubleshoot it the usual way, as it is not a known problem.
What shows up in the error log (the one for the virtual server in /home/domain/logs, and the standard Apache one in /var/log) when you get this error, if anything?
--
Check out the forum guidelines!
My installation says:
Virtualmin version 6.00
But originally was something less than 5.99 (I don't remember the exact version). This amazon instance was launched from an image I created in April, and immediately apt-get update(d).
The apache error log for this site says:
[Thu Aug 24 17:55:36.707214 2017] [proxy:warn] [pid 16340] [client 184.186.226.189:51754] AH01144: No protocol handler was valid for the URL /index.php. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
... which is odd because I checked the error log when I started this issue and there was nothing helpful.
OK! Success! I enabled every apache module that started with "proxy_" and it all now works. I don't know that I really need them all, but it seemed like a good thing to try. Should they all be enabled?
I guess "re-check configuration" should check all those modules as well before saying it's FPM ready?
Alright.... more info.
I decided to see if anything had changed with mod_php - basically to make sure that the REST of the system was still working and that the 500 error wasn't something unrelated to php execution mode. Yep, mod_php still works.
Then I decided to try the other execution modes. CGI works. FCGId works. FPM, 500 error. So basically all of them work except FPM. But from what I've read, FPM is what I want :(
Related but tangental errors I see in VIrtualmin while doing this...
Maximum PHP script run time seems to lose it's value in the UI when switching execution modes. Frequently, the option in the UI is displayed as 0 seconds, which isn't a valid option. Doesn't seem to make a difference whether it was previously set to unlimited or whether a value was set.
When switching a site from mod_php to CGI or fcgid, "php_admin_value engine Off" gets inserted into the virtualhost config. This is VERY problematic as it kills a site that should be running, since it's not using mod_php. As it is, switching from mod_php would take three or more steps: switch the site execution mode for the site, remove "php_admin_value engine Off" from the virtual host config, (repeat those two steps for every virtual host on the server), disable mod_php. If there are many virtual hosts on the server this could result in substantial downtime while an administrator is doing all that editing. And if you dare to disable mod_php prior to eliminating all the "php_admin_value engine Off" directives, apache itself won't restart. I don't want to send this thread off on another tangent so I won't get into mod_php's issues here...
When switching a site from mod_php to CGI or fcgid, "php_admin_value engine Off" gets inserted into the virtualhost config. This is VERY problematic as it kills a site that should be running, since it's not using mod_php.
This should only happen if mod_php is enabled in Apache. And, if it is enabled in Apache, it won't cause a site to fail AFAIK (and is even necessary in the case of mod_fcgid, I believe).
If you're seeing that directive added on a system that has mod_php disabled that's a problem (and confusing, as I wasn't able to reproduce when I tried a day or two ago). But, yes, that directive does need to go away if you remove mod_php...it does not happen automatically. The reason it doesn't is that mod_php really shouldn't be turning off and on on a system-wide basis. Either you use it and leave it on forever, or you don't and turn it off forever. It's likely we won't even be installing mod_php in the installer going forward; I want to get rid of it entirely, as it just causes too much trouble.
--
Check out the forum guidelines!
Correct. Exactly. The scenario is that I am referring to is migrating from mod_php to something else, so obviously mod_php is enabled. I really don't think you want to create a situation where one has to migrate to an entirely different server, or go offline for significant periods of time, to change the execution mode.
I would be opposed to dropping support for mod_php. From what I've read it's only insecure in a shared hosting environment. We find Virtualmin to be extraordinarily useful even in our dedicated environment (6 amazon servers so far, all running mod_php at this time).
I think you need to find out how many users are still running mod_php before you even think about deprecate it. I think you would be surprised. And you would tick off all those people. To say the least.
Security is merely one issue. It's also slower and much more memory-intensive than any of the other execution modes. So, there's not really any reason for anyone to use it, that I'm aware of, except for "It's what I'm used to." Which is a valid reason for keeping it around as an option; but maybe not as part of the default installation. It will be a long time before we actually remove support for it.
So...maybe I wasn't clear about my intention:
virtualmin config-system --include Apacheto remove some of the "use mod_php for everything" directives in the Apache configuration. We'll document that if we go that route.But, I'm willing to be convinced (which is why I made a poll about it). I'm just trying to understand why people want it. So, why do you want mod_php?
I'm getting that switching is not as easy as it should be. I need to work on that, since I don't think it's really the purview of Virtualmin proper, but I do think we probably need a command line tool or something that'll do all the things: Disable mod_php, remove any php_admin_value directives from Apache conf, and switch all virtual servers to fcgid or php-fpm. That's do-able, it's just not a thing I've looked at yet. but, the difficulty of switching is kinda why I want people to use one of the good modes from the get-go and make it a little harder to go down the sub-optimal path (because once you're on the sub-optimal path, getting back is beyond most users abilities).
--
Check out the forum guidelines!
Great. I am willing to be convinced too. You may be interested to know why I use webmin/virtualmin. Since the late '90s, BTW. I am not a system admin, more of a user facing software/web developer. I work for a small non-profit that also outsources my services to get better economies of scale. I don't like command lines. If I did, I probably wouldn't use webmin. Since I am not a true sys admin, I need a control panel that does things for me and makes my life easier. I am a fan of open source, so options like cPanel and Plesk aren't attractive. Also, my experience with cPanel makes me despise it, since it actually has it's own version of some binaries, making it really sort of it's own linux distribution, different than others. I like web/virtualmin because it sticks very close to being something that "just" manages standard conf files rather than sink deep hooks into the system. So, I don't use webmin/virtualmin server images; I always just install the package over a standard (currently Ubuntu) distro. I work for a non-profit, so "free as in beer" is important. My task at hand is to migrate 5 servers from Ubuntu 12.04 to Ubuntu 16.04, all currently running mod_php. Virtualmin's features to change user ownership of sites, and backup & restore entire accounts, has proven invaluable. One of those servers is already migrated, and yes, still on mod_php. With the exception of updating permissions from old apache to new apache, it was seamless. I wouldn't care if the migration retained mod_php configuration or allowed the mode to be changed to something else with a selection item, as long as it "just works".
Your clarification is critical. A better option than mod_php as the default, that actually works smoothly, would be very welcome. But also remember that which mode to use is not your decision to make. mod_php is still a viable option for at least some users. Switching to/from mod_php should remain as simple as it is now. Simpler, in fact. I don't believe inserting "php_admin_value engine Off" is your decision to make. Perhaps a warning in big red text would suffice, when Virtualmin determines that mod_php is no longer in use but is still enabled. Sticking with mod_php is not so much "what we're used to", it's more "what we trust". It's never failed me. That's a big deal. Like I said, I am ready to move on but our server with the most sites will be the last one to convert, and will be done after several months of running the others with no issues. Do yourself a favor and figure out a way to find out how many Virtualmin servers still use mod_php; that will tell you a lot about what you need to do. I would be surprised if it's less than 25%. Probably closer to 50%.
Thanks for your help with this issue, and all the work you do. Virtualmin rocks.
I just had this 'end of script output before headers'-problem myself:
It should be 'php-cgi5.6'.
Try this:
apt remove --purge php5.6apt install php-cgi5.6
'Re-Check Configuration' and select PHP version again.
Don't forget to remove mod_php which could be installed for any reason and will block fcgi execution.