Error 500: Connection reset by peer: mod_fcgid: error reading data from FastCGI server

I run a VPS with a few domains and one domain suddenly stopped working with an 500 error.

Error log reading:

[warn] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server [error] Premature end of script headers: index.php

I run CentOS 6.* and PHP 7.0.15 (in case that matters). I presume it was caused by a recent update.

When I compere the httpd.conf for the different virtual directories I see no difference. How can tackle this problem?

I did a workaround for now.

virtualmin > > Server Configuration > Website options > change from ‘FCGId’ to 'Apache mod_php ’

That works, however I can’t go back to ‘FCGId’, I get “Failed to open /home/domain3/fcgi-bin/php7.0.fcgi.webmintmp.12945 : Permission denied”

Other domains on the VPS work fine.

You should check your FCGId configuration in /etc/httpd/conf.d/fcgid.conf (Centos 7) and see what values you have with FcgidBusyTimeout, FcgidProcessLifeTime and FcgidIOTimeout. Of course the reason for the initial problem could be slow/oversold server or bad coding. Its hard to say not knowing the entire situation, but good start would be the three records i mentioned at beginning. Just pay attentions some of this records could be located inside httpd.conf file and if you set them in fcgid.conf then you should remove from httpd.conf.

This is for Centos 7 and if you have different OS you should apply this suggestions for your OS.

Second problem is pretty much clear by itself, there is a problem with permissions and you should check that file to match domain/virtualserver owner.

I’m having the same problem, I think my host has applied an update, and only one of four sites are working?

Isn’t there only one httpd.conf file, the same for all sites, why would one site work and not the others?

Did you find a solution?

It does sound like the connection between Sync Gateway being closed and not automatically re-established properly. I haven’t heard of anyone hitting this issue before, though, so I’m not sure what’s different in your scenario.

I assume you get the same error for subsequent requests against the SG, prior to restarting? And for different types of requests?