Submitted by sfatula on Sat, 02/04/2012 - 01:54
So, I have defined a custom php5 fastcgi wrapper script for a template, default settings template. I create a new server for that template, and, it does NOT use the custom wrapper script! It uses the standard one virtualmin creates, which is wrong.
Is there a bug here that makes the setting irrelevant?
Status:
Active
Comments
Submitted by JamieCameron on Sat, 02/04/2012 - 14:53 Comment #1
This works OK in my tests ...
Make sure that at System Settings -> Server Templates -> your template -> PHP wrapper scripts, you enter the script into the "FastCGI wrapper for PHP 5" box , and not "CGI wrapper for PHP 5"
Submitted by sfatula on Sat, 02/04/2012 - 15:03 Comment #2
It is, specifically, what is not appearing in the final file on a new server is the very last line, my guess is you may be replacing it.
My entire data in that box is:
!/bin/bashPHPRC=${HOME}/etc/php5 export PHPRC umask 022 SCRIPT_FILENAME=$PATH_TRANSLATED export SCRIPT_FILENAME exec /usr/bin/php-cgi
What I get on a new server is:
!/bin/bashulimit -u 100 PHPRC=/home/test/etc/php5 export PHPRC umask 022 SCRIPT_FILENAME=$PATH_TRANSLATED export SCRIPT_FILENAME /usr/bin/php-cgi
So, perhaps, it's not that it's ignored, it just won't keep my last line? Not having an exec is very bad and plain wrong. It causes hanging processes, which I realize you then clean up with a kill stranded php cgi script, but all that is un-necessary if you simply add exec, which is what my custom wrapper was inteded to do. But it doesn't work ('d swear it did on older versions). I can of course manually edit the generated file (and do), and all is fine. I even disable you php cgi cleanup script as it's not needed, have never had a stranded process in more than a year.
Still, would love to be able to get this to be automatic. Try it out....
If you are not sure about the exec, please reference the Apache docs found here:
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Scroll down to their php-wrapper script, voila, an exec. The missing exec is the entire reason that you have stranded php-cgi processes! When php dies or terminates, it does not terminate the parent process (which you have without exec). Of course, this may work in concert with fcgid.conf, not sure, in which I always use:
FcgidIPCDir /var/run/mod_fcgid FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm FcgidMaxRequestsPerProcess 500 FcgidMaxProcessesPerClass 5 FcgidMaxProcesses 100 FcgidMinProcessesPerClass 0 FcgidIOTimeout 121 FcgidIdleTimeout 600 FcgidErrorScanInterval 10 FcgidFixPathinfo 1
The max processes replaces the ulimit, but, doesn't matter if you retain it, I am ok with that. The max per process opens up a new php process after 500 requests since php has an issue with that as also documented on the apache page.
Anyway, whether you want to change more stuff or not, please allow me to keep that last line as I can't stand all those cgi processes piling up for no reason exceot for a cron job to kill them! Also, I suppose it uses more memory the way it is now, albeit, small. I find using the fcgid.conf file in better ways makes mod_fcgid extremely reliable and efficient.
Submitted by JamieCameron on Sat, 02/04/2012 - 15:20 Comment #3
I see why that is happening - if you have a "Maximum number of processes" limit set for your PHP processes at Administration Options -> Resource Limits, the exec is removed so that resource limits actually work. The work-around is to turn that off..
The alternative hack solution is to put a space before
exec, so that Virtualmin's code that modifies it doesn't recognize the line :-)Submitted by sfatula on Sat, 02/04/2012 - 15:27 Comment #4
Ok, will try disabling the limit of 100 since it's irrelevant anyway when using fcgid.conf to configure mod_fcgid. Actually, setting this directive (FcgidMaxProcessesPerClass) is better in httpd.conf anyway (for site specific limits), better than using ulimit. I wish vmin started using more of the mod_fcgid settings. I think they are cleaner, and, more effective. And you would avoid the entire problem with abandoned processes since exec would always be used. Many of the settings set at various places in vmin can be translated to fcgid statements.
Submitted by JamieCameron on Sat, 02/04/2012 - 15:34 Comment #5
The FcgidMaxProcessesPerClass setting works for php scripts launched by Apache, but it doesn't limit the number of sub-processes they can run in turn .. what's why Virtualmin uses ulimit to set resource limits.
Submitted by sfatula on Sat, 02/04/2012 - 15:37 Comment #6
If you are speaking of php managing multiple cgi instances (children), not a problem since there's only 1. If you are speaking of a more advanced program where maybe the apache screen spawns off more copies by using process management, I suppose that's true. Of course, the penalty is all those extra processes hanging around. Not worth it to me!
Submitted by JamieCameron on Sat, 02/04/2012 - 17:28 Comment #7
Yeah, it is rare that this is an issue ... Unless someone writes a fork bomb that launches thousands of processes.