My First Postmortem: Web-stack Debugging

On February 18, 2020 Holberton students were given our third debugging project, this project was for a web-stack. The website was returning a 500 status code for all GET requests. It was our task to identify the problem and create a Puppet script to rectify it. This is my postmortem for correcting this error.

Summary:

Apache returns a 500 error for all GET requests. It is a single HTML webpage, therefore an issue with the webpage’s MySQL or PHP would most likely be the cause of the error.

Timeline:

• 2/18/2020 @12:00 AM ET, Web-Stack Debugging #3 project is released.
• 2/18/2020 10:00 AM, Started project research, beginning with causes of 500 errors.
• 2/18/2020 1:00 PM, I realize that error logging for PHP is disabled, so I re-enable it.
• 2/18/2020 1:30 PM, I restart the server and encounter a “no such file” error.
• 2/18/2020 4:00 PM, A typo is found in the PHP file.
• 2/18/2020 4:30 PM, After manually fixing the typo, requests are now returning a 200 status code.
• 2/19/2020 10:00 AM, Begin writing Puppet script to correct error.
• 2/19/2020 3:00 PM, After testing and finalizing Puppet script, answer file is pushed to GitHub.

Bug Cause and Resolution:

The root cause of this bug was simple typo. When looking into /var/log file there were error logs for Apache and MySQL, however PHP error logs could not be found. Once they were enabled, and the server was restarted, the command curl localhost:80 was used to find the typo.

It stated an error on line 137 of /var/www/html/wp-settings.php file. That particular line was:require_once( ABSPATH . WPINC . ‘/class-wp-locale.phpp’ ); , ending in .phpp instead of .php. Most likely the result of simple human error, or possibly a cat walking across the keyboard of a developer as they edited this file.

After finding the typo, it was corrected, and the server was restarted and tested to ensure that there was nothing else causing the initial 500 error code. Once everything was verified as successful, a Puppet script was written, should this error need correcting across multiple servers.

Prevention

This error could, and should, have been prevented by the person that was initially editing or updating the config file. The server should have been tested after making changes to the file and before anything was implemented for the webpage. The errors for PHP should also not have been disabled on the server, and were they enabled the typo would have been found and corrected in testing prior to deployment. Lastly, if this typo was the result of a rogue feline taking a stroll across a developers desk, then stricter pet supervision should be implemented while text editors are open.