In case of trouble, look here

THIS PAGE DOES NO LONGER APPLY, BUT IS KEPT FOR HISTORICAL REASONS
This version of WP doesn’t keep versions, not offers the ability to mark a page “not visible” like the blogroll entries.

After I switched to PHP 5.1, MOD_PHP has been updated and the PHP-engine rebuilt, these problems seem to be gone. But you still can read about it 😉

I don’t like it at all
Sometimes, the (basically Unix-based) software doesn’t work as expected. Even worse, it may crash and leaves you, the reader, without the requested page.

There is nothing I can do about it, since the software is out of my control. I’m not one of the developers, I’m just a user.

If these things happen, the only thing I can say: quit your browser, wait a while and retry. It’s stupid but that’s the way it is at the moment. I hope to get it fixed when new softare has arrived and is found fit for use.

PHP problems
It can happen on login, accessing a page, posting a comment, that the blog sudenly returns a server error:

not a strict CGI response

It’s not your fault, it’s not a WordPress issue. It’s not an issue with tyhe webserver itself. It’s a MOD-PHP problem.
It happens once in a while (actually, more than once) that the PHP engine signals an error, and this is found in the server log. By examining the logs, I found that there are only two errors that show up. Tracking when they occur might give some idea, but I think it’s rather random. One of the errors has bee traced to be deep within the PHP engine that comes from HP and is used in this server. On the other there is no clue where and why it occurs.
These issues are known by HP, and an update on this PHP engine seems to be scheduled, as well as a complete new implementation. Until then I’ll just have to live with the problem.

Database problems
The blogs I maintain all use a MySQL 4 database (MySQL 4.1.14) and its stability isn’t as it should be. For no appearant reason, the server may crash leaving you a message the database cannot be accessed. It’s often – not always – when data is flushed.
This problem resides within MySQL – it might be that this system is a bit too low on memory, but that should never cause “not enough core”, as it most often tell me in the logfile.
MySQL is Unix based and does not have the fine error handling of VMS, and the error may well be translated into “Access Violation” in VMS – having the same value: 12. I’ve seen ACCVIO in MySQL logs, so it would’t really suprise me. Luckily, there is some clue where it happens and at what functionality. But I’m not in a position to get deep into that code.
It happened so often some time ago, that I created a small “watchdog” procedure checking every 15 minutes or so, that MySQL_SERVER is still alive and if not, it will restart MySQL. So if it’s gone, there will be a new instance in at most 15 minutes.
Installing the newly available MySQL package (MySQL 5.2) is on the tasklist, and though installation senms to be straightforward, the data needs to be unloaded from the old database and loaded into the new one, and it needs proper testing before I can use it in the blogs. It may render the blogs unavailable for a while. It is said I could use them side-by-side but there will be some conflicts.
(I prefer not to use MySQL but RdB – Real VMS – but that requires a lot of work within WordPress and debugging PHP code is not exactly an easy task)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.