SYSMGR

We're a bunch of Computers: Diana, Daphne, and Dido, called the 3D-cluster, running OpenVMS, Io running OpenVMS as well (in some obscure role in the network) Aphrodite, Athene and Irene running WindowsXP-Pro (SP2, of course) and Cerberus at the edge of the Network, with Charon, also running Linux, as standby. SYSMGR takes care of us.

Monday, April 3

03-apr-2006

PHP/MySQL trouble
PHP is very slow - there are regular time-outs and other problems, and for some reason, the MYSQL_SERVER crashed this afternoon on access violation. Guessed it wss because of shortage in memroy (it did tell "not enough core' ) so I raised APACHE$WWW's pagefilequota (500.000 to 2.000.000).
It didn't help, really....
Worst: I seems to have lost entered user data!
Patches and reboot
I installed some patches and rebooted Diana, after having made a system disk backup. Changed the default bootdevice to be the new system disk (before boot, of course)
Still trouble
After boot, it turned out that the database volume wasn't mounted - the container had not even been loaded. MySQL wasn't started, it seemed. No, of course not: since the volume containing the database wasn't available!.
Started it manually, and it tuned out again that I lost data of users I entered. More: Wordpress cannot find it's database???? PHPMyAdmin can neither, but Mysql itself has no trouble accessing the Wordpress database:
mysql> use wordpress;
mysql> select * from ws_options;
is no problem at all, but:
mysql> use mysql;
mysql> show databases;
didn't show up any of the added databases either! So I decided to recreate the wordpress database:
mysql> create database wordpress;
and it says:
Cannot create database: wordpress already exists
and
mysql> show databases;
now shows them all!

But when starting Wordpress on the web, it still cannot find it's database, and phpmyadmin doesn't see any other databases than the default ones.

MYSQL log gives no clue whatsoever on what might be the case. Nor does PHP...

Wordpress data cannot be read - by PHP
Accessing the wordpress database table wp_options - the one that cannot be read by phpmyadmin and Wordpress after line 61 - could well be read by mysql so the data itself is correct: it contains the RSS-lines on line 66 and further; the point is that one of the fields: wp_iptions.option_name, is quite long: RSS_<a number taht's over 20 characters in size>. These indeed showed up in the administration panel of Wordpress.
Since it's a problem for two distinct PHP programs, the guess is that is is the php_mysql module that has a problem.

0 Comments:

Post a Comment

<< Home