WP update
Just updated WordPress to version 4.9 – 159 years after OpenVMS time started running – just after I got the message from WordPress.org.
06-Nov-2017
Maintenance report
Nothing wrong with the maintenance job:
PMAS statistics for October
Total messages : 4087 = 100.0 o/o
DNS Blacklisted : 108 = 2.6 o/o (Files: 1)
Relay attempts : 26 = .6 o/o (Files: 31)
Accepted by PMAS : 3953 = 96.7 o/o (Files: 31)
Handled by explicit rule
Rejected : 3074 = 77.7 o/o (processed), 75.2 o/o (all)
Accepted : 190 = 4.8 o/o (processed), 4.6 o/o (all)
Handled by content
Discarded : 400 = 10.1 o/o (processed), 9.7 o/o (all)
Quarantained : 253 = 6.4 o/o (processed), 6.1 o/o (all)
Delivered : 36 = .9 o/o (processed), .8 o/o (all)
Even no large anti-relay files. Most have a few entries, but none is larger than 4 blocks (2Kb)
More on PHP
I changed the workingset parameters of the WASD scripring user (HTTP$NOBODY) because these may cause problems with PHP:
but that didn’t make any difference for this, just that the blogs run faster, at least without updates… But PHP 5.4 and up won’t run once it fails. Though Mrak said that the adapted PHPWASD version would output the io-error code, none is shown. What I do see are the settings of the HTTP$SERVER account (that is: What’s left of the quota): Large enough.
|19:53:51.14 CGI 1374 0004 CGI VARIABLES 1,632 bytes|
|19:53:51.21 CGI 2214 0004 CGI NOT a strict CGI response!|
AST:1944/2000 BIO:1949/2000 BYT:4953856/4999424 DIO:998/1000 ENQ:450/500 FIL:286/300 PGFL:461376/500000 PRC:0/100 TQ:97/100
|19:53:51.21 ERROR 0437 **** INTERNAL CGI:2215, not a strict CGI response|
|19:53:51.22 ERROR 1122 0004 RESPONSE DCL:5321 (basic-only) 502(502) "Script did not provide an acceptable response."|
|19:53:51.23 GZIP 1008 0004 RESPONSE DEFLATE no, minimal content-length|
|19:53:51.23 REQUEST 1162 0004 REQUEST STATUS 502 (Bad Gateway) rx:377 tx:917 bytes 0.109368 seconds 11,831 B/s|
It’s getting worse. At some point, there is another response: The browser cannot find the site, and WATCH shows:
|20:15:49.47 CGI 1374 0002 CGI VARIABLES 1,642 bytes|
|20:15:49.47 REQUEST 1162 0002 REQUEST STATUS 000 (Unknown Code!) rx:389 tx:0 bytes 0.002929 seconds 132,787 B/s|
But when requested immediately after a restart, the site – even the admin pages – will show when the URL is entered in the browser – but next actions will cause the same error – even:
|20:18:14.11 CGI 1374 0002 CGI VARIABLES 2,023 bytes|
|20:18:14.11 NET 1802 0001 CONNECT ACCEPTED 82.161.236.244,38057 on http://www.grootersnet.nl,80 (0.0.0.0) BG37011:|
|20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 1 'Status: 502' 11 bytes|
|20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 2 'Script-Control: X-error-text="Cannot chdir("/tracks/wp-admin"), i/o error."' 84 bytes|
|20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 3 'Script-Control: X-error-module="PHPWASD"' 40 bytes|
|20:18:14.11 CGI 2326 0002 CGI RESPONSE header line 4 'Script-Control: X-error-line=1384' 33 bytes|
|20:18:14.11 CGI 2588 0002 CGI RESPONSE stream mode|
|20:18:14.11 ERROR 1122 0002 RESPONSE PHPWASD:1384 (basic-only) 502(502) "Cannot chdir("/tracks/wp-admin"), i/o error."|
|20:18:14.11 GZIP 1008 0002 RESPONSE DEFLATE no, minimal content-length|
|20:18:14.11 REQUEST 1162 0002 REQUEST STATUS 502 (Bad Gateway) rx:748 tx:917 bytes 0.006836 seconds 243,581 B/s|
even when CGI-compliance is disabled….
WordPress update
Nevertheless, the update of WordPress (to 4.8.3) was straightforward.
05-Nov-2017
Internet connection broken
Yesterday at 11:15 (or so) the internet connection was down at my ISP – it looked like a broken cable. They rerouted at the end of the afternoon so in the evening I did have connectivity again. This morning however, it was down again for a few hours, due to repair. Why they removed rerouting before the rupture was repaired – I don’t know. But it’s not the right thing to do ….
PHP again
Mark Berryman gave me something to work with: looking whether it is memory that causes problems with PHP7. He explained there are several big differences between versions 5 and 7: 7 id fully 64-bit and checks memory boundaries, something PHP 5 (32 bit) doesn’t. So the idea is to switch memory checks off by defining
$ DEFINE/SUS USE_ZEND_ALLOC 0
and he supplied special builds of the WASD PHP engine – but didn’t tell what the changes imply: Logging?
Tried them this evening – but without result.
I also set the memory boundary in PHP.INI to 512M – four times from the original. But even that didn’t help.
So back to the version that does work…
(There may be an issue with the database: Connection is lost, at times.. Perhaps PHP 5.2-13 does have problems as well??)