[CentOS] [Partially Solved] -Re: PHP Questions on move from CentOS 5.x to CentOS 6.x

[Max Pyziur]

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