I actually solved this problem eventually, but it took so long that I thought I would post the question I was going to post a few hours ago so others that might happen to run into it would not find themselves in the same boat of wasting 5 hours trying to solve a simple problem.
I was trying to get a version of Zend running under an installation of lighttpd with a scaled down php and Zend core framework running through fastcgi but the problem was that any time I confronted an error, it was not reporting in the browser and was not showing up in any of the log files. (the actual platform was android which added to the confusion, but the problem turned out to be a lighttpd/zend configuration issue non-specific to the platform)
Since I wasn't sure at which layer the logging was failing, I tried everything from modifying the error/logging settings in the lighttpd.conf, fastcgi values in both the lighttpd and php configuration files and setting various logging parameters in php.ini but none of them produced any error messages in the logs even though the zend page in question was saying 'Application Error' and little else.
What I ended up discovering was that all of the examples I had run across of setting up the lighttpd.conf showed good examples on how to set up the fastcgi, how to set the server parameters, how to configure php, etc. and even how to translate typical apache .htaccess files used for Zend including rewrite rules into something similar in the lighttpd.conf
What none of them did make obvious was the setting of any required Zend environment variables.
Under a default zend site configuration such as you might find on the Zend help pages, they generally set up some kind of bootstrap.php along with a corresponding application.ini file. In the examples I saw most often and therefore the ones I followed, they included the ability to configure multiple application environments such as production, testing, development, etc. This was controlled on the server in question by setting the environment variable APPLICATION_ENV to include the environment.
In my particular set up, the 'production' environment in the example I used was the default and turned 'off' all php, exception and other error logging for the production environment to avoid users seeing ugly errors in a production setting. Since this ran after Zend started, it over-rides anything previously configured in lighttp.conf or php.ini.
Even though this has been common in most of the exmaples I've seen on configuring a zend server, none of the examples I saw for lighttpd showed setting this variable and since I was focused on the 'layers' involved, it slipped my mind.
So setting the environment in the lighttpd.conf to include development environment made my errors visible again:
setenv.add-environment("APPLICATION_ENV"=>'development')
Now I have a functional zend LAMP server implementation running on my cell phone using bitweb for android! Thanks Andi!
Related
I have a server in the office that's used as a development server. It's running Centos 7 with Apache, PHP and MySQL.
Randomly some web applications on the server has stopped returning a response, and upon inspecting the Apache error log, I'm seeing this error when no response is received;
zend_mm_heap corrupted
I've done some research and understand this has something to do with Zends memory management, but I don't seem to be able to find a way to resolve the issue.
I have checked my php.ini file, and cannot see any reference to APC so don't believe it's causing the issue.
The server was running fine, and it's pretty random that this has started, I don't believe we've changed anything on the server to cause the issue.
This error appears across multiple projects, so I confident that it's not project specific and more something relating to the server/software itself.
If I add the following to a projects .htaccess file, then it seems the web application works fine and no errors are generated. However I don't believe adding this to every project on my server is a suitable solution and I definitely thing there an issue somewhere, maybe bad ram?
php_flag opcache.enable Off
I have a server setup running Nginx 1.1.19 and PHP 5.5.7 on Ubuntu 12.04 LTS. When opcache is enabled, if there is a file that is identical in both my development and production environments, that file will always be run from production. However, if I change just one character in either file, PHP will correctly run the proper script.
For example, if I clone the same project to two different directories and the only thing that I change between the two is the APP_ENV environmental variable in the configuration file, whenever I point my browser to the development environment, all of the database parameters from the production config are loaded.
If I turn opcache off, the weird behavior ceases and everything works as I expect.
Is there an opcache config parameter that I can set that will force PHP to resolve the correct script location? I tried setting revalidate_path to 1, but that just switched the problem around (pointing to either production or development always yielded the development environment.
For now I've just turned opcache off, but I'd like to know more about it.
Short Answer: YES - taken from an answer over on ServerFault I provided to a similar question:
Make sure that opcache.use_cwd parameter is set to true for your application's configuration of OpCache - it's set to false by default and leaving it set to default will probably cause collisions if you're hosting more than one PHP application on your system...
When originally shipped, opcache.us_cwd was set to a default of false - that's how I get it on an Ubuntu 14.04 Zend Server AMI from Zend themselves, though I have heard that some modern distributions have changed the default setting from false to true. I haven't personally seen any but it's worth confirming yourself on your setup to validate if TerryE's comment is accurate for your specific configuration on your webhost.
I have just done a fresh install of the latest stable PyroCMS version on my web server. I now can hardly use the site due to PHP errors pertaining to session data. "Cannot modify header data."
Why would the CMS run without error on MAMP but not on the live server?
I had the same problem. Looks like PyroCMS is having trouble with php 5.4 which is what MAMP is using by default. Try switching your php version to 5.3.
Thread with same issue
Both the server must be having different configurations with regards to displaying of errors.
Either place error_report('E_ALL'); at the initial page (most probably index.php) or find out how you can disable displaying errors in your CMS (there must be some configurations).
Or trying putting off the display_errors directive in your php.ini file.
You should have PHP set up so that you spot errors on your local machine before they make it to production. It seems like you currently have this the wrong way around!
To fix it, your dev install of MAMP should have error_reporting set to E_ALL in php.ini and display_errors set to 'on'. Your production webserver should have display_errors set to 'off' at the very least (check that they are sent to the log files instead - you don't want to lose them) and you may also wish to reduce error_reporting to E_ERROR.
Setting it to E_ERROR will keep the logs on the production server clean so that you can spot big problems when they happen. You may especially want to do this if you are using a library or CMS that produces PHP notices or warnings, which you can't do anything about. Alternatively, you may wish to keep everything going to the logs with E_ALL and systematically sort out all the stuff that shows up, however, you will need to be using code that you can modify without making it awkward to upgrade. This can be very useful because sometimes the environment on the production server differs from your local one and things can genuinely break for reasons you don't expect.
Incidentally, the 'cannot modify header data' error suggests that this is not a stable version of PyroCMS, whatever it says on the tin!
Thanks for the help guys. I eventually found the problem which was to do with sessions. I had session.autostart=on on the live server. Turning this off fixed the problem.
I'm playing with a PHP weblog application using a shared hosting service, as a part of my PHP learning process. The service provider has a typical LAMP environment with remote ssh access.
Vim has been my best friend in exploring the PHP code. However, I found it sometimes hard to trace stuff in the code in case of error. For example, sometimes I visit a page and I got a blank response with no error messages whatsoever. How should I go about debugging this? Any tools that will be helpful?
My experience has been mainly in C/C++, Perl and some CGI programming. So PHP is a very refreshing experience with me :-)
In case it matters, the application I'm playing with is Lyceum, and I don't have much choice on the LAMP environment itself.
EDIT: Free software tools preferred :-)
I assume your hosting provider configured their PHP installation with display_errors turned off, which is a good thing. That's why you're seeing blank pages. So the most practical solution at the moment would be to have an .htaccess file which turns it on:
php_flag display_errors on
You'd also need error_reporting to an appropriate value:
php_flag error_reporting "E_ALL | E_STRICT"
Anyway, remember to turn this off before letting users access your web site.
For advance debugging I'd recommend Xdebug installed on the server with Eclipse PDT or NetBeans IDE with PHP support as your editor. They both are good clients for debugging, but I really doubt any provider would install Xdebug on their live servers. So you're pretty much left with logging functions if you don't have a development environment.
Getting access to your own local development environment (via XAMPP, for Example) would let you install XDebug.
PhpEd would let you debug it, but also Eclipse's PDT Environment.
Error Tracing and logging via editing php's ini config file is a good way as well, specially if you can manage it to log information. Also, consider adding trace statements and using FirePHP, for example.
Personally, I would recommend jEdit rather than vim. The SFTP plugin allows you to edit (well, load and save) the PHP documents directly on the server and the PHPParser plugin will give you some error recognition.
Also, if you get a blank page with no error messages, chances are hight that those messages are just hidden from you. Make sure that error reporting is enabled, either in your config or in your code like this:
// Report all PHP errors
error_reporting(E_ALL);
If error reporting is enabled and you still don't see any messages, either enable logging or enable output to the browser.
If you get a blank page, it's probably because of a fatal error, with display_errors turned off. By default, PHP will log errors to Apaches error-log, but you can also configure it to log errors to a separate log.
For debugging, you may also want to look into Xdebug. This extension can do a lot of things, including interactive debugging. You'll need a client to use the debugger, but there is a plugin for vim that does this.
Try NuSphere PhpED
PHP v5.2.8
Windows Server 2003 SP2 (IIS 6, I believe, though I can't find a version # anywhere in IIS manager)
The full error is:
"CGI Error
The specified CGI application misbehaved by not returning a complete set of HTTP headers."
I installed the WAMP stack from bitnami.org, and the PHP pages work completely fine when visiting via Apache, which I have running on port 8888. However, due to network configuration and firewall reasons, I have to get this working on the IIS server on port 80. There are other websites running on port 80, including a default website that can't be changed. Unfortunately, I also have to have this running as a virtual directory, such as www.myserver.com/phpapp, instead of as it's own website such as phpapp.myserver.com. The reason for this is that the firewall, beyond my control, requires new passthrough rules to allow access on a new subdomain.
This same WAMP stack from Bitnami is working fine on another server when the php app runs as it's own "website" in IIS, since I can add a new PHP ISAPI filter - but that tab/option is not available on virtual directories.
I've installed the php "Web Service Extension" in IIS Manager. I have tried both php-cgi and the php5isapi.dll in the web-service-extensions. Furthermore, I have tried both of those as the "application extension" under the websites "configuration" mappings.
I've also tried mix/match combinations of the php5isapi.dll and php-cgi.exe for the "web service extensions" and the websites "configuration" extension mappings.
I've tried tweaking a few things in php.ini, (including making sure the doc_root is blank). However, as I mentioned before, this website works fine when visited via the Apache port. IIS points to the exact same directory.
What on earth is causing this error? I've spent quite a bit of time searching online, and it seems this error pops up for a few different reasons. If one had a PHP app that did a raw write to the response without writing the headers first would cause this error. Some PHP apps can cause this error when there is a PHP error resulting in some malformed redirect.
My php error logs are missing in action. In my php.ini I have
error_reporting = E_ALL
display_errors = On
log_errors = On
display_startup_errors = On
error_log = "c:\temp\php.error.log"
But there is never a log file in c:\temp. I also tried escaping the slashes, and tried forward slashes in the path, and the log file never shows up.
Again, I feel compelled to mention that this all works fine via apache, so it doesn't seem like PHP itself is bailing due to some strange configuration (even though I can't find the log file) Not to mention this is the same php.ini that I use on the other computer where this is working fine via IIS (where the php app is it's own "website" instead of a virtual directory).
I don't know what other info to provide - but I'm at my wits end after battling this off and on for several days. If I drop an HTML page in, I can visit that just fine via IIS under this virtual directory. What can be causing this?
The app I'm trying to run is vBulletin. Not sure that it matters a whole lot other than to give credence to the correctness of the PHP in the app.
This should have solve all it, takes care of these issues.
IIS Aid PHP Installer
http://www.iis-aid.com/iis_aid_php_installer