Clever Geek Handbook

HTTP错误503。服务不可用：托管支持中的一种情况

托管支持的工作基本上是相同的类型，客户的大多数请求都是根据完善的方案解决的，但是有时您仍然必须面对不平凡的问题。然后，工程师的主要任务是找到一条-唯一能够找到解决方案的正确路径。在本文中，我想谈谈我们如何在共享主机上遇到浮动错误“ HTTP错误503。服务不可用”，我们如何尝试捕获，诊断并意外结束。



开始



托管为用户提供了典型的Linux + Apache + Mysql + PHP堆栈和管理包装。在我们的案例中，这是基于Centos 7并转换为CloudLinux的ISP Manager 5业务。从管理方面来看，CloudLinux提供了用于管理限制的工具，以及具有各种操作模式（CGI，FastCGI，LSAPI）的PHP选择器。



这次，客户与我们联系并遇到以下问题。他在Wordpress引擎上的网站定期开始出现503错误，并告知了我们。



以50x开头的响应代码涉及服务器端问题。这些可能是站点本身以及为其提供服务的Web服务器的问题。



我们收到以下错误的典型情况：



  • 500 Internal Server Error-经常与站点代码中的语法错误或缺少库/不受支持的PHP版本相关。连接到站点数据库也可能存在问题，或者文件/目录的权限不正确
  • 502错误的网关-例如，如果Nginx引用了错误的Apache Web服务器端口，或者Apache进程由于某种原因停止工作
  • 504网关超时-在Web服务器配置中指定的时间内未收到来自Apache的响应
  • 508达到资源限制-已超过分配给用户的资源限制


此列表仅包含一些最常见的情况。还值得注意的是，当超出限制时，用户会同时收到500和503错误。



诊断这些错误时，第一步是检查Web服务器日志。通常，这足以确定罪魁祸首并解决问题。



关于本例中的503错误，我们在日志中看到一个条目：

[lsapi：错误] [pid 49817] [客户端xxxx：6801] [主机XXX.XX]发送请求时出错（GET /index.php HTTP / 1.0）；uri（/index.php）内容长度（0）：ReceiveAckHdr：没有要从后端读取的内容（LVE ID 8514），请检查docs.cloudlinux.com/mod_lsapi_troubleshooting.html
仅基于此日志，无法确定可能是什么问题。



初步诊断



最初，我们检查了超出限制的用户统计信息。前几天记录了少量的过量，但是日志中的错误是新鲜的，而且，它们以一到几分钟的间隔出现在日志中。



我们还使用错误日志中提供的链接研究了CloudLinux建议。

更改任何参数都不会带来任何结果。



该站点在Mysql 5.7服务器上使用了一个数据库，该数据库在Docker容器中的同一服务器上运行。容器日志包含以下消息： 



[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)


这些消息中包括有关正在调查的站点的连接中断的消息。这给出了与DBMS的连接未正确执行的假设。为了进行检查，我们在测试域上部署了站点的副本，并将站点数据库转换为5.5.65-MariaDB DBMS的本地Centos 7版本。在测试站点上，使用curl实用程序执行了数百个请求。该错误无法重现。但是这个结果是初步的，在生产站点上转换数据库之后，问题仍然存在。



因此，消除了与DBMS错误连接的问题。



下一个建议是检查网站本身是否存在任何问题。为此，我们建立了一个单独的虚拟服务器，在该服务器上我们提出了最相似的环境。唯一的显着区别是缺少CloudLinux。该问题不能在测试服务器上重现。因此，我们确定站点代码中的所有内容都井井有条。但是，我们尝试以相同的方式禁用Wordpress插件，但问题仍然存在。



结果，我们得出结论，问题在于我们的主机。



在分析其他站点的日志之后，发现在许多站点上都发现了问题。约100个验证时： 



/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99


在测试过程中，我们发现新安装的干净CMS Wordpress还会定期出现错误503。



大约2个月之前，我们进行了服务器现代化的工作，特别是将Apache的操作模式从Worker更改为Prefork，以便能够在PHP中使用PHP。 LSAPI而不是慢速CGI。有一个假设可能会影响此结果，或者需要一些其他Apache设置，但是我们无法将Worker模式返回。在更改Apache操作模式的过程中，所有站点配置均被更改，该过程并不很快，并且并非所有操作都可以顺利进行。



更正Apache设置也没有得到理想的结果。



一路上，我们在搜索引擎中寻找类似的问题。在其中一个论坛上，与会人员认为托管人有问题，如果问题没有解决，则需要更改。当您站在另一边时，听起来并不乐观，但是您可以理解客户。为什么他需要不工作的主机。



在这一阶段，我们已经收集了可用的信息和执行的结果。联系他们以支持CloudLinux。



详细的诊断



几天来，CloudLinux支持人员深入研究了该问题。基本上，建议是关于已建立的用户限制的。我们也检查了这个问题。在禁用限制（用户的CageFS选项）并且在PHP模式下将限制作为Apache模块启用的情况下，未观察到此问题。基于此，已经暗示CloudLinux正在某种程度上产生影响。结果，到本周结束时，请求已升级为支持的第3级，但还没有解决方案。



在此过程中，我们研究了有关CGI和LSAPI模式的Apache文档，在具有测试站点的不同端口上的托管服务器上设置了第二个Apache实例，通过直接向Apache发送请求并接收相同的错误代码来消除Nginx的影响。



LSAPI文档有助于诊断503错误：

www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki：php：503-errors

在“高级疑难解答”部分中，建议跟踪系统中发现的过程： 



while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done


该命令已经过改进，可以将所有进程及其标识符记录在文件中。



查看跟踪文件时，我们会看到一些相同的行： 



cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...


如果我们看一下进程发送的信号结构的描述，我们会发现 



pid_t    si_pid;       /* Sending process ID */


指示发送信号的进程的标识符。



在研究轨迹时，系统中不再使用PID 42053的过程，因此，在捕获轨迹的过程中，我们决定也监视发送SIGHUP信号的过程。

在扰流器下，描述了一些动作，这些动作使得可以确定它是什么类型的进程，并获得其跟踪以及有关向其发送SIGHUP信号的进程的附加信息。



追踪技术
控制台1。 



tail -f /var/www/httpd-logs/sitename.error.log


2. 



while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep "sitename" | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid -o /tmp/strace/trace.$mypid; fi ; done


3. 



while true; do if mypid=`cat /tmp/strace/trace.* | grep si_pid | cut -d '{' -f 2 | cut -d'=' -f 4 | cut -d',' -f 1`; then ps -aux | grep $mypid; fi; done;


4. 



seq 1 10000 | xargs -i sh -c "curl -I http://sitename/"


1 , 4 503, 4.



结果，我们得到了流程的名称，该流程/opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini



每分钟在系统中执行一次。



我们跟踪几个cagefsctl进程，从头到尾至少跟踪一个： 



for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;


接下来，我们研究他的所作所为，例如： 



cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP


还获得了以SIGHUP信号终止的进程ID。终止的进程是当前正在运行的PHP进程。



接收到的数据已转移到CloudLinux支持，以阐明此过程的合法性以及它是否应以这种频率工作。



后来，我们收到一个答案，说明团队的工作/usr/sbin/cagefsctl --rebuild-alt-php-ini执行正确，唯一的警告是团队执行得太频繁了。通常在系统更新或PHP设置更改时调用。



在这种情况下，剩下的唯一线索是检查谁是cagefsctl进程的父级。



结果很快就到来了，我们感到惊讶的是，cagefsctl的父进程是ispmgrnode进程。有点奇怪，因为ISP Manager的日志记录级别设置为最大值，并且在ispmgr.log中看不到cagefsctl调用。



现在，有足够的数据可以与ISP系统支持联系。



结果



执行ISP Manager更新后触发了该问题。通常，更新ISP Manager是正常情况，但它导致同步过程开始，并以错误结束并每分钟重新启动。同步过程调用了cagefsctl过程，该过程又终止了PHP过程。



同步过程中止的原因是为了使设备现代化而在主机上进行的工作。问题发生前几个月，服务器中安装了PCI-e NVMe驱动器，XFS分区已创建并安装在/ var目录中。用户的文件也已传输到该文件，但磁盘配额未更新。挂载选项还不够，还需要在ISP Manager参数中更改文件系统类型，因为 它调用命令来更新磁盘配额。对于Ext4和XFS，这些命令是不同的。



因此，问题在工作几个月后就感到了。



结论



我们自己创造了问题，但直到最后一刻才弄清楚。对于未来，我们将尝试尽可能多地考虑细微差别。在来自CloudLinux和ISP系统支持的训练有素的同事的帮助下，问题得以解决。现在我们的主机稳定了。我们已经获得了经验，这将对我们的未来工作有所帮助。



PS：我希望您对阅读本文感兴趣，它将帮助某人快速解决类似的问题。


More articles:


All Articles