Well, that was fun. I just tried to log in to this site and found that I couldn’t get into the admin area. No useful error messages, of course, just web browsers claiming that the server didn’t want to send any data. Webserver error logs? No help at all.
So, back to the kind of WordPress troubleshooting that used to be needed all the time, but hasn’t been needed for so long that I had to think about it.
This kind of error is usually caused by a misbehaving plugin, and the traditional fix is to rename the plugins folder on the server so WordPress can’t see them any more, and so disables the lot. Renaming it back again let me start enabling them one at a time to see what was breaking things.
And it seems that the breakage was being caused by Akismet (spam blockage) and Jetpack (adds numerous features), both from WordPress rather than random developers. Now this normally happens if a plugin is updated, but neither has been updated for a few weeks.
But what has had an update or two is the web server. Looks like one of the recent updates is conflicting with these two plugins, which is a wee bit annoying…
So, for the time being, both are disabled until I can work out what’s going on.
OK, digging into the kind of Linuxy stuff I rarely need to investigate pointed out that any attempt to activate Akismet or Jetpack was causing segmentation faults, which are caused (or so my limited research tells me) by a process using more memory than it’s supposed to.
Digging further suggested that changing a value in php.ini would be the answer. So, I increased from 128M to 256M, restarted Apache and….
Now as to why it suddenly started doing that, I’d have to say errr, dunno. Not sure if something had reset php.ini to a default value (I have a vague recollection of setting this value higher some time in the past), or if both plugins had suddenly started to use more memory (which seems unlikely), or if it was just random oddness.
But anyway, normal service has resumed.