search

sc3 / cookcountyjail

A Django app that tracks the population of Cook County Jail over time and summarizes trends.
http://cookcountyjail.recoveredfactory.net/api/1.0/?format=json
Other
31 stars 23 forks source link

v1 API no longer responded to requests #359

Closed nwinklareth closed 10 years ago

nwinklareth commented 10 years ago

On 2014/05/04 it was discovered that trying to access the v1 API with the following URLs did not work:

bepetersn commented 10 years ago

Still not working? It does for me, anyway. On May 5, 2014 12:20 PM, "nwinklareth" notifications@github.com wrote:

On 2014/05/04 it was discovered that trying to access the v1 API with the following URLs did not work:

— Reply to this email directly or view it on GitHubhttps://github.com/sc3/cookcountyjail/issues/359 .

wilbertom commented 10 years ago

We should look at the server logs to see how long it was out.

nwinklareth commented 10 years ago

The logs won't tell us. I created this issue to track that we had this problem, which Brian had fixed and he thought that the problem still existed which it did not.

On Wed, May 7, 2014 at 8:34 AM, Wilberto Morales notifications@github.comwrote:

We should look at the server logs to see how long it was out.

— Reply to this email directly or view it on GitHubhttps://github.com/sc3/cookcountyjail/issues/359#issuecomment-42427027 .

Regards

Norbert

Norbert Winklareth

bepetersn commented 10 years ago

Ah, sorry for forgetting.

The issue came up during my changing the locations of some important django files, in particular wsgi.py. The problem arose after these changes were pushed to the server, using our fabric production master deploy command. At the end of this command, the production gunicorn server is restarted.

In essence, the gunicorn.sh file failed to locate wsgi.py, which is actually what runs the django app. But unlike you might expect, the gunicorn service still ran, and not only that, it said nothing about its failure to find a wsgi application. It still logged all the requests made to it (but not their results), and simply didn't pass any of them along to the django application.

Anyway, I figured out what was happening after staring at the live gunicorn process on the server for awhile -- in the gunicorn.sh file, we used to pass in a module level reference, cookcountyjail.wsgi:application, by argument. Changing this to countyapi.wsgi:application solved the issue.