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>
While that behavior may well be an indication of an Apache DoS, that’s obviously a Yahoo IP address, and one that’s been used with Slurp; with a Yahoo spider.
Use of robots.txt might reduce the occurrences of of this, though there does appear to be a secondary problem being triggered by the spider.
Lowering the connection timeouts — the default is often too large — might clear up the dangling channels.
Also make sure you’re on the “current” Apache port for OpenVMS Alpha, too.
I already found out it is a Yahoo address, and indeed, likely a bot to retrieve all data. But why do they try on a secured site (port 443…), Yahoo should expect to have no access unless authenticated. So a DoS attack is a possibility, but I doubt it will be run by Yahoo.
However, the number of session was not noticed on the server but on the router. It could well be a router issue, because the next day I had to reboot the router (said I was out of internet connections – when accessing my site from the outside. This is weird!). Probably a bug, it happens 🙁 but I didn’t report it yet.
Better check my router logs on this and contact Draytek.
Oh, and Apache: I’m NOT an Apache user, because IMHO, this server is a bad choice for a webserver on VMS. There are alternatives that perform way better than Apache in all aspects. And offer far better tools.
But I agree that it is always best to keep up-to-date. No matter which software you use.