I run PHP in CGI mode (that's a requirement for my application). Because of that, if I run ps, by default the processes don't show which php script they are running. They just say "/usr/bin/php".
Since several years ago I've been using, in production, setproctitle to set the process title just like PHP does when running in suPHP.
However, this package appears to be dead and I've never seen it getting a stable version. Plus, it is incomplete and might lead to memory corruption on Linux.
I'm glad to see that there is a native alternative for CLI mode, cli_set_process_title, but is there any alternative for PHP running in a web application?
Related
I have a commercial membership site php program on the server, but after the server upgrade it no longer works. The provider has ceased to operate so there is no support. I am using php 7.0.15, but the server wants me to upgrade to a more recent version, 7.4. This breaks the program /all I get is a blank screen)
My level of PHP does not allow me to debug such a complicated program. My question is:
is there any way of instructing php to only use the older version? I imagine that this would have to be done in the php.ini file on the server?
I would like to upgrade to php 7.4 on the server, but have this software run in php 7.0.
Is this possible?
The simple answer is No - PHP does not offer any options to emulate the behaviour of previous versions.
Partly because features are sometimes removed because they prevented changes in the engine, or would need a lot of work to operate with them; partly just because there is only a limited amount of resources available to work on the core of PHP, and maintaining multiple versions of each feature to enable such compatibility would take effort away from improving the current version.
Your short-term option is to find a way to run an actual copy of PHP 7.0 on the server, or a different server that will allow you to run it. You may need to pay someone who provides unofficial long-term support for old versions, since the last official security patch for that version was over 3 years ago. Even PHP 7.4 will only receive official security patches until the end of this year.
In the long term, your only options are to hire someone to update the application to run on a modern version of PHP, or to migrate to a different application which still has a vendor supporting it.
Setting PHP's opcache parameter to 1 (on, the default) is giving me 'zend_mm_heap corrupted' errors in the Apache log file at a rate of a few a day, irregularly.
Previous StackOverflow answers have suggested this might be because of (a) using other caching modules such as APC - not the case here, as only the standard PHP distribution is being used without any non-native caching or (b) running out of memory - but I have at least 1.6G of swap space available according to free -m or (c) a bug in the PHP compiler - unlikely as this error is not widely reported and I am not doing anything unusual.
The server runs several websites, built using Drupal, Joomla, and bespoke PHP. I am running a standard PHP5.6.36 with mod_php and Apache 2.4.33 using the event MPM on Amazon Linux 2.
The only thing that is not completely standard stuff is that I am using the Amazon AWS SDK for PHP v. 3 to send mail, but I have no reason to suppose that this is causing the problem.
How can I track down what is causing the heap corruption?
Looks like this bug has been reported. Within the comments it's suggest to set the following within php.ini:
opcache.revalidate_freq=7000
opcache.fast_shutdown=0
I have been trying to run HHVM as standalone web server for multiple domains and it looks like they are switching to FCGI mode only https://github.com/facebook/hhvm/wiki/runtime-options
Is that the case or running it as standalone is still possible on production?
Yes, you should use FastCGI mode and let nginx/Apache/whatever deal with being the webserver. HHVM's old built-in webserver has been deprecated for quite a number of releases now -- I can't find the old the wiki page on its deprecation, but it's been about six months or so. This more closely mirrors how PHP is often used, and removes a whole host of complicated HHVM-specific configuration mess. Many people are already familiar with how to make nginx/Apache serve files the way they want, and so we can just keep the HHVM-specific stuff in HHVM and let the full-featured webservers do what they are good at.
The getting started guide has a very quick, basic intro to getting FastCGI set up if you're using our prebuilt debian/ubuntu packages, and the FastCGI wiki page contains all the details to get set up in some other environment.
Can anybody tell me why using the pcntl lib on production servers is discouraged? The PHP manual tells very briefly about it, and I'm in a dire need to use this library...
Is there another way to do the same thing in php?
pcntl is discouraged in production environments because the functionality it supports (fork, process control, signal handling) are fairly explicitly things you should not be using in a CGI style application. Now, if you're writing a daemon or command line application in PHP, that is another matter...
From the PHP manual:
Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment.
one has to be clear about the differences of a php cli script and a sapi/cgi script.
php on production systems may as well have support for pcntl.
the important thing here is to have 2 php config files. one for cli and one for cgi setup.
one then has to disable pctnl in the cgi setup because the real security issue is, that forking a script when executed by the webserver may leave zombie processes flooding the system.
in a cli environment it might be necessary to be able to write scripts that fork...
There is a PHP application right now on a Linux box running under Apache with MySQL. Since we are a windows shop, management wants to get rid of the Linux box and move everything over to windows. Is there a performance difference between the two platforms? Or, is there any significant difference at all, in terms of performance or management?
Microsoft had a team help out optimising PHP for Windows, which work is part of PHP 5.3. Some figures I've seen places the performance close to PHP + Apache on a unix system. Before 5.3 (Which means currently, since 5.3 isn't out yet), performance is bad on Windows. I think there are some patches and tricks you can pull to improve it, but it's going to cost you a bit of performance. That may or may not be a problem; People have a tendency to overestimate performance.
Note that there are other reasons to use unix than just performance. Code may not be portable and even though the core php runs fairly ok, you can well get into trouble with php-extensions and third party libraries. No matter how you look at it, Windows is a second-rate system for running php on.
If your application isn't huge or get hit a couple thousand times per second, there's no difference between the two.
LAMP == WAMP in php small projects. Just install something like XAMPP if you want your environment to be as close as possible to your existing one but in Windows.
Good luck with your project!
You should consider the MS WebPI (download at www.microsoft.com/web ) which would install the entire stack for you to run PHP in IIS7 environment.
the performance is comparable for most apps.
I've just done this for the same reason. Mgt wanted to get rid of the Linux box. I was able to completely move my php application and MySQL database. It took longer for me to configure PHP for IIS than it did for me to move the existing content over.
I have found though that the IIS server is a fair bit slower when it comes to loading pages and images. Where in Linux it appeared instantaneous, in IIS it takes a half second for the page to load and another second for images.