Tuesday, April 20, 2010

Debugging

My friend Will is living with me for awhile, and doing some volunteer work. One of his projects is to create a website that provides information on members of the organization he's helping out.

The organization has a hosting company that provides a web server, a MySQL database, and the option of installing certain additional software, like WordPress. But it only lets Will have FTP access, so he's been doing the main coding on his home Linux system, and then FTPing his development files onto the main server.

Yesterday he ran into a problem - one of his PHP files was supposed to generate a PDF file listing all the people in the database. On his local system, the PHP file would load and run, and out would pop the PDF file just as expected. On the remote server, the page would produce a 500 error - internal server error, and do nothing.

We stayed up till 1:00 AM debugging it. At first I wanted to eliminate the possibility that it was the PDF data itself causing the problem, so we edited the file to produce a blank PDF page. Still got the error. Then we edited the file so it wouldn't even produce PDF data, but would just load up the various libraries it relied on, and then just make an empty HTML file. Still gave the same error.

If we were seeing a 500 error on a blank HTML file, the problem couldn't be in the file itself. We checked the file permissions, and found they were the same as the PHP files provided by WordPress itself for administrative features of the web site. We also copied the problem file into the same directory as those WordPress PHP files. When we viewed our file, we still got the error. Viewing the WordPress PHP files, we got no error.

So that eliminated any file permission issue or directory permission issue, right? The file that had the error had the same permissions, and was in the same directory, as files that didn't have the error. The only possible answer was that somehow the PHP needed to generate appropriate HTTP headers or HTML code.

So we tried copying the HTML code from one of the working files into the problem file. Still the same error. We were about to try directly copying one of the working files to have the name of the problem file, so that the problem file would be completely eradicated and replaced by an identical copy of a working file, but we were too tired and had to go to sleep.

Then Will emails me this morning. Problem solved! If we had done that final test last night, we would have seen that the identical copy would still have produced the same error. The exact same file, but just with a different filename.

Apparently Will had done that test when he woke up, and, having come to the end of any possible investigative avenue, just stared at the directory listing for awhile, until he figured it had to be a permissions problem after all. The problem file had the permissions set as -rw-rw-r--. This was the same as the WordPress files, but apparently WordPress is fine with its own files having those permissions, it just doesn't want anyone else's files to have those permissions. Once Will set the file permissions to -rw-r--r--, the problem went away.

I'm still not clear on how he made that leap, but it's so frustrating, because checking the permissions was one of the first things we did, and we naturally compared them to the WordPress files since we assumed the WordPress PHP files (which were actively used as part of the running application) would have the correct permissions for us to use. So the whole time last night, we kept saying, "OK, what could account for this? We know it's not a permissions problem, so...."

Bah. This is why I never tried to be a professional coder or sysadmin. Yes, I have skills, but if something like this can totally hang me up, then that's kind of a real problem.

No comments:

Post a Comment