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 at brama.com