Firstly forgive me if my terminology isn't entirely accurate. I have only limited knowledge on this subject, but will best try to convey the problems we are having. My server administrator is trying to deploy php 5.5.9 on a live server. Originally the intention was to install php 5.4.x, but we opted for the latest version instead (a manual compile is required regardless due to the o/s)
The O/S is OpenSuse 12.1 and the server is a Plesk server (Plesk Version 11.0.9) with Apache 2.2.1. This particular o/s does not have the ability to update php automatically so everything has to be done manually. Since we didn't want to risk screwing up the server (currently running with php 5.3.8), we opted to install a second version of php alongside the current one. The instructions we followed are outlined here: http://kb.parallels.com/en/114753
After numerous failed attempts due to missing libraries during compilation, we were finally able to compile php 5.5.9 without error and then proceeded to run tests with 'make test'
Unfortunately, the test results came back with 32 failures and 20% of the total tests were skipped. A total of 13011 tests were done, 10410 of which were completed. The TEST SUMMARY can be downloaded from here: http://uploaded.net/file/v6ug55l8
Anyway, deciding we might aswell give it a try, we applied the changes as indicated in the first link above to the vhost.conf. However, it didn't work, and the vhost then returned Internal Server Errors for every page regardless of script or extension. The errors logs sadly do not indicate any errors, only a whole ton of internal server errors recorded by mod_security. We did notice a huge number of these in the error log: Warning: SuexecUserGroup directive requires SUEXEC wrapper. But, it doesn't seem to be related, as the same error goes back several weeks.
So, we're stuck without any idea what to do next. Our next attempt will be to try and compile a php 5.4.x instead, as perhaps something is bumping heads with 5.5.9...
Any and all advice will be appreciated. As per the opening statement, I'm not an expert here, so if you need any additional information about the machine and it's server, feel free to ask. Thankyou for your attention!
Problem solved. The vhost's CGI-BIN needed to be CHMOD 755 and not 775.
Related
We have a couple of PHP scripts that can be run from the CLI. These both may take several hours to complete and have historical run okay (occasionally requiring memory limits to be increased). However, on our production server, the scripts, after a relatively short period of time, will stop running with a segfault error:
/home/*******/bin/runlive: line 3: 9558 Segmentation fault php
$HOME/********/sites/live/index.php" $*
(runlive - just sets up a path)
We have tried running this on a different server with the same database data and codebase and do not get the same error.
We have tried moving the production server to a new VM to discount hardware as the cause and this did not resolve the issue.
We have tried using the 'catchsegv' utility to output information about the segfault:
sudo /usr/bin/catchsegv runlive [script name] > catchsegv.txt
but this did not output anything.
If I run these script on the same dataset, it does not always fail at the same point when processing user records which I think discounts it being a data issue.
Any ideas on how to diagnose this, much appreciated.
Any ideas on how to diagnose this
There are several possibilities:
Bad hardware
Bad software
Bad software could be subdivided into:
Bad combination of libraries (bad version combination, powned server, etc.)
Bad environment (e.g. particular host name, or installation paths)
You want to use divide and conquer approach to eliminate possibilities.
You've already taken the steps to eliminate hardware, but this is not yet entirely conclusive.
You'll probably want to do the following:
Build another VM (preferably in a place that you know is running on different physical machine), with exactly the same versions of all installed packages, using trusted source (don't just copy packages from the original machine).
Check weather the crashes still reproduce. If they do, your original server is probably not powned, and the hostname probably doesn't matter.
If the crashes don't reproduce, you've eliminated 2.1 (bad combination of versions), and now need to examine differences between the two machines with a fine comb.
Continue dividing the problem until you find the root cause.
Or you can take the bottom-up approach: run the php binary under debugger, reproduce the crash, look for upstream bug reports with similar stack trace, apply fixes for these bugs (if you find any such bugs), etc.
last year i have purchased an encrypted script wich run two crons jobs, a month ago crons stop working and i have talk to the hosting company they said its script problem , The PHP cron file works fine without any errors when visited by browser, the script provider told me that this issue should be fixed by hosting service and refuse to help !
here the command used it run every 10 MIN /home/username/public_html/cron/cron.php
cPanel Version 64.0 (build 24)
Apache Version 2.4.25
PHP Version 5.6.30
my question is it true upgrading the PHP version will affect cron job and how can i solve this?
thanx
In short, yes, upgrading PHP can effect your scripts -- the crons aren't run by Apache or PHP; the crons run from the OS level.
Your PHP upgrade is most likely affecting the crons in one of two ways:
The upgrade was large, like PHP5.6 to PHP7.0 and there's a deprecation warning somewhere (which will output in the crons' log) or the script is running some code that's now fully deprecated; most likely a query or a class/method named after a reserved word. Your logs will have more info, just make sure you have debugging turned on, otherwise your errors will be suppressed.
The new PHP settings from the upgrade have disabled some of the allowed rules from an older PHP version, such as getting away with empty or unassigned variables, and now your script is running into errors (ie. using a variable that doesn't exist, such as $_REQUEST['something'], which would have been empty but now returns an error that effects the rest of the script).
To fix this you need to know what the problem is. The easiest way is to access the log files that crons often create. If you don't get that with your host, ask them for it, or ask them to send you a copy of the error that's being created -- a quick Google on the error will tell you what the problem is. But without knowing more about the script or the error log, you probably won't get a better answer.
old command is working its just me i did copy past from my old backup and i forget the PHP at the firts off command ! nothing has changed the command should be like that exp : php /home/username/public_html/cron/cron.php
We're currently banging our heads against the wall with our Azure setup. It might be us who lack skills, but we cannot figure out how to run our instances more smoothly. We run PHP 5.6 w. wincache on Azure. We have multiple instances, which share most of the files. However, it appears that the PHP cache is not shared, and some times when we deploy some files will magically be corrupt. For example a syntax error in a file which should not have a syntax error. This results in our platform throwing up, because, well syntax error in a file.
The only way to fix this appears to be a hard restart of our services, which takes time both in terms of the restart and warming the cache. We are trying to move away from the PHP setup, but unfortunately it's what we have currently.
Is there anyway to flush the system or specific instances without having to restart everything? It's kind of a ball toss if our release goes well or has loads of issues, which in turn makes us more hesitant to release.
How can I determine what add-ons to apache will be required for my php code? I have legacy php code that was setup a long time back (and we dont have the documentation on what was done at that time). I need to get this application working on another new server, but apache has yet to be installed.
I would like to install only those components which are necessary.
a php module, pal
to run php code you need mod_php installed. That's it.
if you're talking of PHP extensions, that's another matter and it's hard do tell.
I'd make it this way: log all errors and watch for "undefined function" ones. And turn appropriate extensions on.
It have to be done anyway.
Legacy code being run on fresh PHP installations usually flood your logs with errors.
I am running a PHP site that uses Ajax and jQuery as well. The site will run fine for quite some time, and suddently my pages (and ajax-retrieved sub-pages) comes back with the message
PHP has encountered an Access Violation at 77FCAFF8
It seems that rebooting the server corrects the issue. Running PHP Version 5.1.6 (Windows NT 5.0 build 2195). I did a some searching on here and some other sites, and there seems to be no fix..
URL REMOVED
UPDATE:
I think I'm on to something.. will get back to you.
UPDATE
After reviewing the IIS setup, i noticed there was no Handler Mapping setup for the website. This, of course begs the question - how did it ever work in the first place, when it was originally setup this way!? I added the handler mapping and it seems to be Okay so far.
UPDATE
The problem popped its heads out again this morning after 36 hours without encounering it. Back to the drawing board.
UPDATE
We ended up just moving the site to a secondary web server where we were able to upgrade PHP without an issue.
This is a PHP issue somewhere. You could spend some time narrowing down which function you're using that is causing the problem. I would instead upgrade to a newer version of PHP. If still no luck, try a slightly older version. There have been significant changes with version 5.3.2.
After some research I think this may be the solution (Taken from http://bugs.php.net/bug.php?id=28929 ):
[2010-06-11 15:12 UTC] in2ishun at yahoo dot com
***************** SOLUTION!!!!
I realize this issue is AGES old, but it still manages to be the top hit on Google searches as of now (6/2010).
I fixed my own instance of seeing this error. W2k3, IIS6, PHP 5.2.6, MySQL 5.1.
The problem is in the pathing. When I used the MSI installer for MySQL without doing an "advanced" installation (where I could manage the install details), it added a path to the system environment that contained spaces. Even after changing the path environment to use the Windows short-name location of the mysql bin directory, it still didn't work.
The solution was for me to reinstall mysql and set the default installation path to just off the root (e.g. C:\mysql). Once I did that the error went away and my app started working.
There are a number of sites with a variety of potential solutions to this issue and several of them mentioned paths and the "libmysql.dll" file (in the "bin" directory of your mysql installation).
If this helps you solve your problem, consider leaving a comment here so others can see that it works.