烧瓶应用程序无法始终启动答案

【问题标题】：flask app won't consistenly boot烧瓶应用程序无法始终启动
【发布时间】：2017-10-18 20:31:43
【问题描述】：

我在测试我的烧瓶 API 应用时遇到问题，它无法始终启动。由于要求，我必须确保它在 CentOS6（默认为 python 2.6）上运行，但我使用自定义的 python 2.7 virtualenv。我的启动命令如下：

/opt/mist/mist_base/env/bin/uwsgi --py-autoreload 1 --master --socket=/tmp/mist_app.sock --pidfile=/tmp/mist_app.pid --module=wsgi --honour-stdin --chdir=/opt/mist/mist_base/app --threads=1 --virtualenv=/opt/mist/mist_base/env --die-on-term --uid mist --gid mist

自定义 virtualenv 是 /opt/mist/mist_base/env。

我有人帮我打包这个软件，以便使用 RPM/Yum 进行安装（他以前做过，并且以这种方式打包是一项要求）；在此过程中，他坚持要构建另一个自定义 python virtualenv (/opt/mist/mist_base/.localpython)。不幸的是，他已经离开了公司，我们没有关于做了什么的细节。我在其他 virtualenv 中寻找可以调用二进制文件/库的 RPM build/init 命令，但没有找到。

使用提供给我的说明，我构建了生成的 RPM 并将其安装在我的测试服务器上，一切运行良好。我将相同的 RPM 提供给我的客户安装在他的测试服务器中，但它没有启动。

我的工作启动顺序如下：

*** Starting uWSGI 2.0.14 (64bit) on [Thu May 18 13:49:09 2017] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-17) on 20 March 2017 07:18:55
os: Linux-2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Apr 11 17:13:24 UTC 2017
nodename: mistdb
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /opt/mist/mist_base/app
writing pidfile to /tmp/mist_app.pid
detected binary path: /opt/mist/mist_base/env/bin/uwsgi
setgid() to 487
setuid() to 493
chdir() to /opt/mist/mist_base/app
your processes number limit is 7394
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/mist_app.sock fd 3
Python version: 2.7.5 (default, Mar 20 2017, 06:43:30)  [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
Set PythonHome to /opt/mist/mist_base/env
Python main interpreter initialized at 0x21c4aa0
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x21c4aa0 pid: 24902 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 24902)
spawned uWSGI worker 1 (pid: 24907, cores: 1)
Python auto-reloader enabled

同时这是我的客户看到的：

*** Starting uWSGI 2.0.14 (64bit) on [Tue May 16 13:12:26 2017] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-17) on 20 March 2017 07:18:55
os: Linux-2.6.32-696.1.1.el6.x86_64 #1 SMP Tue Mar 21 12:19:18 EDT 2017
nodename: mist-testbed
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 2
current working directory: /
writing pidfile to /tmp/mist_app.pid
detected binary path: /opt/mist/mist_base/env/bin/uwsgi
setgid() to 497
setuid() to 497
chdir() to /opt/mist/mist_base/app
your processes number limit is 15208
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/mist_app.sock fd 3
Python version: 2.7.5 (default, Mar 20 2017, 06:43:30)  [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
Set PythonHome to /opt/mist/mist_base/env
Python main interpreter initialized at 0x280c890
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145536 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 139, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 103, in __get_openssl_constructor
    return __get_builtin_constructor(name)
  File "/opt/mist/mist_base/.localpython/lib/python2.7/hashlib.py", line 91, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
Traceback (most recent call last):
  File "./wsgi.py", line 1, in <module>
    from mist_main import app as application
  File "./mist_main.py", line 1, in <module>
    from _app import return_app
  File "./_app.py", line 1, in <module>
    from flask import Flask, Blueprint, render_template, session, redirect, url_for, escape, request, abort
  File "/opt/mist/mist_base/env/lib/python2.7/site-packages/flask/__init__.py", line 17, in <module>
    from werkzeug.exceptions import abort
  File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/__init__.py", line 151, in <module>
    __import__('werkzeug.exceptions')
  File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/exceptions.py", line 71, in <module>
    from werkzeug.wrappers import Response
  File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/wrappers.py", line 26, in <module>
    from werkzeug.http import HTTP_STATUS_CODES, \
  File "/opt/mist/mist_base/env/lib/python2.7/site-packages/werkzeug/http.py", line 32, in <module>
    from hashlib import md5
ImportError: cannot import name md5
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 25071)
spawned uWSGI worker 1 (pid: 25072, cores: 1)
Python auto-reloader enabled

在启动过程中，应用首先尝试使用 .localpython virtualenv，然后尝试使用 env virtualenv。由于我找不到任何使用 .localpython 的 RPM/init 代码，我无法解释为什么 1. 我的应用程序实例不使用它 2. 我的客户实例使用它。

这完全有可能是由于环境的不同，我们将尝试根据他们的规格构建一个 VM，看看是否能解决这个问题。这是否也仅仅是 virtualenv 损坏和/或没有包含所有需要的外部库的情况？

【问题讨论】：

似乎是hashlib 缺少组件的问题。我认为这个是相关的：stackoverflow.com/questions/20399331/…
我想知道为什么要使用两个 virtualenvs 中的库。我的理解是uwsgi 将使用--virtualenv 参数声明的库/二进制文件。直到本周，我从未见过这种行为的偏差。
我一直在做更多的挖掘工作，我正在查看lib/python2.7/hashlib.py 和__get_builtin_constructor() 我看到： elif name in ('MD5', 'md5'): import _md5 return _md5 .new _md5 在哪里？是系统级包提供的吗？

标签： python flask uwsgi centos6

【解决方案1】：

我的客户今天回来了，看起来他们在他们的 CentOS 6 服务器上做了一些我们没有做的事情。具体来说，他们运行了一个脚本来启用 FIPS 的服务器，并以某种方式与我的自定义 python 2.7 环境如何与内置加密库交互。

【讨论】：