Cookiecutter-django: Worker timeout using Docker with Gunicorn

[acquayefrank]

I didn't know where to ask this. But can docker conflict with gunicorn. I'm using cookiecutter-django on a project and I'm not using docker. When I move the app to my server gunicorn keeps giving a [CRITICAL] WORKER TIMEOUT . I've increased the worker timeout but still face the problem.
When I try using the debug option of gunicorn I get this:
Ignored premature client disconnection. No more data after: gunicorn
Upon Googling docker related issues came up

[jayfk]

The way docker is used in cookiecutter-django is completely separated from gunicorn. Docker uses gunicorn as a piece to deploy the application but only if you run this through docker with docker-compose.

[pydanny]

Please don't use SHOUTED words, even if a returned error message. Especially if it includes a word like 'CRITICAL'. I panicked and dropped everything at a bad time to look into this issue.

As for your googling for related issues, can you provide links to some of the references you found?

[acquayefrank]

@pydanny sorry for using shouted words. This is the error I get when I run gunicorn in debug mode:

Ignored premature client disconnection. No more data after: b'\x16\x03\x01\x01"\x01\x00\x01\x1e\x03\x03\x06\x9b\xfc\xf5\x07L\x95(\x99Z\x0fC6H\x8a;\xd7eanJ\xcb1\'\xd9\xf7\x0cQ\xeb\xc7\x01\x9f\x00\x00\x88\xc00\xc0,\xc0(\xc0$\xc0\x14\xc0\n\x00\xa3\x00\x9f\x00k\x00j\x009\x008\x00\x88\x00\x87\xc02\xc0.\xc0*\xc0&\xc0\x0f\xc0\x05\x00\x9d\x00=\x005\x00\x84\xc0\x12\xc0\x08\x00\x16\x00\x13\xc0\r\xc0\x03\x00\n\xc0/\xc0+\xc0\'\xc0#\xc0\x13\xc0\t\x00\xa2\x00\x9e\x00g\x00@\x003\x002\x00\x9a\x00\x99\x00E\x00D\xc01\xc0-\xc0)\xc0%\xc0\x0e\xc0\x04\x00\x9c\x00<\x00/\x00\x96\x00A\xc0\x11\xc0\x07\xc0\x0c\xc0\x02\x00\x05\x00\x04\x00\x15\x00\x12\x00\t\x00\xff\x01\x00\x00m\x00\x0b\x00\x04\x03\x00\x01\x02\x00\n\x004\x002\x00\x0e\x00\r\x00\x19\x00\x0b\x00\x0c\x00\x18\x00\t\x00\n\x00\x16\x00\x17\x00\x08\x00\x06\x00\x07\x00\x14\x00\x15\x00\x04\x00\x05\x00\x12\x00\x13\x00\x01\x00\x02\x00\x03\x00\x0f\x00\x10\x00\x11\x00#\x00\x00\x00\r\x00 \x00\x1e\x06\x01\x06\x02\x06\x03\x05\x01\x05\x02\x05\x03\x04\x01\x04\x02\x04\x03\x03\x01\x03\x02\x03\x03\x02\x01\x02\x02\x02\x03\x00\x0f\x00\x01\x01

So when I google "Ignored premature client disconnection. No more data after" ..

The first two links are:
https://github.com/docker/docker-registry/issues/132
https://github.com/docker/docker-registry/issues/177

[acquayefrank]

Hi @pydanny , I just resolved the issue. This was primarily due to negligence on my part ... I configured nginx wrongly.
Kindly close this issue and sorry for once again for using SHOUT words. @jayfk thanks for the help

[hasancansaral]

@acquayefrank I am getting the very same error, do you mind sharing what you did (wrong) and how you resolved the issue? Thanks.

[hasancansaral]

@pydanny I don't think the issue here has something to do with Nginx configuration. I am getting this error regardless how I configure Nginx, especially for timeouts.

This occurs when I re-deploy with a new version (docker-compose build django && docker-compose up -d) when my containers are already running. Then the only options becomes killing the docker-machine host, recreating one and redeploying to it, which resolves it.

However, it sometimes succeeds. We have both development and production environments which are exactly the same (amazonec2), and it can sometimes happen that one succeeds but the other doesn't. Any thoughts?

[egregors]

@pydanny Hi. I am getting absolutely the same issues.
@hasancansaral did you find the solve for this problem?

[hasancansaral]

Unfortunately, no.

I am using docker-machine to provision my host machine and restarting it with docker-machine restart helps. But that does mean downtime, it kills all the containers, and IMO shouldn't be necessary. Still trying to replicate, but for the moment it looks like it occurs randomly. @pydanny I believe this issue should be open. Thanks.

[ssteinerx]

@jayfk, @pydanny, see #802.

[jangeador]

One of my projects which has been running on production started doing this. I am clueless as the same settings are working perfectly on the staging server. I deleted all the containers, all the images and recreated them from the ground up. No luck. Is there a solution for this?

[pydanny]

@jayfk, do you think we could resolve these periodic nginx issues by switching to Caddy? I know you've had success with it on various projects.

[jayfk]

Absolutely. Caddy is awesome and should be enough for 95% of the projects started with Cookiecutter Django.

It wouldn't help with this particular error, though.

[jangeador]

Update: I could not find a solution. I had to reprovision the server and restore the data from backup. No changes to the code. Same version I was trying to run, ran flawlessly on the new server. Hopefully someone will be able to explain this stumper.

[pydanny]

@jangeador every once in a while a build or server just goes funny. It could be a hardware issue (the cloud runs on hardware), or a VM shutdown, or a library that didn't install quite right when the server was provisioned. Things that we can't see because of abstractions of deployment. That's part of why repeatable deployments exist, because sometimes glitches happen.

My personal philosophy is that if there's a configuration error that I can't solve in 30 minutes, my next step is to do what you did: rebuild from scratch on a new server. If it runs fine, it means a glitch occured. There's nothing I can do so I just move on.

Of course, if this kind of thing happens frequently it means it's time to dig in. Or, as I learned the hard way, switch to a hosting provider who had a better way of building or newly provisioned servers.

[hasancansaral]

Well, I am going to humbly disagree for that particular error ocurring due to a build gone bad. For about a few months my project was running just fine (I have had the [CRITICAL] WORKER TIMEOUT on startup after deployment a few times, but changing the vm or even docker-machine restart had helped at that time). But then it just happened. Same load, no updates, nothing changed. And I am talking about a solid 3 months without this error. So this made me think that it shouldn't have something to do with AWS or the deployment.

P.S. This is also how I came to terms with Docker, in addition to a few problems that are also discussed here that I encountered in some other projects (which have more frequent deployments than the one build on top of this). Everything seem to work just fine then.