PHP updated
It required some work in startup procedures but now the blogs ru using Mark Berryman’s 5.2.13 version of PHP.
No trouble so far, except that the first start of the admin pages gave some error; but I could not reproduce it since the second time, it worked…Might have been a cache issue…
Next step: See if 5.3 and 5.4 do the job as well. And see whether WordPress 4.1 can now be installed.
17-Oct-2013
Thanks to my ISP ?
This may, or may not, be related to my router problems yesterday, that caused connections to drop without notice. Or in another way, since I have no longer the ability to block addresses of networks (since the firewall in that router misses this facility).
Normally, I start SoyMail at work and keep it open all day. It checks for new messages every 15 minutes. Runs silently (Windows sound machine muted 🙂 and no trouble at all). Except for today, where all of a sudden sync failed during retrieval of messages. Restarting fails with a 503 error: “This service is currently unavailable”. Trying some time later, nothing is wrong.
So I started the Admin site, and found System not responsive; however, other actions would work. I found a large number of accesses to this blog, many in idle state, but they could still be active. At some point, I could access the System report and indeed: there were quite a lot of WASD processes that run PHP_WASD, given the current working set. The only way, I could think of, was deleting them, but that didn’t help, so I fugured that is I would purge the idle processes, these would go.
They didn’t.
So the next thing was restartNow. It solved the problem a bit: I could now show the System report and found a large number of PDP_WASD images still around;bur Soymail could be reaccessed and haply refreshed the contents. For a few hours, when the very same happened again. I just restarted WASD, and found even more remaining PHP_WASD processes in LEF state, even LEFO. It solved the issue for an hour, but at that time, to no avail.
It seems all process slots were taken.
Back home, I tried to kill these processed, but even STOP/ID failed, except for one or two. But there were over 60 of them (my processcount is maximized to 110) and the only way to get rid of them easily was to reboot Diana.
That settled the issue, but question remains: how can this happen? I’ve done some investigation and details will be made public later – let the experts look at it first….
A quick look at the number of connections shows that some time today, I have had far more a second (or minute) than I have had ever before. There are some spikes at times but I blocked these networks in the Vigor router, so these would have no opportunity to access ANY service on the LAN. But I am now forced to use the Fritzbox supplied by my ISP. It offers a better IPV6 connectivity (something still not well working on the Vigor – at least not with my ISP) and a more robust telephone connectivity (the Vigor may drop connections – or that is related to the issues I have encountered) but it simply lacks a firewall that allows me to block traffic – and it lacks external logging via syslogd. But it’s the only one they support – officially…
Well, that food for some other rant 🙂
27-Feb-2013
More on WordPress
Mark has suggested another mapping:
map /wptest**/ /wptest*/index.php
exec+ /wptest/**.php* (cgi-bin:[000000]phpwasd.exe)/wptest/*.php* ods=5
and that works – for the basic action; though for completeness, I had to add
pass /wptest/000000/* /wptest/* ods=5 search=none dir=noaccess
pass /wptest/* /wptest/* ods=5 search=none dir=noaccess
to be sure images and stylesheets are loaded as well.
But first, I had to set things up so I could use the all-important WATCH facility: make sure I had to login, and could access the required files. The fast way was to copy the setup of Diana. Once that was done, I could find out what would happen now.
This new mapping does the trick – for a part. The normal user page comes up nicely, without a problem, and it is possible to login. But once the “login” button is hit, the process stops abruptly; WATCH output shows that there is insufficient core to extend “PATH” in the admin page (/wptest/wp-admin/indecx.php). This is weird, since the maximum amount of available memory for the PHP processor is 128M, set in PHP.INI….So it could be a matter of another process parameter: too little virtual memory. But pagefilequota is set to 500.000 for HTTP$NOBODY – the user under which the PHPWASD executable runs.
But when the URL of the admin page is next executed – and a new PHPWASD image is started – nothing is wrong: it simply comes on screen, a new post can be added, and followed by a few extra’s.
So it looks it works – until there is the io-error again – caused, in examination, by the same problem: there are 512 channels open…
Some further examination revealed that, if you wait long enough, the open cahnnels are closed at some point, but if you enter the next command too quick, the PHP engine gets to work without closing open channels….
What could be caused by parameter max-execution-time in PHP.INI: this has been extended from 30 to 120 seconds, otherwise the user page would not show because of exhaustion of execution time, as I found out when testing with SWS.
This has been added in the correspondence in the WASD mailing list; the raw data is available in a Windows .zip file on request by mailing list subscribers: these files may be rejected when sent as an attachement, for instance when received on a gmail account….
There is something more that’s wrong, but that is within the application: Some references in the tinymce environment are plain wrong and so some javascript files cannot be located and so some buttons don’t work. But since the link is set within WordPress, it seems more of a WordPress issue than PHP….(though these may be related!) Perhaps this is one of the things that is repaired in 3.5.1?
25-Feb-2013
New router installed
This weekend there was an opportunity to install the Vigor router in stead of the Fritzbox; since IPTV was now working on the Fritzbox, I was able to prepare a number of installations to handle IPTV on the Vigor. This traffic is in a separate, tagged VLAN, and the easy solution is bridging it to a LAN port, and since it is another network, into a separate LAN. That solution tunred out to work, for a running configuration, but how that will work if the TV-receiver needs to restart remains to be seen; the configuration is probably not the best.
IPv6 doesn’t initialize either, but since the prefix is known and fixed, it can be defined as a static address; however, I followed the Draytek advice and it makes no dfference….
So the Fritzbox remains available, in case I need to re-initialize the receivers….
Another issue with installation is that the Netgear GB-switch I had in mind – split VLANs – does not work properly. It seems to work, but after some time, connections are lost. So I re-installed the old 100Mb box in stead – it simply works…..
WordPress issues – continued
Did some deeper investigation on the problems; I created an audit log for both SWS and WASD and found a difference in handling. Posted the outcome to the WASD mailing list, after which Mark installed Wrodpress and MySQL to investigate; however, he used a different mapping than he proposed, and that one seems to work, except for ACCVIO’s. But he didn’t get the redirections that I found – which were, in retrospect, not really unexpectible; for some reason, a 301-status triggered a full reparse of the code – up the four times until the last one runs into resource exhaustion…
There is something going on in the WordPress code that triggers a 301-status to be returned – and false! – when the command to the server is a REDIRECT – as is shown in the WATCH output that Mark included.
The next step in this investigation is changing the mapping – and find out what causes ACCVIO, which is a completely different matter.
30-Aug-2012
Weird PHP issue
All of a sudden, any blog that has run fine for years, run into an error:
Warning: require(/sysblog/000000/wp-includes/class.wp-dependencies.php) [function.require]:
failed to open stream: no such file or directory in /sysblog/wp-includes/script-loader.php on
line 3
Fatal error: require() [function.require]: Failed opening required
'/sysblog/000000/wp-includes/class.wp-dependencies.php' (include_path='.:/php_root/000000') in
/sysblog/wp-includes/script-loader.php on line 3
This happened also on the Trips,Tracks and Travels blog, and that runs WP 263 (where thos blog uses WP 265).
If I would have changed something, it could be the result of that change. But I didn’t….
So I tried a different approach, since it might be a web-issue, and ran the blog immediately under PHP:
$ php :== $php_root:[bin]php
$ set def sysblog:[000000]
$ php index.php
and that gave exactly the same outcome.
Also checked the (no longer published but still present) Boorcamp blogs: same result.
What the heck was going on here?
Looking back – on line – when this could have started, I found the earliest:
...[30/Aug/2012:06:25:59 +0000] "GET /sysblog/index.php?p=333 HTTP/1.1" 200 767
and to look even further back, I have to cycle the access log….
So I mailed the WASD mailing list on the issue, and tried again to find out some more information, and accessed the Trips,Tracks and Tavels blog again.
BEHOLD: NO PROBLEM….
I again accessed the sysmgr blog (this one), and here as well, it all worked again like before. That is also shown in the access log:
...[30/Aug/2012:08:41:06 +0000] "GET /sysblog/index.php HTTP/1.1" 200 37951
Mind the last numer: the size of the reply…
Who knows the answer, please inform me…
It must be someting in the system – but what could it be?
(There is something not entirely right: because the admin pages seem to require a re-load. Even on posting. But that can be worked around)