Power fail and the aftermath
This afternoon another power failure occurred – its cause is still a mystery – and Diana didn’t start all by itself. The usual problem, I assume: The Alpha trying to boot when the disks aren’t ready yet.
Of course, I was elsewhere, experiencing the outage while working. It couldn’t come on a less appropiate moment, I had to give a presentation on webservers on OpenVMS and wanted the system as an example on how to set things up.
Luckily, my son was able to help me out being instructed by phone. We found out reset didn’t seem to do anything, but power cycle did – in one go, for a change.
Within 10 minutes the system was up and running again – except for the webserver, to start with. I could access Diana by SSH so I had the opprotunity to settle that: It turned out the WASD server image wasn’t fully built, as it seemed. Rebuilding the server solved that problem (all files and procedures were still present). Mail and the operator entry now did work, and so did the static pages. PHP however kept failing: image PHPWASDSHR could not be activated – a good example of WASD’s WATCH utility – to locate the cause of error in ‘real time’. I used that.
But solving the problem would have to wait untill after the presentation, when I got home.
What could have been a cause of trouble, was a clean-up done some time ago, and rebuilding the WASD server might have changed file protections. In the end, it did for some directories, but whatever I tried, the problem kept appearing oin all PHP code (blogs, forum and PHPMyadmin). Showing the PHP environment (PHP-Info) showed that MySQL wasn’t loaded at all, despite all protection and logical names were properly defined.
A sudden idea made me run the PHP-code directlky using the PHP.EXE. This immediately showed what happened: a message either overlooked, or not outputted, when the index.php file is accessed over the web: The MYSQL41.EXE file was not valid as an PHP library file.
This triggered memory: I’d seen the same error after building the MySQL 4.1 engine, when any of the linked sharable images was missing – or didn’t reside on SYS$LIBRARY.
So I took a look on what has to be defined:
$ DEFINE/SYS/EXEC /NOLOG LIBZ_SHR32 sys$library:libzshr32-1_2_3_ev56.exe
$ DEFINE/SYS/EXEC /NOLOG LIBSSL sys$library:OPENSSL098A_LIBSSL_SHR32.exe
$ DEFINE/SYS/EXEC /NOLOG LIBCRYPTO sys$library:OPENSSL098A_LIBCRYPTO_SHR32.EXE
I checked the existence of each of these three files and found LIBZ_SHR32 non-existing – at least, the file got another name: libzshr.exe.
After changing this logical to
$ DEFINE/SYS/EXEC /NOLOG LIBZ_SHR32 sys$library:libzshr.exe
the problem was solved.
When trying to access WordPress as next action, MySQL crashed, and I found it had crashed due to tye same error: LIBZ_SHR32 did refer a non-existing file. But once restarted by the watchdog, I could enter this blog entry without a problem.
This file was renamed to build Clamav… But since LIBZ_SHR32 now refers to an existing file. it look as if all images using this image, are now up and running.