生产环境调用google-chrome工具渲染pdf进程挂起分析

问题描述：

客户生产环境某台机器在接收到交易请求，执行通过脚本调用google-chrome访问页面渲染生成pdf过程时，前端交易无应答直到超时异常；

问题分析：

1.对于这个交易过程，通过业务实现来分析，其链路如下：

交易调用链路

2.对于可能导致交易发生阻塞的点，最容易的就是想到业务系统自身的处理日志，通过查看交易自身的业务日志请求、应答发现，在后端服务执行到调用环境中的google-chrome插件生成pdf的过程没有正常执行结束，所以需要关注这个插件的执行过程发生了什么问题；

3.首先通过Linux中，系统中检查后端应用派生出的子进程，有许多google-chrome工具生成的子进程未正常结束：

调用google-chrome工具子进程挂起

4.对于linux中的进程挂起，我们通常使用strace工具检查进程阻塞在什么地方了（strace -v -tt -T -p 进程ID）：

进程阻塞在poll系统调用上

5.无法直观分析上下文的调用过程，经过针对google-chrome分析其使用原理，为chrome的后端针对URL渲染页面生成PDF的过程，不需要有浏览器视图的访问，是通过java后台调用插件工具，在后台进行页面的渲染后将页面写成pdf文件格式；

6.在进程执行的挂起命令可以模拟java，进行手动调用过程，来通过strace动态跟踪（strace -v -tt -T google-chrome 。。。）：

手动跟踪系统调用过程

7.发现进程是阻塞在一个socket(6015)的访问上，经过对6015端口连接情况的分析，返现这是个xserver生成sshd进程在监听，猜测可能是chrome执行过程中，需要访问这个端口，所以针对这个端口进行抓包如下：

针对问题套接口抓包

8.对于X11这个协议不是很熟悉，通过这个过程无法识别出是否正确，所以需要客户针对目前没有问题的环境也进行抓包和API调用分析，如下：

正常环境套接口抓包

通讯对应系统调用

9.可以发现，原环境，也存在这个访问过程，但是明显针对socket的访问是得到了应答的，说明目前的生产环境这个服务存在问题，无应答，导致进程一直在等待，从而无法完成后续任务，所以在测试环境进行复现，但是发现测试环境根本没有这个访问过程，没有去去读/root/.Xauthority这个文件后再访问socket的过程，所以开始怀疑是否和这个文件作为条件从而导致后续代码执行流程有关，但是测试环境无法复现这个问题，只能在有问题的生产上验证，但是出于安全考虑，可能需要备份生产front用户下的/root/.Xauthority文件再验证是否还会去访问socket，由于业务时间内，备份文件/root/.Xauthority存在风险，所以想是否可以找一个其他用户，看是否有这个文件/root/.Xauthority，恰巧这个系统内有个jdk用户，家目录下没有这个/root/.Xauthority文件，从而使用jdk用户执行命令，结果如下：

切换用户执行后端模拟渲染pdf工具

10.发现没有读取/root/.Xauthority文件，和访问socket的过程，所以问题定位一定和用户的环境变量因素有关，在非业务时间，可以针对front家目录下的/root/.Xauthority进行备份时，客户运维反馈，备份后，文件/root/.Xauthority又自动生成，针对这个自动生成问题，在本地环境进行实验发现，客户应该是通过xshell使用front用户登录导致，通过root用户su切换到front是不会生成，并且在jdk用户下没有发现/root/.Xauthority文件，可以得知，jdk用户一定是通过su - jdk的方式切换，并且执行命令不会有问题；所以让客户运维通过root登录后，su - front，然后执行命令，结果命令成功生成pdf文件；

11.所以得知，这个访问/root/.Xauthority文件后，连接socket的过程不是生成pdf的必要过程，可以使用这个方式绕过而解决问题，但是根本问题是客户的这个环境的xserver存在问题；

12.需要通过root登录后，su - front；然后重启业务服务程序，使业务进程集成的环境变量是不需要去访问/root/.Xauthority 和socket的，从而绕过xserver问题；

13.本次问题分析，主要是尽快解决交易阻塞问题，没能对X11服务访问的阻塞原因详细分析，这个可能是这个环境下问题的根本原因，所以这个问题还需针对X11的服务过程再学习分析；