SYSMGR in the attic

New cables
Since the systems have been moved to another position, the cabling for monitor, keyboard and mouse weren’t long enough to connect to the server, so I ordered extension cables/ For keyboard and mouse, I envisioned that USB extensions would do, and this one came with build-in amplifiers. But nothing happened, so I decided a reboot – which failed: there were user files open on two disks and that meant these could not be dismounted, and the system became overloaded – for no appetent reason. Tried to stop some processes but the system became slower and slower. CTRL_P, and crash (to find out what was going on) was required. After restart it became clear that there was a TCPIP process that took all CPU and caused excessive paging.
But the system started without a hitch – almost: after upgrading WordPress (to a new directory) I forgot to change the logicals for the blogs. Done that by hand so it now all works again.
There is one more short downtime to be expected, when I change power tomorrow.

The USB extensions don’t work so I have ordered the normal PS2 extension cables. the USB extension have found good use by moving the printer and scanner, and now I have some more room on the workplace to add more machines.

Nothing special
The maintenance log shows nothing particular. it has been rather silent.
PMAS statistics for October
Total messages    :   1233 = 100.0 o/o
DNS Blacklisted   :    108 =   8.7 o/o (Files:  1)
Relay attempts    :    192 =  15.5 o/o (Files: 30)
Accepted by PMAS  :    933 =  75.6 o/o (Files: 31)
  Handled by explicit rule
         Rejected :    386 =  41.3 o/o (processed),  31.3 o/o (all)
         Accepted :    206 =  22.0 o/o (processed),  16.7 o/o (all)
  Handled by content
        Discarded :    162 =  17.3 o/o (processed),  13.1 o/o (all)
     Quarantained :    154 =  16.5 o/o (processed),  12.4 o/o (all)
        Delivered :     25 =   2.6 o/o (processed),   2.0 o/o (all)
Even the number of relay attempts has been pretty low, the largest amount of attempts (100) were on 30-Oct-2015, sent from 14.222.40.34 (outside address) with a faked sender account (any@grootersnet.com, but that can only be sent from this address :))
Just the number of SYSLOGD log files is larger than usual; there have been a number of days where someone tries to retrieve large amounts of data from the site – like the YAHOO-based access a few days ago – but there isn’t a logfile scanner – yet – so I would have to look into that (one of the pending projects is just about that…).
System load has been stable as well over the last four weeks. Except for the reboot due to moving the system:

So nothing special….

A few days ago, there was one address (68.180.230.158) that had many, many links open to the site, since it connected to port 443 and Diana, suspicion arose someone was trying to access one of the secure sites. So it was blocked access to all of them: trying to access the site will just drop the connection.

The server log showed the same address encountered four times an ACCVIO on accessing the entry of this blog:

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000597C000, PC=FFFFFFFF8083D9A0, PS=0000001B

for times in a row.
This error has occurred a few days earlier as well, but from a different origin, on a different program counter:

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000597C000, PC=FFFFFFFF8083D9B8, PS=0000001B

The difference in program counter is obvious since this is a separate process that can be located elsewhere in memory, but since the virtual address is the same, it is the same error. ACCVIO will cause the process to abort but when a next process is started immediately afterwards (which is possible in this particular case) it can be loaded in the same physical location and produce the same error. Here, it is the PHP executor, this will cause WASD to start worker processes on the fly – probably in the same location.

Reason mask 04 means the process tries to modify a location that is read-only, or inaccessible. It may also mean that an attempt was made to expand the user stack – as the HELP/MESSAGE output states:

This message is also displayed when an attempt has been made
to make the user stack larger than the user’s virtual address
space permits.

I noted this error before, and rather often, when the system was on 512 Mb of memory, so it is likely to be related to lack of virtual memory – a too low setting of process parameter pgflquo of user HTTP$NOBODY (set to 500.000). So I could increase this value, but since it only occurs on higher loads from one address, this can be deferred.

On older systems, I could look at system parameter VIRTUALPAGECNT but that is obsolete in VMS version 8.4 and set to the max possible (2147483647, the default value):
SYSGEN> SHOW VIRTUALPAGECNT
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
VIRTUALPAGECNT 2147483647 2147483647 2048 2147483647 Obsolete
SYSGEN>

A few issues
There was too little time last week to look if everything works properly, so it was only this morning that I found that there are a few issues, but only in the operational site (so far), that needs to be looked at: The list op OPERATOR logs won’t show up (gives me an extract of the access log), for instance, though the link is all right. So there may be more that’s not working as it should. The question is, however, why this happened. There was no change in environment that I’m aware of. So there is some investigation to do.
The result:
Running the procedure that creates the index file, didn’t finish as intended:

$ @SMAN:[com]indexoperlogs.com
Creating index file of operator and FTP logs
%RMS-F-FUL, device full (insufficient space for allocation)

So where has the space gone? Creating a list on this device won’t work either. so put it elsewhere (with enough free space):
$ dir/out=$116$dka106:[000000]x.x/size web_disk2:[000000...]
$
to get a full view on all what’s on the disk (which is actually a logical one).

No matter what, I can remove the old WordPress versions, saving me some 100.000 blocks. the big win however is removing all images of Trips, Tracks and Travels from the disk, because these are moved a few weeks ago to another disk, and it seems to work fine. That means 10 Gb….. Of course, I used a script (Q&D) for this operation.
Why the disk was so full: I added a view videos to Tessa and som eother stuff on a disk that was already pretty filled up. It fitted – until the operatorlog.html file was once more created – a week ago… The logfiles were a bit larger than normal because Daphne was started (and this logs on Diana as well).

And the text on the home page needs to be updated and set s well, this is not done automatically, and I didn’t add this on the last reboot.

Reorganization
Have been offline for an hour: reconfiguration of my workspace / recreation area,  so moved the server. Took a bit more time than estimated because I had an appointment with the dentist, and second startup failed after starting TCPIP because there was no Internet connection. But now it works again.