jmoiron.net

The past 2 days I've had a few perplexing technical problems that have had interesting answers. After a long weekend of drinking, eating, and lest I forget drinking, I got back to Cecilia's late last night and felt like doing a little digital maintenance on my computer, when I noticed that it was down. It's never down.

It's 00:15 on a Sunday, and it's snowing outside, so naturally the only thing to do is to go back to my apartment and figure out what the hell had happened. It turns out the police had raided my apartment due to some faulty Carbon Monoxide detectors, and during that raid cut the power. Unfortunately, I was a bit sloppy setting up my raid recently, and the old stuff was still in /etc/mdadm/mdadm.conf, so I had to find some way to rebuild it. A few naive attempts at trying to get mdadm to scan the superblocks on the disks that were involved in the array led down scary looking alleys of failure, but I finally stumbled upon a very useful combination:

sanji:~# mdadm --examine --brief --scan --config=partitions
ARRAY /dev/md1 level=raid5 num-devices=3 UUID=e0b67c52:2567a35d:f92c22ef:7f8cfb1d
ARRAY /dev/md0 level=raid0 num-devices=2 UUID=068ad357:dbfae400:fb5cee9b:1ff10449

So, essentially, this command scans the superblocks of your disks for "raid superblocks" and prints out mdadm.conf lines for whatever it finds. Thanks a lot, Hoboken P.D.

My second adventure had to do with the YUI autocompleter. At work we have a fair bit of scaffolding set up around this to be able to create autocompleters fairly easily. Today, I ripped through a 'reverse registration' system that peeked into all of our autocompleter-using widgets for resources and made a few local data sources that would asynchronously cache all autocompleter data off the server. This was actually pretty nice, and it allowed me to add a single deferred=true kwarg to various django form fields and widgets and have that actually work, with very little work happening in the views or templates.

Once I had my test page up, my autocompletion adventures being complete, I went off to try it on another page and hit an immediate road block. I fixed various small issues, but couldn't figure out why my autocompleter box still wasn't coming up. Made sure it wasn't a z-index problem, checked other common sources of error, but couldn't find anything. Stepped through damn near the entire process of creating the autocompleter but everything looked right; I could see via firebug the remote datasource was getting loaded, but that data didn't seem to make it to my autocompletion choices box.

Finally, I started looking all around for possible hooks into the "DataSource" (ajax/xml/json/javascript/csv/etc abstraction YUI uses) and realized that the page that wasn't working was leaving my json replies unparsed. After 20 minutes more of digging, I found that some old part of our header code was pulling in some YUI files twice, and one in particular json-min.js, which the docs claimed was necessary, was actually screwing up the process of parsing the reply. Removed those extraneous inclusions and everything worked. This was after 5 hours of frustration; I count myself very lucky that Roger got me to listen to some Bossa Nova because if I was listening to techno today I'd have broken something expensive.

Finally, I come home and again after a while all I want to do is get to the coding I didn't get to do last night. I log into my machine, set up my environment, fire up the dev server, hit my todo list, and boom:

Traceback (most recent call last):
      File "/var/lib/python-support/python2.5/django/core/servers/basehttp.py", line 278, in run
        self.result = application(self.environ, self.start_response)
      File "/var/lib/python-support/python2.5/django/core/servers/basehttp.py", line 635, in __call__
        return self.application(environ, start_response)
      File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py", line 239, in __call__
        response = self.get_response(request)
      File "/var/lib/python-support/python2.5/django/core/handlers/base.py", line 67, in get_response
        response = middleware_method(request)
      File "/var/lib/python-support/python2.5/django/middleware/cache.py", line 115, in process_request
        assert hasattr(request, 'user'), "The Django cache middleware with CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True requires authentication middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to insert 'django.contrib.auth.middleware.AuthenticationMiddleware' before the CacheMiddleware."
    AssertionError: The Django cache middleware with CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True requires authentication middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to insert 'django.contrib.auth.middleware.AuthenticationMiddleware' before the CacheMiddleware.

Of course, my AuthenticationMiddleware was indeed above the CacheMiddleware. Confused, I poked around in both middlewares. The CacheMiddleware does an object existence test on request.user to make sure that the AuthenticationMiddleware is loaded, and the AuthenticationMiddleware does a test in request.session to make sure that the SessionMiddleware it needs is loaded. My poking around led me to realize that although the Auth middleware was setting request.__class__.user, which should work, the hasattr test was failing. At this point, for my sanity, I attempted to print request.user from within the AuthenticationMiddleware. The user, which seemed to be lazily loaded from the session, was then forcefully loaded and the real cause of my problems revealed:

OperationalError: could not connect to server: No such file or directory

Forgot to start PostgreSQL. That's an odd manner of failure; considering that the entire session persistence layer was unavailable, I thought it'd have failed at that layer with an error message similar to that.