Gunicorn: 「起動ワーカー」は、終了信号がないにもかかわらず、無限にループしています

ssh -Dockerコンテナに入ると、次のエラーが見つかりました。

Illegal instruction (core dumped)

おそらく、gunicornはエラーを飲み込むのではなく、このようなエラーを表面化する必要がありますか、それとも別の方法で処理する必要がありますか？ わからない、誰か他の人を助けるかもしれないので、私がこれを上げると思っただけです！

問題を報告していただきありがとうございます。

これがどこで発生するかを理解できれば、それは非常に役立ちます。

おそらく、ワーカーが終了するときにログを追加できます。 通常、ワーカー自体はログに記録しますが、非常に突然殺された場合はログに記録されません。

心配ない！

このスレッドに追加したばかりのSpacyに問題があるようです： https ：

とにかく、 strace確認するように、それはSIGILLを引き起こしています：

--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7ff48bbe6cea} ---
+++ killed by SIGILL (core dumped) +++
Illegal instruction (core dumped)

ワーカーを幻想的に再起動するのではなく、gunicornがこれを識別してエラーをログに記録できればいいと思いますが、終了コードがどのように機能するかについてはほとんどわかりません。

一部の終了コードには間違いなく特別な意味があり、おそらくそれらをログに記録できます。
http://tldp.org/LDP/abs/html/exitcodes.html

いいですね！ さらに、終了コードが予約済みの終了コードではない場合（この場合など）、それをログに記録できれば（説明なしで）クールなので、ワーカーが実際に終了していることは明らかです🙂

同様の問題があります。httpリクエストを行うと、gunicornは常に新しいワーカーを起動します。 応答が返ってこないので、常に新しいワーカーを再起動します。 2つのhttpリクエストからのStraceログ：

select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=510, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=32} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 510
lseek(8, 0, SEEK_CUR)                   = 0
close(8)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 840340})     = 1 (in [3], left {0, 840338})
read(3, ".", 1)                         = 1
read(3, 0x7f2682025fa0, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-q4aa72u7", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 8
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-q4aa72u7", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-q4aa72u7")       = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(8, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(8, 0, SEEK_CUR)                   = 0
lseek(8, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 558
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 37381}[2017-12-28 17:50:23 +0000] [558] [INFO] Booting worker with pid: 558
) = 0 (Timeout)
select(4, [3], [], [], {1, 0}loading test-eu-ovh settings
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0}
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=499, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=31} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 499
lseek(7, 0, SEEK_CUR)                   = 0
close(7)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 450691})     = 1 (in [3], left {0, 450689})
read(3, ".", 1)                         = 1
read(3, 0x7f2682067de8, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-5x9a40ca", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 7
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-5x9a40ca", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-5x9a40ca")       = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(7, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(7, 0, SEEK_CUR)                   = 0
lseek(7, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 579
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 8144}[2017-12-28 17:50:30 +0000] [579] [INFO] Booting worker with pid: 579
)  = 0 (Timeout)
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0

同じ問題に直面しています。 syncワーカータイプの場合、 gunicornが数秒以内に繰り返し起動します。 ワーカーのタイムアウトを900はありません。

アクション前のロードで、AWSS3からデータをダウンロードしています。 さまざまなファイルをダウンロードするのに約1分10秒かかります。

@ sara-02 gunicornを起動するためのコマンドラインは何ですか？

@benoitc gunicorn --pythonpath /src -b 0.0.0.0:$SERVICE_PORT --workers=1 -k sync -t $SERVICE_TIMEOUT flask_endpoint:app
ここに存在

@ sara-02ありがとう。

古い労働者は本当に退出していますか、それともオンラインのままで新しい労働者が生まれていますか？ デバッグログにも何が表示されますか？

ログはボトコアログと混ざっていますが、こんな感じです

[INFO] Booting worker with pid:  a
[INFO] Booting worker with pid:  b
[INFO] Booting worker with pid:  c

しかし、労働者は殺されていますか？ コマンドps ax|grep gunicorn返すものは何ですか？

@benoitc

ただし、1つの質問ですが、ワーカー制限が1に設定されているのに、なぜ2つのgunicornプロセスが表示されるのでしょうか。 1人のマスターと1人の労働者ですか？

1つのアービタープロセス（マスター）とNのワーカープロセスがあります:)

それで、ワーカーが正しく起動するたびにコマンドを実行しますか？ もしそうなら、古い労働者が殺されたようで、新しい労働者が生まれます。 調査します。

@ sara-02最後にもう1つ、これはdockerでも発生しますか？

@ benoitc on docker-composeは期待どおりに機能していますが、同じコードをOpenshift 、このエラーが表示されます。 メモリ要件を増やすことで修正されましたが、 docker-composeを介してアプリケーションを実行すると、使用するメモリがlimited未満になります。

単なる更新ですが、私にとっての問題は実際にはメモリエラーであり、メモリの問題が修正されたときに修正されました。

@benoitc
Dockerで5つのgunicornワーカーを生成しようとしているときに、同じ問題に直面しています。
@ sara-02
メモリエラーの原因をどのように特定しましたか？

@ gulshan-gaurav 2つのことが私を助けました：
ポッドに割り当てられたメモリを増やし、クラッシュを停止しました。 次に、OpenshiftZabbixログを確認しました。

@ sara-02
ステージングポッドでも、メモリにロードしているファイルとモデルは50Mbになるため、5人のワーカーには2GBのメモリで十分です。

@ gulshan-gauravどの問題に直面していますか？ そこに5つのプロセスがあるのは良さそうです。

私も同じ問題を抱えていました。 正確な問題は見つかりませんでしたが、Python3.5から3.6にアップグレードすると解決しました。

Dockerコンテナでも同じ問題に直面しています。 Gunicornは、失敗の原因となるエンドポイントを呼び出すたびに新しいワーカーをボットし続けますが、例外やエラーはGunicornのログファイルに出力されません。 印刷することを選択したものがログに記録され、突然ログファイルに「pidでワーカーを起動しています...」と表示されます。

助けになった1つのステップは、env変数PYTHONUNBUFFEREDを追加することでした。 それ以前は、printステートメントでさえ消えて、Gunicornのログに保存されませんでした。

アプリの他の2つのエンドポイントは正しく機能します。

Gunicornを次のコマンドで実行します：gunicorn localhost：5000 --enable-stdio-inheritance --error-logfile /var/log/gunicorn/error.log --access-logfile / var / log / gunicorn / access。 log --capture-output --log-level debug

すでにPython3.6を実行していて、メモリに問題がないように見えることをtopで確認しました。

編集：それはPythonの問題であり、Gunicornのせいではないようです。 いくつかのバージョンの不一致により、特定の操作の実行中にPythonがトレースなしで停止していました。

私はワーカーノードが思い付くという同様の問題に直面しています
Booting worker with pid: 17636 。 以前のワーカーノードを強制終了しているのか、以前のワーカーノードがまだ存在しているのかわかりません。 しかし、gunicornのコマンドライン引数で言及されているワーカーの数はわずか3- -workers=3です。 また、Pythonバージョン3.7を使用しています

scikit-learnの依存関係に不一致がありましたが、それを解決した後でも、同じ無限のワーカーが登場しています。 どのような種類のPythonバージョンの不一致を探す必要があり、それらを特定する方法は？

OpenShift内でも同じ問題に直面しています。

画像でわかるように、私は6人のワーカーを使用しています（3人で試していました）。
ポッドのメモリを増やしましたが、機能しません。

BuildConfig：

何か案が？

ありがとう

エルブの後ろでこれをawsで実行していますか？ elbとgunicornの間にnginx入力を入れることでその問題を解決しました

同じ問題があります。

flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Starting gunicorn 19.9.0
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Using worker: sync
flask_1  | [2019-02-23 09:08:17 +0000] [8] [INFO] Booting worker with pid: 8
flask_1  | [2019-02-23 09:08:19 +0000] [12] [INFO] Booting worker with pid: 12
flask_1  | [2019-02-23 09:08:19 +0000] [16] [INFO] Booting worker with pid: 16
flask_1  | [2019-02-23 09:08:20 +0000] [20] [INFO] Booting worker with pid: 20
flask_1  | [2019-02-23 09:08:21 +0000] [24] [INFO] Booting worker with pid: 24
flask_1  | [2019-02-23 09:08:22 +0000] [28] [INFO] Booting worker with pid: 28
flask_1  | [2019-02-23 09:08:23 +0000] [32] [INFO] Booting worker with pid: 32
flask_1  | [2019-02-23 09:08:25 +0000] [36] [INFO] Booting worker with pid: 36
flask_1  | [2019-02-23 09:08:26 +0000] [40] [INFO] Booting worker with pid: 40
flask_1  | [2019-02-23 09:08:27 +0000] [44] [INFO] Booting worker with pid: 44
flask_1  | [2019-02-23 09:08:29 +0000] [48] [INFO] Booting worker with pid: 48
flask_1  | [2019-02-23 09:08:30 +0000] [52] [INFO] Booting worker with pid: 52
flask_1  | [2019-02-23 09:08:31 +0000] [56] [INFO] Booting worker with pid: 56
flask_1  | [2019-02-23 09:08:33 +0000] [60] [INFO] Booting worker with pid: 60
flask_1  | [2019-02-23 09:08:34 +0000] [64] [INFO] Booting worker with pid: 64
flask_1  | [2019-02-23 09:08:35 +0000] [68] [INFO] Booting worker with pid: 68
flask_1  | [2019-02-23 09:08:36 +0000] [72] [INFO] Booting worker with pid: 72
flask_1  | [2019-02-23 09:08:37 +0000] [76] [INFO] Booting worker with pid: 76
flask_1  | [2019-02-23 09:08:38 +0000] [80] [INFO] Booting worker with pid: 80
flask_1  | [2019-02-23 09:08:40 +0000] [84] [INFO] Booting worker with pid: 84
flask_1  | [2019-02-23 09:08:41 +0000] [88] [INFO] Booting worker with pid: 88
flask_1  | [2019-02-23 09:08:42 +0000] [92] [INFO] Booting worker with pid: 92
flask_1  | [2019-02-23 09:08:44 +0000] [96] [INFO] Booting worker with pid: 96
flask_1  | [2019-02-23 09:08:45 +0000] [100] [INFO] Booting worker with pid: 100
flask_1  | [2019-02-23 09:08:45 +0000] [104] [INFO] Booting worker with pid: 104
flask_1  | [2019-02-23 09:08:46 +0000] [108] [INFO] Booting worker with pid: 108
flask_1  | [2019-02-23 09:08:47 +0000] [112] [INFO] Booting worker with pid: 112
flask_1  | [2019-02-23 09:08:48 +0000] [116] [INFO] Booting worker with pid: 116
flask_1  | [2019-02-23 09:08:49 +0000] [120] [INFO] Booting worker with pid: 120
flask_1  | [2019-02-23 09:08:50 +0000] [124] [INFO] Booting worker with pid: 124
flask_1  | [2019-02-23 09:08:52 +0000] [128] [INFO] Booting worker with pid: 128

これがdocker-compose.ymlです：

version: '3'
services:
  flask:
    build: .
    command: gunicorn -b 0.0.0.0:5000 hello:app --reload
    environment:
      - FLASK_APP=hello.py
      - FLASK_DEBUG=1
      - PYTHONUNBUFFERED=True
    ports:
      - "5000:5000"
    volumes:
      - ./:/root

どのDockerイメージを使用しますか？

@benoitc

[ec2-user@ip-172-31-85-181 web-services-course]$ docker --version
Docker version 18.06.1-ce, build e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
[ec2-user@ip-172-31-85-181 web-services-course]$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

リンクは次のとおりです。

• Dockerfile https://github.com/glebmikha/web-services-course/blob/master/Dockerfile
• docker-compose.yml https://github.com/glebmikha/web-services-course/blob/master/docker-compose.yml

それはメモリ不足が原因である可能性があることがわかりました。 アプリは利用可能なよりも多くのメモリを必要とします。
しかし、それは単なる仮定です

情報と同じように、3人のワーカーにgunicorn confを実行したときにこの動作を正確に観察しましたが、シングルコアCPUを搭載した仮想マシンにコードをデプロイしました。 次に、2コアを使用するように環境を変更すると、明らかに問題は解消されました。

「ワーカーが終了する」がレベルINFOのみであるのはなぜですか？エラーの結果を除いて、ワーカーが終了するのはなぜですか？ 上記の他のいくつかの報告によると、時々「pidでワーカーを起動する」以外はログに何も記録されずに、ワーカースレッドがシステムOOMキラーによって強制終了されていることを理解するのに長い時間がかかりました。

@HughWarringtonは、終了するワーカーが必ずしもエラーではないためです。 ワーカーは、シグナルまたは--max-requestsなどのオプションによって終了できます。

@HughWarringtonおそらく、ワーカーが異常な終了コードで終了したときのために、アービターにロギングを追加することができます。

そのためのチケットを開くか、このコードをreap_workersメソッドに追加するPRを提供することができます。

同じ問題が発生しました。解決策は、ポッドのメモリサイズを増やすことでした。

大規模なspaCyモデルを使用してDockerでGunicornを実行すると同じ問題が発生し、エラーメッセージなしでワーカーを再起動し続けました。 解決策は、Dockerコンテナのメモリを増やすことです。

今日、Kubernetesで実行されているgevent（1.4.0）ワーカーを含む最新（19.9.0）のgunicornでこの問題が発生しました。 アプリはFalconアプリであり、Dockerイメージはタグ3.7.3付いた公式のPythonイメージです。

[2019-07-05 00:07:42 +0000] [8] [INFO] Starting gunicorn 19.9.0
[2019-07-05 00:07:42 +0000] [8] [INFO] Listening at: http://0.0.0.0:5000 (8)
[2019-07-05 00:07:42 +0000] [8] [INFO] Using worker: gevent
[2019-07-05 00:07:43 +0000] [35] [INFO] Booting worker with pid: 35
[2019-07-05 00:07:43 +0000] [36] [INFO] Booting worker with pid: 36
[2019-07-05 00:07:43 +0000] [37] [INFO] Booting worker with pid: 37
[2019-07-05 00:07:43 +0000] [38] [INFO] Booting worker with pid: 38
[2019-07-05 00:07:43 +0000] [41] [INFO] Booting worker with pid: 41
[2019-07-05 00:07:43 +0000] [43] [INFO] Booting worker with pid: 43
[2019-07-05 00:07:43 +0000] [45] [INFO] Booting worker with pid: 45
[2019-07-05 00:07:43 +0000] [49] [INFO] Booting worker with pid: 49
[2019-07-05 00:07:43 +0000] [47] [INFO] Booting worker with pid: 47
[2019-07-05 00:07:49 +0000] [53] [INFO] Booting worker with pid: 53
[2019-07-05 00:07:50 +0000] [54] [INFO] Booting worker with pid: 54
[2019-07-05 00:07:53 +0000] [57] [INFO] Booting worker with pid: 57
[...]

ポッドには次のリソース設定がありました。

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

すべてを2倍にすると、問題が修正されました。

私たちが気づいた一つ興味深いのは、見てたときにということでしたdmesg我々はそれがあることがわかりますホストマシン上のsegfaultで-ing libcrypto SSLを使用してサーバにアクセスするとき

大きなモデルをメモリにロードしていないので、メモリは私にとって問題ではないようです。 ワーカーがクラッシュし続けるだけで、エラーメッセージが表示されません。 これに対する修正はありますか？

私にとって同じ問題、修正するアイデアはありますか？ python 3.6.3 with gunicorn 19.9.0

@MrKivenあなたのアプリは何ですか？ リクエストのようなものを使用していますか？

誰かが問題を再現する方法を提供できますか？

これは、パイプラインで実行されるいくつかのコンポーネントのマネージャーです。 それらの一部は、同じマシンまたはリモートマシン上の他のコンポーネントへのHTTP要求を開始する場合があります。 パイプラインの一部のモジュールは並行して実行できますが、ThreadPoolExecutorを使用して実行されます。 これらは共有オブジェクトを使用しませんが、後で単一の結果オブジェクトに集約されるデータ構造のみを生成します。

残念ながら、私たちが持っているシステムを公開せずに最小限の例をまとめることができるかどうかはわかりません。

リクエストは、新しいプロセスをフォークすることがあるスレッドで多くの危険なことを行います。 別のクライアントを使用することをお勧めします。 少なくともリクエストに使用している行を貼り付けることはできますか？ タイムアウト機能を使用していますか？

それらの1つは次のようになります。

try:
     resp = requests.post(self._endpoint, json=request_data)

     if resp.status_code != 200:
          logger.critical("[Error]: status code is {}".format(resp.status_code))
          return None

     response = resp.json()
     return {"intent": response["intent"], "intent_ranking": response["intent_ranking"]}
except ConnectionError as exc:
     logger.critical("[Exception] {}".format(str(exc)))
     return None

ありがとう。 そこからシンプルなものを作ってみます。

とにかく、誰かが例として、またはユニットテストとして動作を再現するPRを送ってくれれば、私たちは実際に正しいことを修正していることを確認できます。

それが誰かを助けることができるかどうかはわかりませんが、ドッキングされたフラスコのWebアプリを実行しているときに同じ問題が発生し、dockerfileのベースイメージをpython:3.6.9-alpineに更新して解決しました

ホストのDmesgは、lilibpython3.6m.so.1.0でセグメンテーション違反を示しました。

[626278.653010] gunicorn[19965]: segfault at 70 ip 00007f6423e7faee sp 00007ffc4e9a2a38 error 4 in libpython3.6m.so.1.0[7f6423d8a000+194000]

私のDockerイメージはpython:3.6-alpineに基づいており、 apk updateを実行してPythonを3.6.8に更新していました。

言ったように、ベースイメージをpython:3.6.9-alpine変更すると、私はそれを解決しました

Flask + Docker + Kubernetesを実行するのと同じ課題に直面しました。 CPUとメモリの制限を増やすことで、私はそれを解決しました。

同じことが私たちにも起こりました。 リソース制限を増やすと、問題が修正されました。

これは、macOS Catalina（コンテナ化されていない）で突然起こりました。

私を助けたのは：

1. opensslのインストール：

brew install openssl

1. これを実行して~/.zshrc追加します：

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib:$DYLD_LIBRARY_PATH

出典： https ：

同様の課題を抱えており、誰かが私を助けてくれればありがたいです。
これは私が持っていたものです。

" root @ ubuntu-s-1vcpu-1gb-nyc1-01 ：〜＃sudo systemctl status gunicorn.service●gunicorn.service-gunicornデーモンロード済み：ロード済み（/etc/systemd/system/gunicorn.service;無効;ベンダープリセット：有効）アクティブ：月2020-02-24 07:48:04 UTC以降アクティブ（実行中）; 44分前メインPID：4846（gunicorn）タスク：4（制限：1151）CGroup：/system.slice/gunicorn.service├ ─4846/ home / bright / djangoprojectdir / djangoprojectenv / bin / python / home / bright / djangoprojectdir / djangoprojectenv / bin /gunicorn-├─4866/ home / bright / djangoprojectdir / djangoprojectenv / bin / python / home / bright / djangoprojectdir / djangoprojectenv / bin /gunicorn-├─4868/ home / bright / djangoprojectdir / djangoprojectenv / bin / python / home / bright / djangoprojectdir / djangoprojectenv / bin /gunicorn-└─4869/ home / bright / djangoprojectdir / djangoprojectenv / bin / python / home / bright / djangoprojectdir / djangoprojectenv / bin / gunicorn- 2月24日07：48：04ubuntu-s-1vcpu-1gb-nyc1-01 systemd [1]：gunicornデーモンを停止しました。2月24日07:48:04 ubuntu-s-1vcpu -1gb-nyc1-01 systemd [1 ]：gunicornデーモンを起動しました。 2月24日07：48：05ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4846] [INFO]開始gunicorn20.0。42月24日07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4846] [INFO]リスニング：unix：/ run / gunicorn .soc 2月24日07：48：05ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4846] [情報]ワーカーの使用：同期2月24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4866] [INFO] pidを使用した起動ワーカー：4866 2月24日07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4868] [INFO] pidを使用した起動ワーカー：4868 Feb 24 07 ：48：05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：[2020-02-24 07:48:05 +0000] [4869] [INFO] pidを使用した起動ワーカー：4869 Feb 24 08： 03:41 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn [4846]：---- [24 / Feb / 2020：08：03：41 +0000] "GET / HTTP / 1.0" 400 26 "-" "Mozilla /5.0（Wi lines 1-20 / 20（END） "誰かが私がそれを修正するのを手伝ってくれませんか？

@BrightNanaは、 dmesgを与えて、gunicornエラーがあるかどうかを確認できますか？
dmesg | grep gunicornは、他のエラーを除外するのに役立ちます

こんにちは、
systemdサービスとしてgunicornを提供したい場合、debian9でも同じバグがあります。 CLIから起動すると、gunicornはエラーなしで実行されます。

dmesg | grep gunicornから抽出：

journalctlからの抜粋：
Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1054] [INFO] Booting worker with pid: 1054 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1057] [INFO] Booting worker with pid: 1057 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1060] [INFO] Booting worker with pid: 1060 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1064] [INFO] Booting worker with pid: 1064 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1067] [INFO] Booting worker with pid: 1067 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1070] [INFO] Booting worker with pid: 1070 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1073] [INFO] Booting worker with pid: 1073 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1076] [INFO] Booting worker with pid: 1076 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1079] [INFO] Booting worker with pid: 1079 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1082] [INFO] Booting worker with pid: 1082 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1085] [INFO] Booting worker with pid: 1085 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1088] [INFO] Booting worker with pid: 1088 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1091] [INFO] Booting worker with pid: 1091 Mär 12 07:01:09 build-server gunicorn[828]: [2020-03-12 07:01:09 +0100] [1094] [INFO] Booting worker with pid: 1094
systemctl statusからの抜粋：
● api.service - API Server for BuildingChallenge served with Gunicorn Loaded: loaded (/etc/systemd/system/api.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 08:26:01 CET; 22min ago Main PID: 8150 (gunicorn) Tasks: 3 (limit: 4915) Memory: 37.7M (high: 100.0M max: 500.0M) CGroup: /system.slice/api.service ├─ 8150 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app ├─28936 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app └─28938 /usr/bin/python3 -Es /usr/bin/lsb_release -a Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28909] [INFO] Booting worker with pid: 28909 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28912] [INFO] Booting worker with pid: 28912 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28915] [INFO] Booting worker with pid: 28915 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28918] [INFO] Booting worker with pid: 28918 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28921] [INFO] Booting worker with pid: 28921 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28924] [INFO] Booting worker with pid: 28924 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28927] [INFO] Booting worker with pid: 28927 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28930] [INFO] Booting worker with pid: 28930 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28933] [INFO] Booting worker with pid: 28933 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28936] [INFO] Booting worker with pid: 28936

ご協力いただきありがとうございます。

このような状況のデバッグに役立つPRを作成しました。 誰か見てもらえますか？
https://github.com/benoitc/gunicorn/pull/2315

Docker内で実行されているFlaskアプリケーションでも同じ問題が発生しました。 ワーカーは、プロセスIDを増やしながら無限に再起動していました。

問題は私にとってメモリ関連でした。Dockerに許可されるメモリを増やすと、ワーカーが効果的に生成されました。

@tilgovi 、あなたが最初にそこに着いたので、あなたが私の変更をあなたのPRに取り入れたいかどうか私は気にしません。 これは、信号を介して殺されている労働者をカバーします。

@mildebrandt見てみます、ありがとう！

また、Dockerコンテナ内でGunicorn（20.0.4）+ Gevent（1.5.0）+ Flaskを使用すると、この動作が突然発生します。

[  328.699160] gunicorn[5151]: segfault at 78 ip 00007fc1113c16be sp 00007ffce50452a0 error 4 in _greenlet.cpython-37m-x86_64-linux-gnu.so[7fc11138d000+3e000]

私の場合、ご覧のとおり、セグメンテーション違反はgeventが原因です。 奇妙なことに、このコンテナは5日前に正常に機能し、その後コードは変更されず、ライブラリのバージョンも変更されず、すべてが特定のリリースに設定されています。 依存関係としてflask-mailを削除しました。これにより、他の依存関係のバージョンがわずかに変更された可能性があります。

gevent == 1.5.0からgevent == 20.9.0に更新すると、問題が解決しました。

@ifiddesあなたの問題はおそらく無関係です。 古いバージョンのgeventと最新バージョンのグリーンレットの間でABIの互換性の問題が発生しています。 https://github.com/python-greenlet/greenlet/issues/178を参照して

ああ、@ jamaddenに感謝します。 この投稿は、ブートワーカーの無限のスポーンを検索したときに見つけたすべてでしたが、その問題とその問題のタイミングは私の問題に適合しました。

Ubuntu 20.04サーバーをAWSマシンで、本番環境で

このマシンは、他の本番マシンと同様にAnsibleを使用して構成されました。

[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Current configuration:
  config: None
  bind: ['127.0.0.1:8000']
  backlog: 2048
  workers: 1
  worker_class: uvicorn.workers.UvicornWorker
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /var/www/realistico/app
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1001
  group: 1001
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: /var/www/realistico/logs/gunicorn/access.log
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: /var/www/realistico/logs/gunicorn/error.log
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  dogstatsd_tags: 
  statsd_prefix: 
  proc_name: None
  default_proc_name: realistico.asgi:application
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f7ba5fdd550>
  on_reload: <function OnReload.on_reload at 0x7f7ba5fdd670>
  when_ready: <function WhenReady.when_ready at 0x7f7ba5fdd790>
  pre_fork: <function Prefork.pre_fork at 0x7f7ba5fdd8b0>
  post_fork: <function Postfork.post_fork at 0x7f7ba5fdd9d0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f7ba5fddaf0>
  worker_int: <function WorkerInt.worker_int at 0x7f7ba5fddc10>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f7ba5fddd30>
  pre_exec: <function PreExec.pre_exec at 0x7f7ba5fdde50>
  pre_request: <function PreRequest.pre_request at 0x7f7ba5fddf70>
  post_request: <function PostRequest.post_request at 0x7f7ba5f6e040>
  child_exit: <function ChildExit.child_exit at 0x7f7ba5f6e160>
  worker_exit: <function WorkerExit.worker_exit at 0x7f7ba5f6e280>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f7ba5f6e3a0>
  on_exit: <function OnExit.on_exit at 0x7f7ba5f6e4c0>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: None
  raw_paste_global_conf: []
  strip_header_spaces: False
[2020-10-15 15:11:49 +0000] [18068] [INFO] Starting gunicorn 20.0.4
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Arbiter booted
[2020-10-15 15:11:49 +0000] [18068] [INFO] Listening at: unix:/run/gunicorn.sock (18068)
[2020-10-15 15:11:49 +0000] [18068] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-10-15 15:11:49 +0000] [18080] [INFO] Booting worker with pid: 18080
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] 1 workers
[2020-10-15 15:11:51 +0000] [18083] [INFO] Booting worker with pid: 18083
[2020-10-15 15:11:53 +0000] [18086] [INFO] Booting worker with pid: 18086
...
[2020-10-15 15:12:09 +0000] [18120] [INFO] Booting worker with pid: 18120
[2020-10-15 15:12:11 +0000] [18123] [INFO] Booting worker with pid: 18123

この問題の解決に成功せずに（そしてログにエラーが発生することなく）何度も失敗した後、私はこのHello worldを試してみましたが、次のエラーが見つかりました：

ModuleNotFoundError: No module named 'httptools'

httptoolsインストールした後、 Hello worldアプリケーションは正常に動作し、予期せず、私のアプリケーションも動作します。

エラーがログに記録されなかった理由や、このライブラリが他のマシンにインストールされたが新しいマシンにはインストールされなかった理由はわかりませんが、これで問題が解決します。

これが最近発生し、すべてのCPUを消費して、それがあったkubernetesノードを停止しました。 dmesgに関するヒントのおかげで、最終的にエラーが見つかりました。

[225027.348869] traps: python[44796] general protection ip:7f8bd8f8f8b0 sp:7ffc21a0b370 error:0 in libpython3.7m.so.1.0[7f8bd8dca000+2d9000]

結局、私の問題はhttps://github.com/python-greenlet/greenlet/issues/178の別のインスタンスであり、gunicorn、gevent、およびgreenletを最新バージョンに更新することで解決されました。

これらのタイプの例外はPythonログを作成せず、キャッチできず、終了コード0を返し、発生するとマシンをハングさせる可能性があるため、管理が非常に困難です。

私は、gunicornがこの性質の急速なクラッシュループを検出し、

• 新しい労働者の産卵をあきらめるか、レート制限する
• この問題とhttps://github.com/python-greenlet/greenlet/issues/178に人々を導く有用なメッセージを提供し

おそらくmax_consecutive_startup_crashes 、デフォルトはnum_workers * 10ですか？

＃2504でクラッシュループ機能のリクエストを追跡しましょう。 ＃2315に追加でログインするためのPRもあります。 誰もが問題をデバッグしたようで、将来的に他の人を助けるためにいくつかの機能要求と改善がありますので、この問題を閉じます。 みんな、ありがとう！