昨天在前领导技术大牛吕哥的帮忙下，python服务管理从nginx+supervisor+uwsgi+python3改为了轻便结构nginx + unit + python3，部署和配置起来顿时轻松起来。服务器配置好以后赶紧上官网http://unit.nginx.org将英文文档全部啃完，全面理解了它的运行原理。
由于nginx unit它的服务重启方式，是自动检测配置文件是否有更改，然后才会自动重载，而python代码发布以后，并没有对配置进行更改，所以昨晚在进行代码更新以后，发现运行的还是旧的程序，和吕哥沟通后他说等他想想解决办法。早上一早就发信息过来并将执行代码发了过来。一看原来是直接kill掉进程的方式，再通过运行服务启动程序来进行重载。
然后我就拿测试服务器实验了起来，在服务器上输入下面命令，将unit进程kill掉
kill -9 `ps -ef |grep unit|awk '{print $2}'`
跟着执行启动服务命令（这个命令的路径，大家安装的位置不同路径是不一样的，替换成自己的就可以执行了）
/usr/local/src/unit/build/unitd
命令执行以后发现先是报下面错误，但服务正常启动了
2018/12/20 11:53:25 [alert] 1299#1299 Unable to create certificates storage directory: mkdir(state/certs/) failed (2: No such file or directory)
2018/12/20 11:53:25 [info] 1299#1299 bind(7, unix:control.unit.sock) failed (98: Address already in use)
进入buile目录下面发现state与certs目录都存在，没有发现有什么问题
输入命令查看服务启动状态：ps -ef | grep unit
检查服务没有启动，解决不了只能输入reboot重启一下服务器，重启后运行服务启动命令还是报同样的错误
2018/12/20 11:54:17 [alert] 1299#1299 bind(6, unix:control.unit.sock) failed (98: Address already in use)
服务直接挂了启动不了......
赶紧上goole和百度查询解决方案，发现没有一篇文章，难道只有我是这么干才会出来这种个问题吗？人品简直是爆炸了
没有办法的情况下，只能自己研究检查了，看看日志有没有什么记录，查看build目录下面的unit.log并没有什么异常记录。在检查的过程中发现build目录下面有个0字节的文件名很可疑，名字跟错误提示中的信息一样：control.unit.sock
感觉应该有可能是这个文件造成的，所以尝试使用删除命令将它删掉，然后再次运行服务启动命令，发现一切恢复正常状态，再次刷新这个文件夹，发现删除掉的这个文件又出来了
通过这样操作的结果，可以判断unit在启动后，它会在build目录创建一个名为control.unit.sock的文件，做为服务锁以防止服务同时启动多个，而当服务被非正常状态关闭时，可能就会引发这个文件没有被同步清除，而导致服务无法正常启动。
除了使用kill方法删除unit进程以外，我还尝试使用reboot直接启动服务器，也试过出现同样的问题，服务启动不了。还好发现这个问题以后积极研究解决了，不然万一线上系统哪一天要重启，导致同样的情况发生而一直无法访问，那就影响大了去了。
版权声明：本文原创发表于 博客园，作者为 AllEmpty 本文欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则视为侵权。
python开发QQ群：669058475（本群已满）、733466321（可以加2群） 作者博客：http://www.cnblogs.com/EmptyFS/