Fine so far
The system has been working fine since the last MySQL crashes and I mailed to the mailing list for assistance. Not any process in outswapped mode (LEFO or HIBO) found druing the last days, even when PHP was running. and for the rest there seems to be no trouble either. This is what the system should run like 🙂
I downloaded latest patches, I may do the update tonight as well, but since it requres one or two reboots, I prefer to have some more time.
I also wanted to install ClaMAV – an OpenSource virus scanner that is ported to VMS but with the currently installed executables I cannot extract the files from the file – it’s a .GZ file and Gunzip seems to locate more than on e entry so won’t process the file. There maight be something wrong, whatever I try it fails. See if I can get a decent (more recent) version of Gunzip somewhere – freeware CD, most likely.
Another thing to do is install CFIS – Samba – but again, too late in the day to start with it. I;ll have to spin up a disk and keep it online. No problem since I got one in this shelf available, but seeting it all up needs to be thought over and prepared well. Maybe some tim ethis week – if programming doesnt take all time (which is quite likely).
I found that the new package I installed on the forums (User_Shield) will actually allow a bunch of inactive users be activated or deleted in one push – but the buttons show up in the SubSilver template only, to in order to flush the fake members, it’s needed to change the forum’s look. I think I’l have to update the PHP code of the theme in order to have the buttons available in the Galaxian theme used.
Some more data might be added to Trips, Track and Travels – there is still a number of tracks to publish, even where MapSource refuses to startup at the moment. Garmin has been notified, waiting for the answer. Likely it will be that a files needs to be re-installed.
But No….
When storing this post, MySQL crashed again when I tried to access the page:
071209 21:54:32 InnoDB: Error: Write to file /database/mysql41/ibdata1 failed at offset 0 1048576.
InnoDB: 212992 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 12.
InnoDB: Check that your OS and file system support files of this size.
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
071209 21:54:32InnoDB: Assertion failure in thread 72258240 in file MYSQL_ROOT:[innobase.fil]fil0fil.c;1 line 3922
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
mysqld got signal 10;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=2
max_connections=100
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 72191 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
InnoDB: Thread 72159936 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 line 501
InnoDB: Thread 72209088 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.ic;1 line 111
%CMA-F-EXIT_THREAD, current thread has been requested to exit
InnoDB: Thread 82752192 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.ic;1 line 111
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PTHREAD$RTL 0 000000000004367C FFFFFFFF80E6367C
PTHREAD$RTL 0 000000000006E9E8 FFFFFFFF80E8E9E8
0 FFFFFFFF8016F054 FFFFFFFF8016F054
0 FFFFFFFF80376E0C FFFFFFFF80376E0C
DECC$SHR_EV56 0 00000000001D2DC4 FFFFFFFF8106ADC4
DECC$SHR_EV56 0 00000000001D2A8C FFFFFFFF8106AA8C
0 FFFFFFFF801877CC FFFFFFFF801877CC
It might be this file is too small:
$ dir database:[mysql41]/siz
Directory DATABASE:[mysql41]
ibdata1.;1 53248
ib_logfile0.;1 4096
ib_logfile1.;1 4096
Total of 3 files, 61440 blocks.
that is:
$ dir database:[mysql41]/siz=unit=bytes
Directory DATABASE:[mysql41]
ibdata1.;1 26MB
ib_logfile0.;1 2MB
ib_logfile1.;1 2MB
Total of 3 files, 30MB
Should not be a problem. Or is it because the file cannot be extended:
$ dir database:[000000]/sec
Directory DATABASE:[000000]
000000.DIR;1 [SYSTEM] (RWED,RWED,RE,E)
BACKUP.SYS;1 [SYSTEM] (RWED,RWED,RE,)
BADBLK.SYS;1 [SYSTEM] (RWED,RWED,RE,)
BADLOG.SYS;1 [SYSTEM] (RWED,RWED,RE,)
BITMAP.SYS;1 [SYSTEM] (RWED,RWED,RE,)
CONTIN.SYS;1 [SYSTEM] (RWED,RWED,RE,)
CORIMG.SYS;1 [SYSTEM] (RWED,RWED,RE,)
INDEXF.SYS;1 [SYSTEM] (RWED,RWED,RE,)
mysql41.DIR;1 [SYSTEM] (RWE,RWE,RE,E)
SECURITY.SYS;1 [SYSTEM] (RWED,RWED,RE,)
VOLSET.SYS;1 [SYSTEM] (RWED,RWED,RE,)
Set the directory to W:RE (alas, PHP dos not (yet) take ACL in account) and make MySQL_SERVER the owner. If it happens again, failure to extend the file should not be the cause.