Werkzeug: Werkzeug는 닫힌 파이프에 쓴 후 충돌합니다.

Werkzeug 개발 서버가 아닌 Gunicorn 또는 uWSGI와 같은 프로덕션 WSGI 서버를 사용합니다.

나는 Werkzeug dev 서버를 개발(즉, AFAICT, 의도된 용도), 즉 포트 5000에 직접 연결된 브라우저를 사용하고 있다는 점을 제외하고는 매우 유사한 문제가 있습니다.

오류는 시간당 여러 번 발생하여 계속 개발하려면 서버를 수동으로 다시 시작해야 합니다.

다음은 역추적입니다.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 659, in inner
    srv.serve_forever()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 499, in serve_forever
    HTTPServer.serve_forever(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 238, in serve_forever
    self._handle_request_noblock()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 297, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__
    self.handle()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 216, in handle
    rv = BaseHTTPRequestHandler.handle(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 251, in handle_one_request
    return self.run_wsgi()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi
    execute(self.server.app)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 186, in execute
    write(b'')
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write
    self.send_header(key, value)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 401, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

개발 서버( debug=True )에서 @sfermigier 와 동일한 문제가 발생했으며 동일한 역추적 오류가 있습니다.

이 동작은 일반적으로 매우 간단한 경우에 발생합니다. 일종의 자동 완성 기능을 사용하는 경우입니다. 브라우저는 쿼리 토큰에 대한 연결을 시작한 다음 중지하고 추가 토큰에 대한 다른 요청을 시작합니다. 많은 깨진 파이프로 끝날 것입니다. 그리고 이것은 개발 서버를 완전히 차단하는 마지막 릴리스까지는 문제가 되지 않았습니다 .
따라서 완전한 기능을 갖춘 응용 프로그램 서버를 사용하도록 제안하는 것이 좋은 해결 방법이지만 여기에 여전히 문제가 있습니다. 물론 개발 전용 문제이지만 트리거하는 것이 너무 일반적이라는 사실은 _프로토콜 내부_에 익숙하지 않은 많은 개발자를 방해합니다.
깨진 파이프는 매우 일반적이며(오류로 인한 긴 요청과 개발자가 브라우저 중지 버튼을 누르는 경우) 개발 서버를 중단해서는 안 됩니다.
그냥 내 의견입니다. :)

@xcash

이 동작은 일반적으로 매우 간단한 경우에 발생합니다. 일종의 자동 완성 기능을 사용하는 경우입니다. 브라우저는 쿼리 토큰에 대한 연결을 시작한 다음 중지하고 추가 토큰에 대한 다른 요청을 시작합니다.

관련이 있는 경우 browsersync with gulp.js 사용하여 이 문제가 발생했음을 확인할 수 있습니다.

WSGI 서버 실행을 포함하지 않는 솔루션이 있는 사람이 있습니까? 내 호스트에 대해 SYN 스캔을 수행하는 봇에서 이 문제가 발생하는 것 같습니다.

@glennzw 귀하의 환경에 대해 더 구체적으로

FWIW, 나는 릴리스를 많이 따라 잡지 못했고이 (매우 성가신) 문제가 2016 년 5 월에서 8 월 사이에 발생하기 시작했습니다. 나는 이것을 내 setup.py install_requires = ['Werkzeug<0.11', 'flask<0.11', ... 추가했습니다. 이것은 문제를 해결하는 것 같습니다(IME, Werkzeug를 고정하는 것만으로는 트릭을 수행하지 않는 것 같습니까?)

나에게 복제 사례는 충분히 간단했습니다. 페이지를 로드하지만 로드가 완료되지 않도록 하십시오. 즉, _any_ 깨진 파이프 오류를 트리거하면 웹 서버가 충돌하고 다른 요청을 처리하지 못합니다. IMHO, 웹 서버는 클라이언트가 연결을 조기에 닫을 때 _ 넘어질 수 없습니다_. 심지어 개발 중인 연결도 포함됩니다.

모두 passthrough_errors 가 어딘가에 설정되어 있지 않을까요?

@untitaker 이 경우, 팔레트/플라스크#1674 팔레트/플라스크#1679 팔레트/플라스크#1928 관련이 있습니까?

잘 모르겠습니다. 기자 중 한 명이 확인해 주셨으면 합니다.

2016년 8월 26일 17:05:25 CEST에 David Lord [email protected] 은 다음과 같이 썼습니다.

@untitaker 이 경우, 팔레트/플라스크#1674 팔레트/플라스크#1679
팔레트/플라스크#1928 관련 가능성이 있습니까?

당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -242761250

K-9 Mail을 사용하여 Android 기기에서 보냈습니다. 제 간략함을 용서하십시오.

cc @miguelgrinberg

Werkzeug는 깨진 파이프 및 연결 재설정 오류를 처리해야 한다고 생각합니다. 이것은 실제로 오류의 표시가 아니며 클라이언트가 방금 사라졌습니다. 이 경우 오류 패스스루가 설정되어 있더라도 위의 포괄 방식에서 무시할 예외로 인식되는 특별한 예외가 발생해야 합니다.

gunicorn이 수행하는 방법은 다음과 같습니다. https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

그것이 해야 할 일입니다. 번식 방법을 알아보려고 합니다
이 동작이지만 아직 사용할 수 있는 명확한 테스트 케이스가 없습니다. 따라서 질문
약 passthrough_errors .

나는 이것이 Werkzeug의 버그가 아니며 사용자의 브라우저가
다른 요청을 차단하는 연결이 아직 열려 있습니다(대신
서버 충돌). 브라우저를 닫았다가 다시 열면 서버가
다시 기능.

2016년 8월 26일 금요일 오전 11:54:16 -0700에 Miguel Grinberg는 다음과 같이 썼습니다.

Werkzeug는 깨진 파이프 및 연결 재설정 오류를 처리해야 한다고 생각합니다. 이것은 실제로 오류의 표시가 아니며 클라이언트가 방금 사라졌습니다. 이 경우 오류 패스스루가 설정되어 있더라도 위의 포괄 방식에서 무시할 예외로 인식되는 특별한 예외가 발생해야 합니다.

gunicorn이 수행하는 방법은 다음과 같습니다. https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -242821084

아, 그리고 깨진 파이프 오류가 _are_ 표시됩니다. 예, 하지만 설명된 대로 서버를 끊지 않아야 합니다. 가능한 이유에 대한 이전 의견을 참조하십시오.

최신 비트를 다시 테스트했는데 여전히 내 환경에서 동일한 동작이 표시됩니다. 하지만 재생산에 문제가 있는 것 같아서 내가 특별한 이유를 꺼내려고 했습니다.

import time
from flask import Flask
app = Flask(__name__)


@app.route('/')
def hello_world():
    time.sleep(5)
    return 'Hello, World!'


if __name__ == "__main__":
    app.run()

flask run 로 예상대로 작동하지만 python hello.py 를 통해 시작할 때 응답이 렌더링되도록 하기 전에 웹 브라우저를 닫으면 웹 서버가 충돌합니다.

응답의 일부가 손실된 것 같습니다.

2016년 8월 26일 금요일 오후 12:29:39 -0700에 Clayg는 다음과 같이 썼습니다.

최신 비트를 다시 테스트했는데 여전히 내 환경에서 동일한 동작이 표시됩니다. 하지만 재생산에 문제가 있는 것 같아서 내가 특별한 이유를 꺼내려고 했습니다.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment-242829536

예, slack에서 트리플 틱은 견적을 차단하는 방법이고 ctrl-return 는 줄 바꿈을 하는 방법입니다.
github에서 트리플 틱은 견적을 차단하는 방법이지만 ctrl-return 는 제출하는 방법입니다.
... 어쨌든 ... 근육 기억

나는 완료하기 위해 제출한 직후에 내 게시물을 편집했습니다. 그리고 나는 당신이 이메일에서 답장하는 것처럼 보이기 때문에 답장을 하는 것뿐이며, github에서 나의 편집 후에 또 다른 통지를 보낼지 확신이 서지 않습니다.

위 @clayg 의 수면 테스트로는 재현할 수 없습니다. 실제로 깨진 파이프 오류가 전혀 발생하지 않습니다. 해당 요청이 응답을 반환하기 전에 브라우저를 닫지만 Werkzeug는 어쨌든 끝까지 요청을 수행하고 200개의 로그 라인을 콘솔에 인쇄하고 오류를 표시하지 않습니다.

나는 또한 스트리밍 응답을 사용하여 끝없는 스트림에서 비디오 프레임을 제공하는 플라스크 비디오 스트리밍 예제를 사용하여 동일한 트릭을 시도했으며, 그 경우에도 브라우저를 닫을 수 있고 오류 없이 요청이 종료됩니다. 이것은 이상합니다. 과거에 이 응용 프로그램이 요청을 종료하기 전에 콘솔에 깨진 파이프 오류를 유발할 것이라고 확신하기 때문입니다.

사실 너무 빨리 말했어요. Python 2.7을 사용할 때 비디오 스트리밍 앱으로 매번 재생산할 수 있습니다. 3.5에서 재생산할 수 없습니다. 위의 모든 스택 추적은 2.7에 대한 것이므로 Python 3으로 테스트하는 경우 염두에 두십시오.

흥미로운 데이터 포인트가 하나 더 있습니다. reloader로 실행하면 자식 프로세스가 종료되면 reloader를 실행하는 마스터 프로세스가 다른 프로세스를 시작하므로 중단이 없습니다. 그러나 리로더 없이 서버를 실행하는 경우 깨진 파이프 오류로 인해 콘솔로 돌아갑니다.

편집: 다른 프로세스 부분을 시작하는 리로더를 무시하십시오. 이는 발생하지 않는 것 같고 대신 통과 오류 설정을 변경하는 효과를 보고 있었던 것 같습니다.

좋아, 여기 내가 생각하는 일에 대한 분석이 있습니다.

• 클라이언트가 요청 중간에 사라짐
• 요청이 계속됩니다. 소켓 연결이 버퍼링된 것으로 보이므로 대부분의 경우 소켓에 쓰기 작업을 수행해도 문제가 발생하지 않습니다.
• 요청이 끝나면 소켓 서버 클래스는 소켓에서 flush() 를 발행합니다. 이것은 현재 수정된 Python 라이브러리의 오래된 버그의 주제였습니다: http://bugs.python.org/issue14574. 이 수정의 해결책은 socket.error 를 포착하고 무시하는 것이었습니다.
• 그런 다음 소켓 서버는 연결을 닫으려고 합니다. 이것은 OP의 역추적에서 가져온 다음 스택 프레임입니다.

File "/usr/lib/python2.7/SocketServer.py", line 710, in finish self.wfile.close()

• 불행히도 Python 2.7에서 socket.close() 메서드가 수행하는 첫 번째 작업은 다시 플러시하는 것입니다.

File "/usr/lib/python2.7/socket.py", line 279, in close self.flush()

• 이 두 번째 플러시 시도는 try/except로 보호되지 않으므로 EPIPE 예외가 발생합니다.
• 소켓 서버는 예외를 포착한 다음 서버의 handle_error() 메서드에 전달합니다.
• handle_error() 의 Werkzeug 구현은 passthrough_errors 설정을 살펴보고 항상 True 설정했기 때문에 EPIPE 오류를 다시 발생시키고 버블링되도록 합니다. 맨 위.

Python 3의 소켓 코드는 완전히 다르며, 특히 주변에 try/except가 없는 플러시 호출이 없는 것으로 보입니다. EPIPE 오류는 Python 3을 사용할 때 Werkzeug까지 버블링조차 되지 않습니다.

passthrough_errors가 true로 설정되어 있습니까? Werkzeug에서는 기본적으로 false입니다.

2016년 8월 27일 02:10:13 CEST에서 Miguel Grinberg [email protected] 은 다음과 같이 썼습니다.

좋아, 여기 내가 생각하는 일에 대한 분석이 있습니다.

• 클라이언트가 요청 중간에 사라짐
• 요청이 계속됩니다. 소켓 연결은 다음과 같습니다.
  버퍼링되어 있으므로 대부분의 경우 소켓에 대한 쓰기는
  문제.
• 요청이 끝나면 소켓 서버 클래스는 flush() 발행합니다.
  소켓에. 이것은 Python 라이브러리의 오래된 버그의 주제였습니다.
  현재 수정되었습니다: http://bugs.python.org/issue14574. NS
  이 수정의 해결책은 socket.error 를 포착하고 무시하는 것입니다.
• 그런 다음 소켓 서버는 연결을 닫으려고 합니다. 이것이
  OP의 역추적에서 다음 스택 프레임:

 File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
 self.wfile.close()

• 불행히도 Python 2.7에서 가장 먼저 socket.close()
  메소드는 다시 플러시됩니다.

 File "/usr/lib/python2.7/socket.py", line 279, in close
 self.flush()

• 이 두 번째 플러시 시도는 try/except로 보호되지 않으므로
  EPIPE 예외를 발생시킵니다.
• 소켓 서버는 예외를 포착한 다음 예외를 전달합니다.
  서버의 handle_error() 메소드.
• handle_error() 의 Werkzeug 구현은
  passthrough_errors 설정이며 항상 다음으로 설정되어 있으므로
  True , EPIPE 오류를 다시 발생시키고 위로 버블링되도록 합니다.

Python 3의 소켓 코드는 완전히 다르며, 특히,
주변에 try/except 없이 플러시 호출이 없는 것 같습니다.
그들을. EPIPE 오류는 사용할 때 Werkzeug까지 버블링되지 않습니다.
파이썬 3.

당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -242881523

K-9 Mail을 사용하여 Android 기기에서 보냈습니다. 제 간략함을 용서하십시오.

오, 에헴: https://github.com/pallets/flask/pull/1679

passthrough_errors 는 app.debug 에 의존해야 한다고 생각합니다. NVM은 쓸모가 없다

실제로 해당 PR을 되돌리는 것 외에는 다른 옵션이 없습니다. passthrough_errors=True 프로그램에 디버거를 연결하지 않은 경우 좋은 기본 동작이 아닙니다.

다른 방법을 찾았습니다. 두 가지 PR:

• https://github.com/pallets/flask/pull/1996 -- 트레이스백이 여전히 표시된다는 점을 제외하고 자체적으로 문제를 해결합니다.
• https://github.com/pallets/werkzeug/pull/998 -- passthrough_errors=True 인 경우에도 소켓 오류를 다시 발생시키지 마십시오. 어쨌든 그런 의도는 아닌 것 같아요

둘 다 넓은 의미에서 동작 변경이므로 백포트하지 않는 것이 좋습니다.

https://github.com/pallets/flask/pull/1996 이 허용 가능한 솔루션이라고 생각합니다. 중요한 것은 예외가 전파되는 것을 원하지 않는 일반적인 경우를 수정한다는 것입니다. 전파하고 싶다면 디버깅 중이며, 이 경우 socket.error가 전파되어서는 안 될 때 전파되는 것은 큰 문제가 아닙니다.

https://github.com/pallets/werkzeug/pull/998 수정은 좋지 않습니다. 응용 프로그램은 자체 처리기의 소켓으로 수행하는 작업에서 합법적으로 이러한 예외를 발생시킬 수 있으며 이러한 예외도 묵음 처리됩니다. 이상적인 솔루션은 이러한 문제가 발생한 위치에서 포착된 다음 handle_error 가 인식하고 무시할 수 있는 일부 사용자 정의 예외 클래스로 다시 발생시키는 것입니다. SocketServer 를 변경하거나 오버로드하지 않으려는 경우 이 부분을 그대로 두는 것이 좋습니다. EPIPE는 콘솔에 덤프되지만 Python 2에서만 가능하며 적어도 다른 수정 사항이 적용된 후에도 서버를 중지하지 않을 것입니다. 무해하고 과거에 존재했던 동작입니다. passthrough_errors 변경.

설명하는 동작은 PASSTHROUGH_ERRORS가 활성화된 경우에만 발생합니다. 그렇지 않으면 Flask 내에서 예외가 발생합니다.

나는이 미용 개선이 가치가 없다고 생각합니다.

2016년 8월 27일 18:29:30 CEST에 Miguel Grinberg [email protected] 은 다음과 같이 썼습니다.

https://github.com/pallets/flask/pull/1996 이 허용된다고 생각합니다.
해결책. 중요한 것은 다음과 같은 일반적인 경우를 수정한다는 것입니다.
예외가 전파되는 것을 원하지 않습니다. 전파하고 싶다면,
그런 다음 디버깅 중이며이 경우 socket.error가 발생합니다.
전파되지 않아야 할 때 전파되는 것은 큰 문제가 아닙니다.

https://github.com/pallets/werkzeug/pull/998 수정이 좋지 않습니다.
그렇지만. 응용 프로그램은 다음에서 합법적으로 이러한 예외를 발생시킬 수 있습니다.
자체 핸들러의 소켓으로 수행하는 작업
침묵하기도 한다. 이상적인 해결책은 이것들을 잡는 것입니다.
그들이 발생하는 장소에서 다음 일부 사용자 정의 예외로 다시 발생합니다.
handle_error 가 인식하고 무시할 수 있는 클래스입니다. 우리가
아마도 SocketServer 를 변경하거나 과부하하고 싶지 않을 것입니다. 제 생각에는
투표는 이 부분을 그대로 두는 것입니다. 당신은 EPIPE를 덤프 할 것입니다
콘솔이지만 Python 2에서만 가능하며 적어도 멈추지 않을 것입니다.
다른 수정 사항 이후에 서버가 들어갑니다. 무해하고
내가 만들기 전에 과거에 존재했던 행동
passthrough_errors 변경.

당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -242926832

K-9 Mail을 사용하여 Android 기기에서 보냈습니다. 제 간략함을 용서하십시오.

마스터에서 수정했습니다.

설명하는 동작은 PASSTHROUGH_ERRORS가 활성화된 경우에만 발생합니다.

예, 나는 그 세부 사항을 생략했습니다. 그러나 이 변경은 이 중 어느 것도 문제가 되지 않는 Python 3에도 영향을 미칩니다. Py3에서 통과 오류가 활성화되면 애플리케이션에서 발생하는 합법적인 socket.error가 침묵됩니다.

master는 wfm인 것 같습니다. 다음 릴리스를 기대합니다. 감사합니다!

안녕하세요, 저는 NGINX 뒤에서 실행되는 Werkzeug 개발 서버를 사용하고 있습니다. 동일한 문제에 직면해 있습니다. 누구든지 이 문제를 해결해 줄 수 있습니까?
11:13:11 web.1 | 127.0.0.1 - - [15/Sep/2016 11:13:11] "GET /api/method/frappe.utils.print_format.download_pdf?doctype=Purchase%20Order&name=PO-00001&format=PO&no_letterhead=0 HTTP/1.1" 200 - 11:13:11 web.1 | Error on request: 11:13:11 web.1 | Traceback (most recent call last): 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi 11:13:11 web.1 | execute(self.server.app) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 184, in execute 11:13:11 web.1 | write(data) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write 11:13:11 web.1 | self.send_header(key, value) 11:13:11 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", line 401, in send_header 11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (keyword, value)) 11:13:11 web.1 | IOError: [Errno 32] Broken pipe

도와주세요

Ragav는 werkzeug의 내장 dev 대신 다른 응용 프로그램 서버를 사용합니다.
gunicorn과 같은 서버. 현재로서는 유일한 해결책입니다.

2016-09-15 8:07 GMT+02:00 Ragav 알림 @github.com:

안녕하세요, 저는 NGINX 뒤에서 실행되는 Werkzeug 개발 서버를 사용하고 있습니다.
같은 문제로 누구든지 나를 도울 수 있습니다. ```
11:13:11 web.1 | 127.0.0.1 - - [15/9/2016 11:13:11] "GET
/api/method/frappe.utils.print_format.download_pdf?
doctype=구매%20주문&이름=PO-00001&형식=PO&no_letterhead=0
HTTP/1.1" 200 -
11:13:11 web.1 | 요청 시 오류:
11:13:11 web.1 | 역추적(가장 최근 호출 마지막):
11:13:11 web.1 | 파일 "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", 193행, run_wsgi
11:13:11 web.1 | 실행(self.server.app)
11:13:11 web.1 | 파일 "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", 184행, 실행 중
11:13:11 web.1 | 쓰기(데이터)
11:13:11 web.1 | 파일 "/home/ommi/frappe-bench/env/
lib/python2.7/site-packages/werkzeug/serving.py", 152행, 작성 중
11:13:11 web.1 | self.send_header(키, 값)
11:13:11 web.1 | 파일 "/usr/lib/python2.7/BaseHTTPServer.py", 401행,
send_header에서
11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (키워드, 값))
11:13:11 web.1 | IOError: [Errno 32] 깨진 파이프

도와주세요

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -247243400,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA6MZ6DNiRIfL91CLeYOoA70W9_nQQzGks5qqOCMgaJpZM4I58cy
.

최근 수정 커밋에 따라 passthrough_errors=False로 app.run을 호출하여 이 문제를 해결할 수 있었습니다. YMMV

충돌을 일으킨 버그는 2016년 12월 21일에 릴리스 된 버전 0.12에서 수정되었습니다 .

• 내부 서버 오류(풀 요청 #2006)를 반환하는 대신 개발 서버 충돌을 일으키는 동작 변경을 되돌립니다.

버전 0.12는 지난 주에만 출시되었습니다.

2017년 3월 20일 월요일 09:05:00AM -0700에서 Alan Rotman은 다음과 같이 썼습니다.

충돌을 일으킨 버그는 2016년 12월 21일에 릴리스 된 버전 0.12에서 수정되었습니다 .

• 내부 서버 오류(풀 요청 #2006)를 반환하는 대신 개발 서버 충돌을 일으키는 동작 변경을 되돌립니다.

--
열기/닫기 상태를 수정했기 때문에 이 메시지가 표시됩니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -287807602

오늘 방금 ReleaseNotes를 보았고 이 수정 사항을 오랫동안 기다려 왔습니다.

참조 :
버전 0.12
2016년 12월 21일 출시, 코드명 Punch.

https://pypi.python.org/pypi/Flask/0.12
크기에 업로드된 파일 형식 Py 버전
Flask-0.12-py2.py3-none-any.whl (md5) 파이썬 휠 2.7 2016-12-21 80KB
Flask-0.12.tar.gz(md5) 소스 2016-12-21 519KB

아, 네, 플라스크를 말씀하시는군요. 확신하는.

2017년 3월 20일 월요일 09:22:15AM -0700에서 Alan Rotman은 다음과 같이 썼습니다.

오늘 방금 ReleaseNotes를 보았고 이 수정 사항을 오랫동안 기다려 왔습니다.

참조 :
버전 0.12
2016년 12월 21일 출시, 코드명 Punch.

https://pypi.python.org/pypi/Flask/0.12
크기에 업로드된 파일 형식 Py 버전
Flask-0.12-py2.py3-none-any.whl (md5) 파이썬 휠 2.7 2016-12-21 80KB
Flask-0.12.tar.gz(md5) 소스 2016-12-21 519KB

--
열기/닫기 상태를 수정했기 때문에 이 메시지가 표시됩니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/pallets/werkzeug/issues/954#issuecomment -287813405

threaded=True 모드의 werkzeug에서 flask 0.12.2를 실행할 때 이 문제를 겪고 있는 사람을 위한 참고 사항:
스레드 모드에서 기본적으로 각 werkzeug 스레드에는 실제로 여전히 이 문제가 있는 것 같습니다. 즉, 반환하는 데 시간이 걸리는 경로를 요청한 다음 클라이언트에서 연결을 닫으면 특정 werkzeug가 IOError Broken Pipe를 기록한 다음 죽는다. 내 응용 프로그램에서 이것이 어떻게든 메모리 누수를 일으키고 있다는 것을 발견했다는 점을 제외하고 서버 전체는 계속 작동합니다. 모든 스레드에서 파이프가 끊어진 후 플라스크 프로세스가 천천히 성장하고 모든 RAM을 사용한 다음 SWAP을 사용한 다음 마지막으로 OS에 의해 사망.
app.run에서 passthrough_errors=False를 명시적으로 전송하면 문제가 해결된 것 같습니다. 클라이언트 연결이 끊길 때 스레드가 더 이상 죽지 않고 정상적으로 IOError를 기록하고 다음도 기록합니다(passthrough_errors=False를 명시적으로 설정하지 않고는 본 적이 없음).

Exception happened during processing of request from ('127.0.0.1', 50652)
----------------------------------------

그런 다음 서버는 계속 정상적으로 실행됩니다. 메모리 누수가 다시 나타나는지 확인하려면 아직 몇 시간을 기다려야 하지만 그렇지 않기를 바랍니다.

누군가에게 도움이 될 경우를 대비하여.

Ubuntu VM의 Kubernetes에 있는 Ubuntu Docker 컨테이너에서도 이 오류가 발생했습니다.

Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 270, in run_wsgi
    execute(self.server.app)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 261, in execute
    write(data)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 227, in write
    self.send_header(key, value)
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

새로운 Ubuntu xenial VM을 만들고 Kubernetes의 Ubuntu Docker 컨테이너에서 동일한 코드를 실행했는데 이 오류가 표시되지 않고 Python Flask가 예상대로 작동했습니다. 내 호스트(Ubuntu VM)에 문제가 있다고 생각합니다.

@vhosakot 앱 구성을 어떻게 설정했는지 알려

경로 기능에서 경로 지정을 위한 다른 기능을 사용했습니다.
해당 함수의 응답에서 데이터를 가져왔습니다.
이제 해당 데이터에 _loads()_를 사용하면 오류가 발생합니다.

...
response = get_contents().data
        if response:
            data = loads(response)
..

오류: IOError: [Errno 32] Broken pipe