I noticed over the last few days that the view counts have dropped away dramatically. Also a potential new blog member tried to click on a blog link and received a “Page not found” error message.
With this in mind I thought I’d create a quick poll to see who can still access my blog posts, which will, hopefully, help me to work out why “visitors” are not visiting.
Note that comments are only possible for logged-in blog members!
Thank you in advance if you can access this blog post!…………Phil
VIEWS News will now be resuming production, because 100 blog members have requested free access to the VIEWS UK forum!
Issue 56 will now be made available to download from the VIEWS UK forum in May 2019, but, in the meanwhile, I’ll be developing indexes in that forum for the existing 55 back-issues of VIEWS News. New issues will, hopefully, be published in February, May, August and November each year, so, if you have a suitable SAS-related article you’d like to have included, please contact me at email@example.com.
Remember that free access to the VIEWS newsletter is restricted to logged-in blog members who have requested access to the VIEWS UK forum. This is so I have a list of interested members willing to received news about forthcoming VIEWS News issues. Any blog members who don’t wish to learn about new VIEWS News issues should not request free access, but any registered blog members who do want access to the VIEWS UK forum should contact me now, if they are not already on the list. Just log into the blog and look for “VIEWS UK” in the forum list to make certain.
The morale of this story is that, once you have proved all the likely reasons for the failure are incorrect, the only remaining reason, however improbable, is the cause!
Note that, as you are reading this post, the problem described below has definitely been resolved!
Over the last few weeks I have been trying to configure my new Linux server to include RAID1 (mirrored) drives, but, while it should only have caused brief service outages for reboots, some of the down times have been rather too long. I have now decided to implement regular copies of the drives instead.
The most recent outage was somewhat baffling, as my attempt to include the RAID1 drives had failed again, but I’d followed my well-practised back out procedure. Unfortunately the server hardware appeared to be up and running, I could access both servers on the device using local IP addresses, but only one, the Apache server and not the WordPress server, using the hollandnumerics.org.uk web address.
A systematic approach to resolving the problem would be needed:
- Check the server monitors to make sure the software was running:
- Both servers were running.
- The problem was not a failure to start the server software on reboot.
- Open the web pages for each server using their local IP addresses:
- The web pages for both servers opened.
- Both servers were up and accepting connections.
- Open the web pages for each server using their web addresses:
- The Apache server pages opened, but the WordPress server pages timed out.
- Maybe a problem with the WordPress port?
- Check the WordPress server access log for my attempts to open web pages:
- Only local addresses were recorded as connecting to WordPress.
- Maybe a problem with the WordPress port in the router?
- Check the event log on the router:
- All connections to the WordPress port are being blocked.
- Maybe a fault in the Port Forwarding configuration in the router?
- Check the Port Forwarding configuration in the router:
- All expected entries present.
- Maybe a fault has developed in the supplied entry used with the WordPress port?
- Replace the supplied WordPress entry with a user-modified copy of the working Apache entry, and then open web pages for the WordPress server using their web addresses:
- The web pages for the WordPress server opened successfully.
The key actions used to resolve this problem have much in common with those actions listed in my post “How Do You Successfully Debug Your Program?“:
- Work through the problem testing systematically:
- Make changes one at a time to be certain you know which one fixes the problem, and also allows you to back out the update if it doesn’t.
- Test after each change.
- Review the results from every test.
- Consider the likely and the unlikely causes of the problem.
- Most importantly: Read the logs!