Power break
once more, at about 8:00. And again, Diana didn’t startup, and I have no idea why not. But a manual power cycle (wait a few seconds before powering up) at about 18:30 showed nothing was wrong at all: it came up as it should. Probably it is some trouble with the HSZ50 controller that has to initialize properly, before the Alpha system would try to catch up? Who knows. This proves a UPS is “required hardware” !
>Web trouble
That is: some. The webs I uploaded yesterday (using JAlbum’s UPLOAD facility) have one flaw: the back link to the index page is wrong. This has been manually adjusted and now it’s allright.
>Log scan
has worked properly last night, after I adjusted the commandfile yesterday. So all spam from 2007 up to (including) yesterday is now logged.
>MySQL crashed
because the database wasn’t closed properly. This mail was entered by when trying to access the site, MySQL went down on an Access Violation:
InnoDB: Thread 107565824 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.
ic;1 line 111
InnoDB: Thread 87995136 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 line
%CMA-F-EXIT_THREAD, current thread has been requested to exit
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004381C FFFFFFFF80A6181C
PTHREAD$RTL 0 000000000006EB58 FFFFFFFF80A8CB58
DECC$SHR_EV56 0 00000000001D0D54 FFFFFFFF80C64D54
DECC$SHR_EV56 0 00000000001D0A1C FFFFFFFF80C64A1C
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=000000000028CDE4, PS=0000001B
----- end of exception message
mysqld FIL0FIL fil_io 44926 000000000000E4C4 000000000028CDE4
mysqld BUF0FLU buf_flush_buffered_writes
39815 0000000000001094 0000000000256CA4
mysqld BUF0FLU buf_flush_batch 40426 0000000000002E74 0000000000258A84

but looking into the logfile, I think the recovery, or the initialisation of logfiles failed:

070112 18:36:31 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 18391400.
InnoDB: Doing recovery: scanned up to log sequence number 0 18391400
InnoDB: Last MySQL binlog file position 0 407933, file name ./diana-bin.000034
070112 18:36:31 InnoDB: Flushing modified pages from the buffer pool...
070112 18:36:31 InnoDB: Started; log sequence number 0 18391400
070112 18:36:31 [ERROR] After InnoDB crash recovery, checking if the binary log
'./diana-bin.000034' contains rolled back transactions which must be removed fro
m it...
/$116$DKA100/000000/WEB/MYSQL/MYSQL/VMS/BIN/mysqld.exe: ready for connections.
Version: '4.1.14-log' socket: '' port: 3306 Source distribution
070112 20:30:09 InnoDB: Error: Write to file /database/mysql41/ibdata1 failed a
t offset 0 1048576.
InnoDB: 212992 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 12.

Somewhere in the code, it seems -1 (MINUS one) bytes were written.

InnoDB: Check that your OS and file system support files of this size.

I don’t think there is any OS able to write that number of bytes!

InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 12 means 'not enough core'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/mysql/en/Operating_System_error_codes.html
070112 20:30:09InnoDB: Assertion failure in thread 88093440 in file MYSQL_ROOT:[
innobase.fil]fil0fil.c;1 line 3922
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.

Well, MySQL wants an error report:

InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

and they will get it – after I have contacted Jean-Francois Pieronne (who ported MySQL to VMS)