Not much to tell
Indeed – apart from the usual SPAM and some kiddies trying to abuse FTP (failed, of course) and the occasional PHP hickups, all runs smoothly. Just saw an update to the blog software, and some other updates must be installed as well, but there other priorities: This year’s holiday pictures need to be processed first for publication, a new layout of the web, cleaning up the control room….
I wish a day was twice as long!
19-Jun-2007
No upgrade!
Today I attempted an upgrade of the blog software to the next version. Of course, I backed up the current state into a new directory ([.WP21]) and redefined the logical referring to this blog directory, and checked whether everthing worked.
Next, I installed the new version as described on the wordpress site. The basic blog – where nothing changed in configuration – seemed to be working, but the upgrade – run automatically when accessing the admin function for the first time – runs into an error:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 270336 bytes) in /wordpress/wp-admin/upgrade-schema.php on line 105
Allowed memory size of 8388608 bytes exhausted (tried to allocate 128 bytes)
This 8Mb limit is defined as a default in PHP, prior to PHP 5.2 (where it is 16M) and it should be able to override the memory requirements by specifying someting in either php.ini or a .htaccess file in the document root, as is specified in this entry in the WordPress support forum.
In the PHP documentation, there is this chapter on runtime configuration, and digging deeper it shows that you can actually do it in different ways. But this version of PHP (4.2) REQUIRES it to be linked with option --enable-memory-limit , as described in paragraph 1.5 in this page.
I tried this – and it still gives this error. That raises the suspision that PHPSHR has been compiled without this option.
So for the time being, the blog won’t run under WordPress 2.2…. But I can keep the current configuration, where it runs on the saved environment. Hopefully, HP delivers a new PHP version quickly with all building files, as requested on the bootcamp (preferred PHP 5.3 which seems to be the current state).
Update
IT WORKS.
It turned out I just made mistake. PHP_ROOT:[000000]PHP.INI should hold a line:
memory_limit = 16M
and that did the trick. The “=” was not mentioned, or completely overlooked, at the PHP documentation.
Anyway, SYSBLOG now runs on WordPress 2.2. This allows me to change themes.
17-Jun-2007
Back from being away
for two and a half weeks, the only thing requiring direct attention was the system disk being filled to 95% by the weekly backup files of the public webs (4Mb each, though the backup files should be deleted after being zipped) and about 30 bogus “users” of the forums. Not that many but it might become a reason to close them. And, of course, there was the usual spam to be removed, but this task was minimized since I once had the ability to access webmail halfway the holiday and remove what was there at the time.
Some things still need to be looked after, but there is no real hurry: Checking why the backup files are not deleted (must be someything simple, I guess), do some cleanup, do some updates (VMS patches, blogging software (2.2), PHPMyAdmin (2.10), MySQL (5.1), SoyMail (1.3.3, the official one)) and handle all new content. Last but not least, finish the new layout of the webs.
MySQL server crashed
after I posted above text. The post was stored, but for some reason, there has been a problem with file-IO, perhaps on one of the after-image-files?
%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
%CMA-F-EXIT_THREAD, current thread has been requested to exit
InnoDB: Thread 88003328 stopped in file MYSQL_ROOT:[innobase.os]os0sync.c;1 line
501
PTHREAD$RTL 0 000000000004381C FFFFFFFF80A6181C
PTHREAD$RTL 0 000000000006EB58 FFFFFFFF80A8CB58
0 FFFFFFFF8016EDF4 FFFFFFFF8016EDF4
0 FFFFFFFF80374E0C FFFFFFFF80374E0C
mysqld FIL0FIL fil_io 44926 000000000000E4C4 000000000028CDE4
DECC$SHR_EV56 0 00000000001D1094 FFFFFFFF80C65094
DECC$SHR_EV56 0 00000000001D0D5C FFFFFFFF80C64D5C
0 FFFFFFFF801873EC FFFFFFFF801873EC
0 FFFFFFFF801873EC FFFFFFFF801873EC
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
0000, PC=FFFFFFFF80B9ADB4, PS=0000001B
----- end of exception message
0 FFFFFFFF800A90CC FFFFFFFF800A90CC
InnoDB: Thread 107500288 stopped in file MYSQL_ROOT:[innobase.include]sync0sync.
ic;1 line 111
DECC$SHR_EV56 0 0000000000106DB4 FFFFFFFF80B9ADB4
DECC$SHR_EV56 0 0000000000106FB0 FFFFFFFF80B9AFB0
DECC$SHR_EV56 0 00000000001417C4 FFFFFFFF80BD57C4
DECC$SHR_EV56 0 0000000000140B68 FFFFFFFF80BD4B68
DECC$SHR_EV56 0 000000000013A5F4 FFFFFFFF80BCE5F4
mysqld BUF0FLU buf_flush_buffered_writes
39815 0000000000001094 0000000000256CA4
mysqld BUF0FLU buf_flush_batch 40426 0000000000002E74 0000000000258A84
mysqld MY_PTHREAD sigwait 23808 0000000000000408 00000000003C5108
mysqld SRV0SRV srv_master_thread 46457 0000000000004104 00000000003167F4
PTHREAD$RTL 0 000000000005773C FFFFFFFF80A7573C
PTHREAD$RTL 0 0000000000043940 FFFFFFFF80A61940
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF80375CE4 FFFFFFFF80375CE4
%TRACE-I-END, end of TRACE stack dump
%CMA-F-EXIT_THREAD, current thread has been requested to exit
mysqld mysqld signal_hand 86616 0000000000002AE8 0000000000232AE8
PTHREAD$RTL 0 000000000005773C FFFFFFFF80A7573C
PTHREAD$RTL 0 0000000000043940 FFFFFFFF80A61940
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF80375CE4 FFFFFFFF80375CE4
%TRACE-I-END, end of TRACE stack dump
MYSQL_SERVER job terminated at 17-JUN-2007 13:23:14.02
Accounting information:
Buffered I/O count: 5218925 Peak working set size: 90336
Direct I/O count: 273915 Peak virtual size: 413376
Page faults: 44513 Mounted volumes: 0
Charged CPU time: 0 02:09:13.07 Elapsed time: 31 16:55:20.72
This happened once before, on POSTing as well.
The file does not exitrs in the package (not even the directory) so I will have to track these down as well – or leave it as it is; the PHP trouble is more common 😉