SYSMGR in the attic

PHP errors?
Operator log of yesterday shows quite a number of this type of messages:

%%%%%%%%%%% OPCOM 22-AUG-2015 07:43:14.63 %%%%%%%%%%%
Message from user HTTP$SERVER on DIANA
Process WASD:80 reports
%HTTPD-W-NOTICED, CGI:2107, not a strict CGI response
-HTTPD-I-SCRIPT, /sysblog/index.php (sysblog:[000000]index.php) phpwasd:
-HTTPD-I-CGI, 2553595354454D2D462D41424F52542C2061626F7274 (22 bytes) %SYSTEM-F-ABORT, abort

The server log tells the same story:

%HTTPD-W-NOTICED, 22-AUG-2015 07:43:14, CGI:2107, not a strict CGI response
-NOTICED-I-SERVICE, http://www.grootersnet.nl:80
-NOTICED-I-CLIENT, 82.161.236.244
-NOTICED-I-URI, GET (9 bytes) /sysblog/
-NOTICED-I-SCRIPT, /sysblog/index.php sysblog:[000000]index.php (phpwasd:) SYSBLOG:[000000]index.php
-NOTICED-I-CGI, 2553595354454D2D462D41424F52542C2061626F7274 (22 bytes) %SYSTEM-F-ABORT, abort
-NOTICED-I-RXTX, err:0/0 raw:357/0 net:357/0

and does so on earlier days. This happens on a number of files, but mainly on index.php and xmlrpc.php; and not just on my address…

It is not caused by PHPcode. I have set in PHP.INI:
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
error_log = user:[phplog]php_errors.log

and the last entry in the logfile is 31-May-2015 – when I was experimenting with highr PHP version.

If it were reproducible, WATCH would show the reason, But it seems to be at random, I cannot recognize a pattern here. And without crash data, it will not be easy to find the cause.
There may be one thing though: the maximum execution time. Reset to 60 seconds as before, it may be a little too low so it may cause a PHP-worker process to stop before it has reached the end of processing – hence “ABORT” – by the PHP-engine. So I gave it a bit more time (30 seconds); See what happens next. another one may be max_input_time, kept to the default value of 60 seconds, for now.

This is the only issue, as far as I can see. The system is at about 75-80% of internal memory, and without a lot of hard paging (to disk, that is) – there is apparently enough free space to be used. That is reflected in T4 data: Low hard page rate (unless a process is started, especially a PHPWASD process, I guess. But that is to be expected).
One thing to improve performance of PHP would be to install PHPSHR. Well, some time next week 🙂

New licenses installed
My current licenses expire September 7th, so to be sure I requested a new set. Within a day, John Egolf,  who handles hobbyists license at HP,  sent me the new set. This comes as a command procedure so it is sufficient to copy it to the VMS system and execute it.
So VMS,  layered products and compilers are covered until 18-Sep-2016.
A new license for PMAS has also been requested at Process, Hunter has sent me a new one that will expire two weeks earlier. Installed that one as well.

It helped
Not just restarting the server.
I still had the maximum execution time for the PHP scripts set to 10 minutes, I used that to upgrade this blog when still on 512 Mb. Now I’m at 1.5 Gb, I upgraded the Tracks blog as well, using the same setting; but that database is significantly smaller than this one, so it finished well within this timespan. But I forgot to reset this parameter.
So that has been reset as well.
This may, or may not have contributed to the low performance, but there were quite a lot of worker processes that ran PHPWASD: (which is the 5.2.13 version of PHPWASD.EXE) within a far higher memory demand than I’ve seen before, it is possible.

Anyway, though not lightning fast, it is better than yesterday.

I’ve seen on the Wordprsss site that there is a program (plugin?) that creates static pages from posts; it comes with Apache’s MOD-REWRITE settings, It may be useful, so I’ll give it a try. The challenge will be to translate MOD-REWRITE to mapping in WASD :).

Load settles
The load seems to settle a bit; I ran into 100% memory yesterday evening, and there wasn’t much movenemnt during today:

It doesn’t mean all is well. SYSBLOG takes ages to load, if it all succeeds! There are quite few WASD worker proce3ssed in the system and many are referred to by the system itself. I’ll have to restart the Webserver, I think…

Same PHP warnings since startup
Six times, since startup. All in admin – some in dashboard, some in admin-ajax.php:

%HTTPD-W-NOTICED, 18-AUG-2015 15:12:54, CGI:2107, not a strict CGI response
-NOTICED-I-SERVICE, http://www.grootersnet.nl:80
...
-NOTICED-I-CGI, 504850205761726E696E673A20204D6F64756C652027646F (288 bytes) PHP Warning: Module 'dom' already loaded in Unknown on line 0.
-NOTICED-I-RXTX, err:0/0 raw:1094/0 net:1094/0


(No Stack overflow, no ACCVIO – because memory is sufficient.)

No idea where this comes from, the weird thing seems ” Unknown” on line 0. So it comes ‘out of the blue’. It’s just a warning, but still: it shouldn’t occur…

For the rest: All is well.

Update ahead
Downloaded WP 4.2.4 yesterday, in preparation to stay up-to-date. Just found out that 4.3 is out; so downloaded that one as well, to be installed ASAP. So there will be a short interruption, likely tonight.

Results from last maintenance job
The results of the last maintenance job were not exactly lost; Info-Zip creates a temporary file and will move it to the destination (by COPY the file and DELETE it afterwards). These temporary files still exist, since COPY didn’t work since the destination files was not available), DELETE didn’t execute. I located these files and examined them, found they were complete, so I renamed them; they still need to be moved to the archives – another maintenance job to do tonight 🙂
Funny
It is not the fastest or easiest way to add or edit content, but WordPress for Android does work, even on a site you handle yourself. This update proves it 😀

UPDATED
Just updated WordPress to version 4.3, and Akismet to 3.1.3. So I’m up-to-date – for this blog. Trips, Tracks and Travels is done as well, I only have to find a good theme.
This means a lot of old stuff can now be removed from disk.

Also added RSS (using rrs2 (standard available in WP) to both blogs.