On Sun, 24 Mar 2013, Johnny Hughes wrote:
On 03/24/2013 10:45 AM, Max Pyziur wrote:
[...]
Apache's log files show a 503 (for postgresql) and 500 (for mysql) errors
I'm troubleshooting this through obvious channels (looking at logfiles, searching google, sdiff'ing configuration files).
However, if someone has suggestions or answers, please do speak up!
The php versions in CentOS-5 and CentOS-6 are different. You don't say what version you are using and what version you moved to WRT php.
However, if you were running the default, the versions of software that run on CentOS-5 might have to be upgraded to run on the newer php in CentOS-6. (from php-5.1.6 to php-5.3.3)
You might also need to follow the upgrade procedures when moving from the older version of mysql and postgresql in CentOS-5 to the newer versions in CentOS-6. (mysql-5.0.95 to mysql-5.1.67, postgresql-8.1.23 to postgresql-8.4.13)
Upgrading for major versions (ie, from CentOS-5.x to CentOS-6.x) is a major undertaking and data/configuration files usually have to upgraded.
This is unlike moving between point releases within the same major version (ie, moving from 5.8 to 5.9 or 6.3 to 6.4). This is because "minor version" upgrades are designed to just work because of backporting and freezing ABI/API changes inside the Major version ... whereas changing Major versions is a major upgrade and should be planned and testing accordingly.
The problems are separated here (divide and conquer). The PHP/Mysql websites now function.
The issue was a default directive in /etc/php.ini; the directive is short_open_tag. On CentOS 5 it is on; on CentOS 6 is off. Dropping the following into relevant .htaccess files: php_value short_open_tag 1
fixed the problem.
On the PostgreSQL/Drupal/PHP side: I installed four minor releases of Drupal (6.14 -> 6.28), creating new test sites. Each works as designed.
So the PHP/PostgreSQL stack isn't the problem.
Existing websites (using Drupal releases ranging from 6.14-> 6.22) are where the errors are occuring. One person suggested deleting cache* content and session* content in relevant tables. That hasn't restored things; but the hunch now is that it is somewhere in the data.
fyi,
MP pyz@brama.com