Blog Brownout – Now back to full power

Blog Brownout – Now back to full power

Lately, visitors to this site were greeted with Cloudflare’s colorful little screen (see right) and the HTTP 502 error – Bad Gateway. Is there a harder error to debug? Maybe, but this one is up there, that’s for sure.

It sent me into a minor panic as I didn’t have any site backups (plumbers pipes are always leaky!) and I could see a years worth of work quickly spiraling down the drain.

I ascertained that some of the site was still working, especially the post URLs themselves which led me to roll out the old wget and create a script that would download all my main posts to my local drive (just in case)

It wasn’t reassuring that I also couldn’t log in via one of the back-ends (rhc) using what I knew to be a good password. As I highlighted last year, when you sign up for cloud based offerings they have you by the balls.

I isolated the problem by killing my .htaccess file and confirming that I could access a static php file on the server. That was OK. So although PHP was somehow playing a part, it was difficult to track down the exact cause of the problem. I could access the WP dashboard but trying to navigate to many of the other WP (php based) screens,such as installed plugins, would trigger the 502 error.

Charles Proxy

I’d been meaning to look into Charles for some time, after reading about it in various blog posts. Without being too harsh, it didn’t help me on this occasion.

It wasn’t any picnic to get Charles going either. Had to upgrade my JRE to 8.0 and on Ubuntu there seem to be a few ways to do this. I settled on the following
sudo apt-get install openjdk-8-jre

You also need to add a Firefox add-in and tell Charles you are using it. See the info on their website.

Is it worth 50 bucks? Probably, but that can wait.

Redhat

The first decent clues came when I was able to log back into Redhat and use the rhc CLI. There are a ton of useful commands and when I issued
rhc app show <app_name> --gears quota

I saw that one of the gears was reporting an error status – and it was the gear containing PHP, so it all started to tie in together.

I removed cron from the offending cartridge and restarted the application. Low and behold the website came back up.

BTW, you could also SSH into the box and check your disk space using the following:

du -h * | sort -rh | head -50

Here’s what I got when I did just that:

Tidy your apps, lads

rhc app-tidy <name> is a handy little command that will clean up a lot of debris from your RHC installation. Here are the usage stats before I ran it:

GearCartridgesUsedLimit 
57xxxxxxxxxxxxxxxxxxxxxxhaproxy-1.4 php-5.4375 MB 1 GB
57xxxxxxxxxxxxxxxxxxxxxxmysql-5.5223 MB1 GB

~/Downloads/charles$ rhc app-tidy phproot

RESULT:
phproot cleaned up

After the cleanup, I had removed over 100MB from my PHP gear. Sweet!

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz