NOTE: This has been fixed. See comments for explanation. Thanks all!
Remember when I said my site upgrade from Ubuntu Lucid (10.04) to Precise (12.04) went flawlessly? Well, I'm not sure that's true. I've been trying to solve a funny little problem that I can't figure out, without success. I was just on the verge of descending into despair (I still might get a series of Mark vs. Computer comics out of it) when it occurred to me: my readers are, by and large, a lot smarter than I am. So follow me below the cut where I relate to you my tale of woe, in the hopes that one of you knows exactly what is going on...
Drupal 6 uses a plugin called CCK FileField to allow people to attach files to nodes.1 Since I converted over to Drupal, I've used FileField to load my webcomics into Drupal, and custom graphics into articles. Since the beginning of last year (January 2011) I've also used FileField to publish podcasts of the individual chapters I publish in the Fiction area.
Thursday night I attempted to publish a new podcast, and nothing happened.
Firefox doesn't give you a lot of information about what it's doing when it tries to upload a file, but Chromium (the Ubuntu version of Google's Chrome browser) actually reports a % status as the file is being uploaded. According to Chromium, it reached 1% and then the page crashed.
At first I thought it was just specific to the podcasts, but I've since come to learn that it depends on the size of the file--the crash is triggered by a file with a minimum size of somewhere between 125kb and 230kb (a 122kb file loads fine, a 230kb file hangs).
The last successful podcast was published on May 10th. Every file I've uploaded after that has been under 125kb, so I don't know specifically when this problem started. However, on May 12 I upgraded my server from Ubuntu Lucid (10.04) to Ubuntu Precise (12.04) in what I described, at the time, as an (Apparently) Flawless Upgrade.
Well that's it then! It must be a problem with the upgrade. Something changed, or something had to be changed that wasn't, that introduced this problem. Right? Well, wait. It's less obvious than that.
If you're having problems uploading a file using a php-based form, the most obvious culprit is usually sitting in one of your php.ini configuration files. PHP uses a number of settings that places limitations on how large the files can be and how many system resources can be reserved for handling the processing of files. The most obvious entries control the Maximum memory allocation, Maximum file upload size, and the Maximum HTTP POST size. Secondary culprits are entries that control how much time the system allows for input to be parsed, and how much time the system allows PHP to execute what's being brought in (Maximum input parsing time and Maximum execution time).
These usual suspects are all set well above the threshold needed to bring in the files. They are, in fact, the same values they were back when everything worked.
On top of that, if the problem had something to do with the server itself, it would be reasonable to expect the problem could be duplicated outside of Drupal, in other interfaces that use php-based forms to upload files. So I logged into phpmyadmin2, created a test database, and tried to import a 35mb sql file.
It worked flawlessly.
Meanwhile, on my test server--which also runs Lucid, is running the same version of Drupal, and uses a backup of the database that is as recent as this morning, can use filefield to upload files of any size without any difficulty whatsoever.
Based on this, I don't think the problem is Apache, or PHP, or mySQL. If it were, the problem should have occurred when I was importing a 35mb file in phpmyadmin, and probably would have occurred when I tried it on my dev machine.
Except there are a few differences between my dev server and my live server:
- My live server is running in a virtual environment set up by Prgmr.com, with a set and finite amount of resources. However, I can track those resources, and I'm not close to filling them up yet.
- My local server is running on localhost on my laptop, which means even though I'm using filefield to upload files in my tests, it's still grabbing files locally. There's very little if anything getting between the file and its destination.
- My live server is SSL enabled, so these uploads are occurring through https. My dev server isn't.
So there are a few other things I can think of that might be the problem:
- My ISP is capping the size of files going outward. I don't think this is the case, because I can sftp files of any size to my server, and I was able to add that 35mb sql file to mysql.
- Prgmr.com is capping the size of files coming in to my site. I don't think this is the case for the same reason -- I can sftp, and was able to import the 35mb database file.
- It's a file permissions issue. However, the directory that I upload the file to has exactly the same permissions as the directory where I upload the comics, and uploading a 122kb mp3 file (that's about five to seven seconds of audio, if you're curious) works just fine. It's the size of the file that triggers it, not the location.
So, as you can probably guess, I'm stumped. And until I'm un-stumped the podcasting portion of this site is going to stop, which probably doesn't affect the majority of my site visitors but it does affect those of you who listen to the podcasts.
I'm hoping that one of you out there will read this and understand exactly what's going on. For my part I have no freakin' clue. It appears to be filefield-specific, because it doesn't occur in phpmyadmin, but there isn't any reason for it that I can find.
Anyone? Anyone at all?