Non-SAS Debugging That Uses My Preferred SAS Debugging Techniques

Total views 2,611 

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 web address.

A systematic approach to resolving the problem would be needed:

  1. 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.
  2. 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.
  3. 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?
  4. 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?
  5. 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?
  6. 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?
  7. 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.
      • Problem resolved!

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!