Repository: benoitc/gunicorn

Issue:
Sockets
Service is running on a kubernetes pod, and out of nowhere and without any specific causes, it happens off and on:
```
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
[2018-11-04 17:57:55 +0330] [31] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
```


Discussion:
Is the anything interesting upstream of gunicorn in your pod, like a reverse-proxy, nginx?
No, no proxies, no nginx
I'm having the exact same problem :confused:

Upstream we have HAProxy and on its HTTP log format, the session state at disconnection (see http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#8.5) it logs those errors as ``CH--`` meaning:

- C : the TCP session was unexpectedly aborted by the client.
- H : the proxy was waiting for complete, valid response HEADERS from the server (HTTP only).

So, if I understand that correctly, the client closed the connection while gunicorn was still sending the response.
Any clues what makes the client abort? Was it waiting a long time for gunicorn to send complete response headers?
@javabrett it does not seem like that, at least on the few log messages I looked up, it is mostly images or other assets, so it should not be taking much time.

The client might have closed the browser or any other action that would abruptly close the connection? :thinking: 
@gforcada are you using the proxy protocol with haproxy? 
@benoitc not that I'm aware of
anyone get anywhere with this? I don't have much to contribute except the exact same error.

My configuration consists of a loadbalancer that's being used to terminate SSL and forward requests to a django app running in a docker container. I'm not sure what the LB is implemented with - its a Digital Ocean product.

I'm fairly certain it related to the load balancer because I have the same app running in another container that isn't behind an LB and its never had this problem.

Any ideas on the root cause and how to prevent?
I wonder if there's any action here. If this is a regular client disconnect, we could maybe silence the error and maybe log a disconnect in the access log, but otherwise I'm not sure what to do.
I just had the same error which crashed our monitoring webserver:

```
[2019-06-10 11:38:25 +0200] [27989] [CRITICAL] WORKER TIMEOUT (pid:17906)
[2019-06-10 11:38:25 +0200] [17906] [INFO] Worker exiting (pid: 17906)
[2019-06-10 11:38:25 +0200] [17924] [INFO] Booting worker with pid: 17924
[2019-06-10 11:38:37 +0200] [17922] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/home/off1user/.pyenv/versions/3.6.1/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
[2019-06-10 11:38:47 +0200] [27989] [CRITICAL] WORKER TIMEOUT (pid:17920)
[2019-06-10 11:38:47 +0200] [17920] [INFO] Worker exiting (pid: 17920)
```
I had the same with pod running docker image dpage/pgadmin4:4.2

OSError: [Errno 107] Socket not connected
[2019-06-14 12:20:32 +0000] [77] [ERROR] Socket error processing request.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/gthread.py", line 274, in handle
    req = six.next(conn.parser)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/usr/local/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
Looks very similar to: https://github.com/benoitc/gunicorn/issues/2070
I'm getting this error occasionally on hosted Google Cloud Run. Below is a simplified version of our container definition:

```
FROM ubuntu:18.04

ENV APP_HOME /app
WORKDIR $APP_HOME

RUN apt-get update \
  && apt-get install --no-install-recommends -y python3 python3-pip \
  && rm -rf /var/lib/apt/lists/*

RUN pip3 install --compile --no-cache-dir --upgrade pip setuptools

RUN mkdir invoice_processing && \
    pip install --compile --disable-pip-version-check --no-cache-dir flask gunicorn

COPY app.py ./
CMD exec gunicorn --bind :$PORT --workers 1 --threads 1 app:app
```

Stackdriver shows the following stacktrace:

```
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/base.py", line 134, in init_process
    self.run()
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 124, in run
    self.run_for_one(timeout)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 68, in run_for_one
    self.accept(listener)
  File "/usr/local/lib/python3.6/dist-packages/gunicorn/workers/sync.py", line 27, in accept
    client, addr = listener.accept()
  File "/usr/lib/python3.6/socket.py", line 205, in accept
    fd, addr = self._accept()
OSError: [Errno 107] Transport endpoint is not connected
```
Same issue as OP here. Using Google Cloud Platform, Python 3.7, gunicorn 19.9.0

```
Traceback (most recent call last):
  File "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 134, in handle
    req = six.next(parser)
  File "/env/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected
 timestamp:  "2019-07-30T15:23:55.435130Z"
```  
I'm having the exact same problem 😕
Exact same problem as GAEfan. Running a Flask app with Python 3.7 in App Engine Standard Env. 
Same issue here
I'm having the same issue running Django app with Python 3.7 in Google App Engine.

Traceback (most recent call last): File "/env/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 134, in handle req = six.next(parser) File "/env/lib/python3.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 181, in __init__ super(Request, self).__init__(cfg, unreader) File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 54, in __init__ unused = self.parse(self.unreader) File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 230, in parse self.headers = self.parse_headers(data[:idx]) File "/env/lib/python3.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers remote_addr = self.unreader.sock.getpeername() OSError: [Errno 107] Transport endpoint is not connected
Same issue running GAE python 3.7 gunicorn and fastapi/uvicorn.
Same issue Google Cloud Run
which kind of request are we talking about? 
same issue in google app engine. POST request. happens inconsistently. Flask app. @benoitc please let me know what info would be useful and i can post.
Same issue as well, Google App Engine, POST request too, Flask app. It seemed to have started when I changed to a custom entrypoint code instead of letting the default one. Custom entrypoint is the following (in Google App Engine you set it inside an app.yaml file):

`gunicorn -b :$PORT --timeout 1200 server.main:app`

Default entrypoint is not setting anything (don't know what is used as default entrypoint though).

Not sure if it started because of that, but I noticed this when I made this change (among other changes).
> 
> 
> No, no proxies, no nginx

I was using `gunicorn` without `nginx`. I was getting the same issue. My setup is running on `Openshift`.
`gunicorn --chdir /src/app wsgi:application  --bind 0.0.0.0:8000 --workers 4 --timeout 180 -k gevent`

> https://stackoverflow.com/questions/58389201/gunicorn-is-failing-with-oserror-errno-107-transport-endpoint-is-not-connecte
the question stand

> Same issue as well, Google App Engine, POST request too, Flask app. It seemed to have started when I changed to a custom entrypoint code instead of letting the default one. Custom entrypoint is the following (in Google App Engine you set it inside an app.yaml file):
> 
> `gunicorn -b :$PORT --timeout 1200 server.main:app`
> 
> Default entrypoint is not setting anything (don't know what is used as default entrypoint though).
> 
> Not sure if it started because of that, but I noticed this when I made this change (among other changes).

what do you mean by entry point? can you post a debug log and the way the request is done? (raw http would help)

> the question stand
> 
> > Same issue as well, Google App Engine, POST request too, Flask app. It seemed to have started when I changed to a custom entrypoint code instead of letting the default one. Custom entrypoint is the following (in Google App Engine you set it inside an app.yaml file):
> > `gunicorn -b :$PORT --timeout 1200 server.main:app`
> > Default entrypoint is not setting anything (don't know what is used as default entrypoint though).
> > Not sure if it started because of that, but I noticed this when I made this change (among other changes).
> 
> what do you mean by entry point? can you post a debug log and the way the request is done? (raw http would help)

I think he's referring to the fact that you're explicitly specifying the `app` path the _gunicorn_ should import-find and run, like the `server.main:app` in his example.

L.E.: Maybe the updated example over here helps: https://github.com/GoogleCloudPlatform/python-docs-samples/tree/master/appengine/standard_python37/hello_world (so basically you have to let the service handle how the server should be started)
Firstly, @benoitc THANK YOU. Your work is awesome.

I'm also experiencing this same issue on Google Cloud Run w/gunicorn. I'm posting what I have, though it's likely not unique, perusing the above. I'm running a Flask app with Gunicorn as the server (and no proxy) in a Docker container.

The traceback (from GC console):
```bash
  File "/usr/local/lib/python3.7/site-packages/gunicorn/arbiter.py", line 583, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 104, in init_process
    super(ThreadWorker, self).init_process()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/base.py", line 134, in init_process
    self.run()
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 211, in run
    callback(key.fileobj)
  File "/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py", line 127, in accept
    sock, client = listener.accept()
  File "/usr/local/lib/python3.7/socket.py", line 212, in accept
    fd, addr = self._accept()
OSError: [Errno 107] Transport endpoint is not connected
```

And Google's parsed output of the above:

```
OSError: [Errno 107] Transport endpoint is not connected
at accept (/usr/local/lib/python3.7/socket.py:212)
at accept (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:127)
at run (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:211)
at init_process (/usr/local/lib/python3.7/site-packages/gunicorn/workers/base.py:134)
at init_process (/usr/local/lib/python3.7/site-packages/gunicorn/workers/gthread.py:104)
at spawn_worker (/usr/local/lib/python3.7/site-packages/gunicorn/arbiter.py:583)
```

If there is anything else I can provide or do to help here, please let me know.
A PR would be welcome to handle `ENOTCONN` gracefully for all the workers. Please post here if you start working on this and I would be happy to review a PR. I'm sure some on this thread would be happy to help test a branch.
Same issue, Google App Engine, gunicorn serving a Django app, a small percentage of requests die like this:

![image](https://user-images.githubusercontent.com/38537396/67796820-aee2c100-fa4e-11e9-92c6-ae7d07364acd.png)


```
entrypoint: gunicorn -b :$PORT wsgi_api:application
```
> A PR would be welcome to handle `ENOTCONN` gracefully for all the workers. Please post here if you start working on this and I would be happy to review a PR. I'm sure some on this thread would be happy to help test a branch.

I am one of those on this thread happy to help test, so please ping me if I can assist. 
> 
> 
> > A PR would be welcome to handle `ENOTCONN` gracefully for all the workers. Please post here if you start working on this and I would be happy to review a PR. I'm sure some on this thread would be happy to help test a branch.
> 
> I am one of those on this thread happy to help test, so please ping me if I can assist.

I'm happy to help testing the PR. If need any assistance please ping me.
I'm happy to help testing the PR. If need any assistance please ping me.

> A PR would be welcome to handle `ENOTCONN` gracefully for all the workers. Please post here if you start working on this and I would be happy to review a PR. I'm sure some on this thread would be happy to help test a branch.

The root cause of this issue with latest version of `gunicorn==19.9.0`. I was shifted to use the older-version of `gunicorn==19.7.1`. I was able to run without any issue. Please try with the older version.
rather try the last master. 20.0 will finally come today i have been side tracked. 

How your health check endpoint looks? How do you respond to it, are you closing the connection? do you set length header and co? i'm not sure why a health check is done via post. sounds weird...
@cmin764 does fflask set some default header? i will try but it would be interresting to ser ho the response looks
@benoitc When I was using the `gunicorn==19.9.0` endpoint health check is really bad. Database connections are waiting for the longer time. Entire loading the application is goes down.

older `gunicorn==19.7.1` Endpoint are breaking Endpoint health check is looks good. I was not closing any connections and not set length of headers. 

I will also test the latest version 20.0.

> 
> 
> > No, no proxies, no nginx
> 
> I was using `gunicorn` without `nginx`. I was getting the same issue. My setup is running on `Openshift`.
> `gunicorn --chdir /src/app wsgi:application --bind 0.0.0.0:8000 --workers 4 --timeout 180 -k gevent`
> 
> > https://stackoverflow.com/questions/58389201/gunicorn-is-failing-with-oserror-errno-107-transport-endpoint-is-not-connecte

with older version gunicorn=19.7.1` I was not able to run with the `gevent`. I have changed my gunicorn command 

`gunicorn apps.wsgi:application --bind 0.0.0.0:8000 --workers 4 --timeout 180`
i am looking at the changes since this version to see if there is any reason for it. thanks for the feedback!
Using 19.7.1 (downgrade from most recent) worked in google app engine environment with push queues feeding workers, and workers talking to each other over http.
> Using 19.7.1 (downgrade from most recent) worked in google app engine environment with push queues feeding workers, and workers talking to each other over http.

This is my use case. I’ll be giving this a shot. 
did you try the latest version?
Tried latest 20.0.0 on Openshift (openshift v3.11.135, kubernetes v1.11.0) - same error occurs. What I observed error is trigered on higher load (integration tests running 20 parralel workers). Raising number of pods reduces occurence of error, leaving single pod results in guaranteed error. It's 3 sync workers config. **19.7.1 just shows no error on pod logs**, but external consumer experiences same unexpected EOF on connection like with newest version. So degrading version does not help.

2019-11-12 16:08:56,982 ERROR gunicorn.error glogging 277 glogging.py Socket error processing request. 
Traceback (most recent call last):
      File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", line 
      134, in handle
    req = six.next(parser)
  File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in __next__
    self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
  File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in __init__
    super(Request, self).__init__(cfg, unreader)
  File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in __init__
    unused = self.parse(self.unreader)
  File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
    self.headers = self.parse_headers(data[:idx])
  File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
    remote_addr = self.unreader.sock.getpeername()
OSError: [Errno 107] Transport endpoint is not connected

> 
> 
> Tried latest 20.0.0 on Openshift (openshift v3.11.135, kubernetes v1.11.0) - same error occurs. What I observed error is trigered on higher load (integration tests running 20 parralel workers). Raising number of pods reduces occurence of error, leaving single pod results in guaranteed error. It's 3 sync workers config. **19.7.1 just shows no error on pod logs**, but external consumer experiences same unexpected EOF on connection like with newest version. So degrading version does not help.
> 
> 2019-11-12 16:08:56,982 ERROR gunicorn.error glogging 277 glogging.py Socket error processing request.
> Traceback (most recent call last):
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/workers/sync.py", line
> 134, in handle
> req = six.next(parser)
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/parser.py", line 41, in **next**
> self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count)
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 181, in **init**
> super(Request, self).**init**(cfg, unreader)
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 54, in **init**
> unused = self.parse(self.unreader)
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 230, in parse
> self.headers = self.parse_headers(data[:idx])
> File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/gunicorn/http/message.py", line 74, in parse_headers
> remote_addr = self.unreader.sock.getpeername()
> OSError: [Errno 107] Transport endpoint is not connected

Can you try increase the [router timeout.](https://github.com/BCDevOps/openshift-wiki/wiki/Route-Timeouts--504-error-for-longer-running-http-requests)
> Can you try increase the [router timeout.](https://github.com/BCDevOps/openshift-wiki/wiki/Route-Timeouts--504-error-for-longer-running-http-requests)

**Folowing this lead we found issue**: Openshift readiness probe setup was too optimistic (app took too long for some requests), and on failure external loadbalancer (AVI) picked up this event and kicked pod out of loadbalancing pool. 
I recently experienced this issue with gunicorn=19.9.0. A restart resolved the issue. I am deployed on Google Kubernetes Engine. The application is a flask app - 
entry:
`command: ["sh", "-c", "gunicorn -b 0.0.0.0:$${PORT} -c gunicorn_config.py run:app"]`
config: 
```
worker_temp_dir = '/dev/shm'
worker_class = 'gthread'
worker = 2
threads = 2
worker_connections = 1000
timeout = 180
keepalive = 2
backlog = 2048
accesslog = '-'
errorlog = '-'
```
Error: 
```Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 274, in handle req = six.next(conn.parser) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/parser.py", line 41, in __next__ self.mesg = self.mesg_class(self.cfg, self.unreader, self.req_count) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 181, in __init__ super(Request, self).__init__(cfg, unreader) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 54, in __init__ unused = self.parse(self.unreader) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 230, in parse self.headers = self.parse_headers(data[:idx]) File "/usr/local/lib/python2.7/site-packages/gunicorn/http/message.py", line 74, in parse_headers remote_addr = self.unreader.sock.getpeername() File "/usr/local/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) error: [Errno 107] Transport endpoint is not connected```
Is the current solution to downgrade to `19.7.1`?
Can anyone share a repository with deployment instructions that I can use to reproduce the issue? I'm happy to look into it, but I want to make sure I know exactly how to set it up.
Hi @tilgovi Fastapi uses gunicorn at production. 
[This repository](https://github.com/euri10/fastapi_appengine_minimal) has a minimal version and showed same error. You can try, I have been this error at App Engine I don't know if it replicates with another environments. That repository, could it help to reproduce the issue?
Same issue here:
gunicorn 19.9.0 + GKE also occurred when we were dealing with high load.
> cmin

Not sure, but everything seems back to normal now.

This is my app.yaml
```yaml
runtime: python37
entrypoint: gunicorn -b :$PORT truestory:app


handlers:
- url: /static
  static_dir: truestory/static

- url: /favicon\.ico
  static_files: truestory/static/img/favicon.ico
  upload: truestory/static/img/favicon\.ico

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto
```

And production run of Makefile:
```Makefile
run: export FLASK_CONFIG = production
run:
	# Run main server in production mode with Gunicorn (remote database).
	@echo "[i] Starting server with Gunicorn."
	gunicorn -b :$(PORT) truestory:app
```

So maybe it was something temporary on GAE.

Resolving patch:
diff --git a/gunicorn/workers/base_async.py b/gunicorn/workers/base_async.py
--- a/gunicorn/workers/base_async.py
+++ b/gunicorn/workers/base_async.py
@@ -73,11 +73,13 @@ def handle(self, listener, client, addr):
                 self.log.debug("Error processing SSL request.")
                 self.handle_error(req, client, addr, e)
         except EnvironmentError as e:
-            if e.errno not in (errno.EPIPE, errno.ECONNRESET):
+            if e.errno not in (errno.EPIPE, errno.ECONNRESET, errno.ENOTCONN):
                 self.log.exception("Socket error processing request.")
             else:
                 if e.errno == errno.ECONNRESET:
                     self.log.debug("Ignoring connection reset")
+                elif e.errno == errno.ENOTCONN:
+                    self.log.debug("Ignoring socket not connected")
                 else:
                     self.log.debug("Ignoring EPIPE")
         except Exception as e:
diff --git a/gunicorn/workers/gthread.py b/gunicorn/workers/gthread.py
--- a/gunicorn/workers/gthread.py
+++ b/gunicorn/workers/gthread.py
@@ -285,11 +285,13 @@ def handle(self, conn):
                 self.handle_error(req, conn.sock, conn.client, e)
 
         except EnvironmentError as e:
-            if e.errno not in (errno.EPIPE, errno.ECONNRESET):
+            if e.errno not in (errno.EPIPE, errno.ECONNRESET, errno.ENOTCONN):
                 self.log.exception("Socket error processing request.")
             else:
                 if e.errno == errno.ECONNRESET:
                     self.log.debug("Ignoring connection reset")
+                elif e.errno == errno.ENOTCONN:
+                    self.log.debug("Ignoring socket not connected")
                 else:
                     self.log.debug("Ignoring connection epipe")
         except Exception as e:
diff --git a/gunicorn/workers/sync.py b/gunicorn/workers/sync.py
--- a/gunicorn/workers/sync.py
+++ b/gunicorn/workers/sync.py
@@ -146,11 +146,13 @@ def handle(self, listener, client, addr):
                 self.log.debug("Error processing SSL request.")
                 self.handle_error(req, client, addr, e)
         except EnvironmentError as e:
-            if e.errno not in (errno.EPIPE, errno.ECONNRESET):
+            if e.errno not in (errno.EPIPE, errno.ECONNRESET, errno.ENOTCONN):
                 self.log.exception("Socket error processing request.")
             else:
                 if e.errno == errno.ECONNRESET:
                     self.log.debug("Ignoring connection reset")
+                elif e.errno == errno.ENOTCONN:
+                    self.log.debug("Ignoring socket not connected")
                 else:
                     self.log.debug("Ignoring EPIPE")
         except Exception as e:


Test patch: