本周五软工团队项目的第一次前后端全部对接时，出了一个蛋疼的错误。
最初起因是小丽叔出于安全的考虑，使用守护进程来跑Web服务器。守护进程(Daemon)是运行在后台的一种特殊进程，如果服务器用root权限来跑的话会有安全隐患，但是daemon本身无法更改一些没有放开权限的文件，即使网站被黑也不会有数据隐私泄露的情况。
但是在使用守护进程的过程中出现了一个很蛋疼的问题，在root权限下我们在Python中使用xml读取是完全没问题的，但是在使用守护进程后，却出现了一个毫无头绪的bug，报错信息如下：
Traceback (most recent call last):
File "-------------", line 411, in <module>（为保护隐私已经删去具体路径）
finish_str = ReadXmlTop()
File "--------", line 102, in ReadXmlTop
dom = xml.dom.minidom.parse(sys.argv[1])
File "/usr/lib/python2.7/xml/dom/minidom.py", line 1917, in parse
from xml.dom import expatbuilder
File "/usr/lib/python2.7/xml/dom/expatbuilder.py", line 32, in <module>
from xml.parsers import expat
File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in <module>
from pyexpat import *
ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so: undefined symbol: XML_SetHashSalt
很奇怪，我们虽然用到了minidom来读取xml，但是为什么root权限就可以，但是守护进程运行时就跪了呢？
一开始我们参考了何涛的建议，认为可能是因为守护进程没有权限去读/lib这个文件夹。但是在加了权限后，事实表明，依然不对！
那能是什么问题？在几经搜索与查找后，（在stackoverflow上有一个类似问题但是并没有人回答...）终于在一个国外的论坛上找到了些许眉目，原因就是动态链接库的命名冲突！
于是我们按照下面的方法在root权限下进行了检查：
ldd /usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so
发现显示如下
linux-vdso.so.1 => (0x00007fffba39e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbb9306f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbb92caa000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fbb92a7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbb934a8000)
其实能看出来这个动态链接库的指向路径确实是没有错误的，都是指向/lib/x86_64这个路径下的动态链接库，那么，究竟是哪里出了问题呢？
我们思索很长时间，终于想到，我们现在是在root下查询的，结果当然是正确的，于是我们在守护进程里去查询，终于发现了一些端倪：
libexpat.so.1 => /opt/lampp/lib/libexpat.spo.1.5. 2
其余动态链接库的指向全部正确，唯有这个指向出了错误！错误就是在这里，因为laravel框架里自带的一些动态链接库与python的libexpat.so.1动态链接库命名相同，并且在默认条件下，守护进程的LD_LIBRARY_PATH是/opt/lampp/lib，所以这个守护进程优先选择了lampp自带的expat。
但是由于lampp自带的expat是不兼容系统的expat的！(缺少一部分字段)所以没有办法执行xml的正确读取。
错误知道了，该如何解决呢？我们起初是想，更改守护进程的LD_LIBRARY_PATH，使用：
export LD_LIBRARY_PATH =/lib
但是不幸的是，不管我们如何更改，发现都没有办法成功更改守护进程的LD_LIBRARY_PATH，值永远是那个。在这过程中，我们还使用了一次ldconfig而让网站直接挂了...
最后机智过人的小丽叔想到了一点，守护进程是一个特殊的进程而不是一个用户，这就意味着，它必须得起一个shell来更改它的环境变量才可以成功。之前我们都是直接使用终端让守护进程执行一些操作，而像更改环境变量这种操作他没办法直接实现。所以最后写了一个shell脚本来更改环境变量，然后守护进程执行shell脚本才成功。
最后有一点要提示的是，在Linux上跑matlab，apache这些，也会有类似的expat的不兼容问题，解决方法与上一致。这种方法只能说是将影响降到最低，但是还是会有Bug隐患，暂时还没有找到更好的解决方案。