记一次uwsgi故障排除

文章目录

1. 1. 应用升级使用sqlite3数据库，引起访问出错
2. 2. 解决问题的关键步骤:编译安装最新版uwsgi
3. 3. 意外收获

我在本地调试了一个flask应用，本地跑得好好的，部署到远程centos6 32位vps上就出了问题。
问题非常隐蔽，因此也走了不少弯路，甚至最后都不知道是哪一步起了关键作用。因此记一下。

应用升级使用sqlite3数据库，引起访问出错

应用采用nginx+uwsgi+flask的结构

应用最新版本中引入了sqlite3数据库，就这一步出了问题。在要访问数据库的时候返回502 bad gateway，查uwsgi日志，记录提示pysqlite中出了错，找不到symbolsqlite3_stmt_readonly什么的(对了这个信息需要在flask开启debug模式才会被记录下来)。查了vps的sqlite3，是3.6版本，我开发机是3.8版本，在以undefined symbol sqlite3_stmt_readonly为关键词反复搜索信息的过程中知道了这个标志是3.7以后的版本才有的，猜想是不是sqlite版本问题。找到了pysqlite的github仓库中一个issue，也是同样的错误。根据下面开发者的回答进行了操作，然而并没有什么用。

又有说没有安装uwsgi的python插件，我用pip和yum都装了一下，也没有用。(pip install uwsgi, yum install uwsgi-plugin-python)

最后还弄出新的问题: 包_sqlite找不到。显然是包管理出问题了。中间各种麻烦，一气之下将python2.7.11源码下载编译安装，然后编译安装了easy_setup和pip，幸好自己以前写过教程。然后重新安装了应用的requirements，幸好之前有更新requirements。

这下出现了新问题，所有的python位置和版本都是2.7.11了，但重启uwsgi后竟然直接找不到flask包，一看发现日志记录的python版本还是之前的2.7.8，这个锅看来uwsgi非背不可了。又是一阵折腾python更新和uwsgi配置未果(包括设置虚拟python环境)。

解决问题的关键步骤:编译安装最新版uwsgi

后来想起来，特么这个uwsgi不是我装的啊，我当初下载的是2.0.10版本，这个运行的是2.0.12版本，这货好像是vps自带的！被vps坑过的我表示，这锅你就背了吧！而且当初还是在root下搞的uwsgi，正好一并改过来。

下载了uwsgi2.0.12版本的源码，进入源码目录，什么配置都不改
python uwsgiconfig.py --build
安装成功。(如果失败或者提示权限问题，就把涉及到的文件权限改成自己的)
python setup.py install
这一步是手动安装python uwsgi 包
然后设置bin，将/usr/local/bin/uwsgi软连接到python包里面那个uwsgi，别忘了把/usr/local/bin放在环境变量$PATH的最前面以优先载入

好了，试运行一下uwsgi，检查正常运行，版本号无误。

查看应用的config文件，没有变动，运行uwsgi，访问应用，可以访问，访问数据库，可以访问，查看uwsgi日志，没有错误。完美。感动哭。

一声不吭正常运行的nginx目睹了整个过程。谢天谢地幸好你一直正常运行。

意外收获

中间有些意外收获。

1. 先是编译的uwsgi-2.0.10的源码，安装好之后，运行提示我找不到应用，找不到python，逗我呢？后来一想原先的版本好像是2.0.12，不管是不是vps自带的，我自己下载编译总可以吧？于是这么做之后就好了

2. 后来觉得sudo nginx有点危险，查看nginx发现普通用户有运行权限，切换普通用户运行结果提示我bind() 0.0.0.0:80 permission denied，确信没有应用在用那个端口，一查才知道linux要求1024以下的端口都必须以sudo级别才可以绑定。老老实实改回sudo。按理说conf里配置8080端口应该也可以，但还是以后再说吧，如果有多个应用了再来配置别的访问端口。

3. nginx的conf里面可以直接配置uwsgi_param传给uwsgi，因此如果要配置多个应用，那么就要在conf/nginx.conf而不是单独的配置文件(对uwsgi来说,单独的配置文件就是用参数指定的xml或者ini格式的配置文件)中指定pythonpath和callable之类的参数。

4. nginx和uwsgi都是服务端程序，不同的是nginx主要负责前端显示，uwsgi主要负责后端数据处理。