【ch05】Linux系统故障排查案例实战

Linux系统故障排查案例实战Linux服务器安全管理高级运维项目5“十四五”高等教育网络空间安全产业人才培养系列丛书“互联网+”新形态立体化一体精品教材+常见的Linux系统故障案例01常见的Linux系统故障案例在root用户下，使用su命令切换为一个普通用户oracle时出现了错误，如图5-1所示。01问题现象于是，尝试直接通过oracle用户登录系统，发现此时oracle用户也无法登录，出现与图5-1所示相同的错误。常见的Linux系统故障案例由图5-1中的错误提示可知，权限出现了问题。那么，可以从权限方面进行排查，基本思路如下。（1）用户/home/oracle目录权限问题。（2）su命令执行权限问题。（3）su命令依赖的共享库权限问题。（4）SELinux问题。（5）系统根空间问题。02解决思路常见的Linux系统故障案例根据解决思路，我们进行逐一排查。考虑到使用su命令切换为oracle用户时会读取/home/oracle目录下的环境变量配置文件。因此，首先检查/home/oracle目录的权限是否存在问题，输出结果如下：03排查过程由输出结果可知，/home/oracle目录的属主是oracle用户，而oracle用户对这个目录具有“rwx”权限。因此，oracle用户目录的权限设置是正确的，可以排除这个问题。继续检查su命令的执行是否存在权限问题，输出结果如下：常见的Linux系统故障案例知道了问题产生的原因，解决问题就变得非常简单，执行如下命令：04解决方法之后就可以顺利执行su命令。这个问题主要是根目录缺失可执行权限引起的。由于在Linux系统下，所有操作都是在根目录下进行的，因此导致/home/oracle目录缺失执行权限。实际上，根目录权限的缺乏对系统中运行的每个用户都存在相同的影响。因此，当权限出现问题时，一定要注意根目录的权限。“Read-onlyfilesystem”问题01问题现象根据上述信息，基本排查思路如下。（1）网站程序问题。（2）服务器磁盘故障。02解决思路工作人员接到客户电话，反馈他们的网站无法添加数据，但网站仍可以正常访问，服务器和磁盘阵列也没有任何报警信息。“Read-onlyfilesystem”问题03排查过程首先通知研发人员对网站程序进行排查。经过排查，发现没有程序出现问题，而在程序日志中有一条信息：根据上述信息可知，程序不能创建目录。那么，尝试手动创建一个目录。登录Web服务器，在/www/data/html目录下创建一个目录test，操作命令如下：根据上述信息可知，/www/data/html目录所在的磁盘分区出现了问题。经过排查，发现/www/data/html目录是挂载的磁盘阵列分区，因此找到了问题的根源。“Read-onlyfilesystem”问题04解决方法磁盘出现“Read-onlyfilesystem”的原因有很多，可能是文件系统数据块不一致造成的，也可能是磁盘故障造成的。主流的ext3、ext4文件系统都具有很强的自我修复机制。对于简单的错误，文件系统一般可以自行修复。当遇到无法修复的致命错误时，为了保证数据的一致性和安全性，文件系统会暂时禁止写操作，将其转为只读模式，从而出现了上面的“Read-onlyfilesystem”故障。手动修复文件系统错误的命令是fsck。在修复文件系统前，应卸载文件系统所在的磁盘分区，操作命令如下：系统提示无法卸载，可能是因为这个磁盘中正在运行文件对应的进程。检查正在运行的文件进程，操作命令如下：“Argumentlisttoolong”问题01问题现象这是一台MySQL数据库服务器，其中运行了很多定时任务，今天通过如下crontab命令添加了一个计划任务，在退出时发生了错误，如图5-8所示。“Argumentlisttoolong”问题02解决思路根据图5-8，可以基本判定磁盘空间已满。此时应检查服务器的磁盘空间。首先检查/tmp分区空间，然后检查根分区的磁盘空间，最后检查系统其他分区的磁盘空间。03排查过程通过df命令查看MySQL数据库服务器上所有磁盘分区的情况。经过检查，发现/tmp分区空间充裕，根分区也还有大量剩余空间，它们都不存在问题，但是/var磁盘分区空间已经使用100%。至此，已经确定问题的根源，是由/var磁盘分区空间耗尽导致的。由于crontab在保存时会将文件信息写到/var目录下，因此出现这个错误也是情理之中的。“Argumentlisttoolong”问题04解决方法使用“du-sh”命令检查/var目录下所有文件或目录的大小，发现/var/spool/clientmqueue目录占用了/var磁盘分区空间的90%。那么，/var/spool/clientmqueue目录下的文件都是怎么产生的呢？是否可以将其删除？下面简单介绍/var/spool/clientmqueue目录下的文件是怎么产生的。我们可以任意打开/var/spool/clientmqueue目录下的文件，发现其中都是一些邮件信息，邮件内容大多是关于CronDaemon的。实际上，/var/spool/clientmqueue就是一个邮件暂存目录。Linux服务器在默认情况下会发送一些邮件，如当cron执行的程序产生输出时，会向执行cron进程的用户发送邮件。在发送邮件时，系统会先将邮件复制到/var/spool/clientmqueue目录下，再等待MTA（MailTransferAgent，邮件传送代理）程序进行处理。MTA的主要功能是先将/var/spool/clientmqueue目录中的邮件转移到/var/spool/mqueue目录下，再通过sendmail服务将邮件发送到真正的目的地。检查MySQL数据库服务器的sendmail服务，会发现它没有开启，这就是/var/spool/clientmqueue目录异常增大的原因：由于缺少发送邮件的客户端服务，因此邮件都被积压在这个目录下了。“Argumentlisttoolong”问题04解决方法在确认这些内容都没用后，切换到/var/spool/clientmqueue目录下，执行rm命令删除所有的文件，出现如下错误：此时，出现了本节开头我们谈到的问题。当在Linux系统中尝试向系统命令传递大量参数时，会出现“Argumentlisttoolong”错误。这是Linux系统一直以来存在的限制。查看这个限制可以通过命令“getconfARG_MAX”来实现，如图5-9所示。2621440是CentOS6.x版本的一个最大值。在CentOS5.x中，这个值相对较小，如图5-10所示。inode耗尽问题客户的一台Oracle数据库服务器在重新启动后，无法启动oracle监听，如图5-11所示。由图5-11可以判断，应该是由磁盘空间耗尽而导致的无法启动oracle监听。因为Oracle数据库服务器在启动监听时需要创建监听日志文件，而图5-11中的3个TNS错误都是由最后一行错误导致的。因此，首先检查服务器磁盘空间，如图5-12所示。01问题现象inode耗尽问题既然错误提示与磁盘空间有关，那么深入研究一下关于磁盘空间的问题。在Linux系统中，对磁盘空间的占用分为3部分：第1部分是物理磁盘空间，第2部分是inode节点所占用的磁盘空间，第3部分是Linux系统用来存储信号量的磁盘空间。我们平时接触较多的是物理磁盘空间，对inode节点所占用的磁盘空间和Linux系统用来存储信号量的磁盘空间接 触较少。既然不是物理磁盘空间的问题，那么检查是否是inode节点耗尽的问题。通过“df-i”命令查看系统可用的inode节点，如图5-13所示。02解决思路inode耗尽问题由图5-13可知，确实是因inode节点耗尽而导致无法写日志文件的。由于inode节点已经全部被使用，虽然仍有可用磁盘空间，但是文件系统已经无法记录这些空余空间了，因此无法新建文件或文件夹。由于这里涉及inode节点知识，因此接下来简单介绍一下Linux系统中inode节点的概念。在Linux系统中，文件由数据块和元数据组成。数据块是多个连续性的扇区，是文件存取的最小单位。“块”（Block）的大小通常是4KB，即由连续8个扇区组成一个块。元数据用于记录文件的创建者、创建日期、大小等。这种存储文件元数据的区域被称为inode，又被称为“索引节点”。由于inode节点同样用于存储文件相关属性信息，因此inode节点同样会消耗磁盘空间。在进行磁盘格式化时，操作系统会自动将磁盘分成两个区域：一个是数据区，用于存放文件数据；另一个是inode区（InodeTable），用于存放inode所包含的信息。02解决思路inode耗尽问题知道了这个问题是由inode导致的后，接下来查看/var目录为何耗尽了inode。经过检查发现，/var/spool/clientmqueue/目录中有500多万个文件。经过分析，确定这个问题是系统的crontab任务导致的。因为系统开启了多个crontab任务，如果crontab任务没有重定向，则默认会在/var/spool/clientmqueue/目录下创建一个监听日志文件。随着时间的推移，这些文件会不断积累，导致文件数量激增。解决方法很简单，只需删除这些没用的文件即可。删除方法是直接使用rm命令，这时可能会提示“Argumentlisttoolong”错误，而解决这个问题的方法在5.1.3节中已经详细介绍了。通过如下命令即可完成删除操作：

[root@localhost~]#find/var/spool/clientmqueue/-name"*"-execrm-rf{}\;在删除监听日志文件后，重新启动oracle监听，并查看新的监听日志文件。至此，问题得到圆满解决。03解决方法文件已被删除，但空间未被释放的问题运维的监控系统发来通知，报告一台服务器空间满了。工作人员登录服务器并进行查看后，发现根分区确实没有剩余磁盘空间了，如图5-15所示。01问题现象文件已被删除，但空间未被释放的问题在一般情况下，删除文件后会释放磁盘空间，但是也存在特殊情况，如文件被进程锁定，或者有进程一直在向这个文件中写入数据等。要理解这个问题，需要了解Linux系统下文件的存储机制和存储结构。一个文件在文件系统中的存放分为两部分：指针部分和数据部分。指针部分位于文件系统的meta-data（元数据）中。在删除数据部分后，指针部分会从meta-data中被清除，而数据部分会被存储在磁盘中。在将数据对应的指针从meta-data中清除后，文件数据部分所占用的空间可以被覆盖并写入新的内容。当删除access_log文件后，空间未被释放的原因是httpd进程仍一直向这个文件中写入数据，导致虽然删除了access_log文件，但是由于进程被锁定，文件对应的指针部分未从meta-data中被清除。因此，系统内核认为文件并未被删除，从而导致在通过df命令查询空间时显示未被释放。02解决思路文件已被删除，但空间未被释放的问题既然有了解决问题的思路，那么接下来查看是否存在进程一直在向access_log文件中写入数据的问题。这里需要使用Linux系统下的lsof命令。通过lsof命令可以获取一个已经被删除但仍然被应用程序占用的文件列表，如图5-18所示。03排查过程文件已被删除，但空间未被释放的问题到这里问题基本排查清楚了。解决这类问题有很多种方法，其中最简单的方法是关闭或重新启动httpd进程。当然，也可以重新启动操作系统，但这并不是最佳的方法。对于这种不断向文件中写入日志数据的进程，为了释放文件所占用的磁盘空间，最佳的方法是在线清空这个文件，具体可以通过如下命令来实现：

[root@localhost~]#echo"">/tmp/access_log通过这种方法，不但可以马上释放磁盘空间，也可以保障进程继续向文件中写入日志数据。这种方法经常用于在线清理Apache、Tomcat、NGINX等Web服务产生的日志文件。02解决思路“Toomanyopenfiles”问题01问题现象一个基于Java的Web应用系统在后台添加数据时，出现了无法添加的提示。于是工作人员登录服务器查看Tomcat日志，发现了以下异常信息：

java.io.IOException:Toomanyopenfiles通过上述异常信息，可以基本判断是系统可用的文件描述符不足。由于Tomcat服务是以系统用户www启动的，因此以www用户身份登录系统后，通过“ulimit-n”命令查看系统允许打开的最大文件描述符的数量，输出信息如下：

[www@tomcatserver~]$ulimit–n 65535由上述输出信息可知，这台服务器允许打开的最大文件描述符的数量是65535。这么大的值应该足够使用，但是为什么会提示这样的错误呢？“Toomanyopenfiles”问题02解决思路这个案例涉及Linux系统下的ulimit命令。这里简单介绍一下ulimit命令的作用和使用技巧。ulimit命令主要用于限制进程对资源的使用，它支持各种类型的限制，常用的如下。内核文件的大小限制。进程数据块的大小限制。Shell进程创建文件的大小限制。可加锁内存的大小限制。常驻内存集的大小限制。打开文件句柄数的限制。分配堆栈的最大大小限制。CPU占用时间限制和用户最大可用的进程数限制。Shell进程所能使用的最大虚拟内存限制。ulimit命令的基本格式为：ulimit[options][limit]“Toomanyopenfiles”问题02解决思路“Toomanyopenfiles”问题02解决思路在介绍完ulimit命令后，继续介绍本案例。既然ulimit设置没问题，那么一定是设置没有生效的问题。接下来检查启动Tomcat服务的www用户环境变量中是否添加了ulimit资源限制。经过检查发现，www用户环境变量中没有添加ulimit资源限制。继续检查Tomcat启动脚本startup.sh文件中是否添加了ulimit资源限制。经过检查发现，startup.sh文件中没有添加ulimit资源限制。继续检查limits.conf文件中是否添加了ulimit资源限制，操作命令如下：由上述输出信息可知，limits.conf文件中添加了ulimit资源限制。既然已经添加了限制，配置也没有错误，为何还会报错呢？经过长时间思考，编者判断只有一种可能，即Tomcat的启动时间早于ulimit资源限制的添加时间。因此，首先查看Tomcat的启动时间，操作命令如下：“Toomanyopenfiles”问题02解决思路“Toomanyopenfiles”问题02解决思路由上述输出信息可知，这台服务器已经有283天没有重新启动过了。Tomcat是在2013年7月6日9点左右启动的，已经启动了约77天5小时。继续查看limits.conf文件的最后修改时间，如图5-19所示。通过stat命令可以很清楚地看出，limits.conf文件的最后修改时间是2013年7月12日。通过询问相关的Linux系统管理人员，基本确认是在这个时候添加的ulimit资源限制。这样此案例的问题就变得非常明显了。由于ulimit资源限制的添加时间晚于Tomcat最后一次的启动时间，而在此期间内，Tomcat服务一直未重新启动，操作系统也一直未重新启动，因此ulimit资源限制对Tomcat是无效的。同时，由于此操作系统是CentOS6.3，系统默认的最大可用句柄数是1024，Java进程仍使用Linux系统默认的值，因此出现“Toomanyopenfiles”错误也是合理的。在弄清楚问题之后，解决问题的方法就非常简单了，重新启动Tomcat服务即可。+Apache常见错误故障案例02“Nospaceleftondevice”错误01问题现象这也是一个客户案例：客户反馈在执行“apachectlstart”命令启动Apache时没有报错信息，但是不能访问网页。客户的网站是基于Apache+PHP+MySQL的在线交易平台。根据客户描述的现象，工作人员的第一反应是防火墙屏蔽了HTTP端口或SELinux，于是登录服务器查看相关信息，如图5-20所示。“Nospaceleftondevice”错误01问题现象由图5-20可知，防火墙所有策略都处于开启状态，没有任何限制，而SELinux处于关闭状态，应该不是防火墙的问题。既然不是防火墙的问题，那么查看httpd进程是否存在及httpd端口是否正常启动，如图5-21所示。图5-21中的操作命令首先查看了Apache上的httpd进程，显示没有httpd进程在运行，同时httpd对应的端口80也没有启动。于是，重新启动Apache，但在启动Apache的过程中没有报错，且启动完成后仍然没有httpd进程在运行。由此可知，应该是Apache内部出现了问题。“Nospaceleftondevice”错误02解决思路在判断是Apache的问题后，首先需要查看Apache的启动（error）日志。在查看Apache的error日志后，发现其中有一条可疑的输出信息，内容为：工作人员看到这条输出信息后，感觉应该是磁盘空间耗尽的问题，于是赶紧查看系统所有磁盘分区，结果发现所有磁盘分区都还有很多可用空间，这就有些奇怪了。在前面的案例中，详细地介绍了Linux系统下对磁盘空间的占用分为3部分：物理磁盘、inode节点所占用的磁盘空间和Linux系统用来存储信号量的磁盘空间。通过检查服务器的物理磁盘空间，发现仍有很多剩余空间，因此可以排除物理磁盘空间问题。接着通过“df-i”命令查看系统可用的inode节点，发现每个分区可用的inode都还有很多，因此可以排除inode

节点问题。那么，应该是存储信号量的磁盘空间耗尽问题。这里简单介绍一下与Linux系统信号量相关的知识。信号量是一种锁机制，用于协调进程之间互斥的访问临界资源，以确保某种共享资源不被多个进程同时访问。Linux系统的信号量用于进行进程之间的通信。它有两种标准实现，分别是Systemv及POSIX。现在大多数Linux系统都实现了这两种标准。这两种标准都可用于进行线程之间的通信，只是系统调用方式略有不同。“Nospaceleftondevice”错误02解决思路Systemv信号量通过系统调用semget来创建。通过Linux系统命令ipcs即可显示进程之间通信时使用的Systemv类型信号量及共享内存。POSIX信号量可用于线程和进程之间的通信，并且可分为有名的信号量和无名的信号量两种。也就是说，是否保存在磁盘上可以通过有名和无名的说法来对应。有名的信号量会以文件形式保存在/dev/shm下，因此可用于不相关进程之间的通信，而无名的信号量只能用于线程间和父子进程之间的通信。在对信号量有了简单了解后，可以发现Apache使用的进程之间的通信方式应该是Systemv，因此可以通过ipcs命令查看和解决这个问题。“Nospaceleftondevice”错误03应对思路在解决这个问题之前，首先查看Linux系统默认信号量的设置值，操作命令如下：

[root@localhost~]#cat/proc/sys/kernel/sem 2503200032128这4个输出值的含义如下。SEMMSL（250）：用于控制每个信号集的最大信号数量。SEMMNS（32000）：用于控制整个Linux系统中信号（而不是信号集）的最大数量。SEMOPM（32）：用于控制每个semop函数调用可以执行的信号操作数量。SEMMNI（28）：用于控制整个Linux系统中信号集的最大数量。“Nospaceleftondevice”错误03应对思路接着通过ipcs命令查看httpd进程占用了多少信号量，操作命令如下：

[root@localhost~]#ipcs-s|grepdaemon其中，“daemon”表示启动Apache进程的用户，默认是daemon用户，也可能是nobody用户，具体根据实际环境而定。在执行完此命令后，发现有很多基于daemon的信号量输出，终于找到了问题所在。解决信号量耗尽的方法很简单，通过ipcrm命令进行清除即可。其中，最简单的方法是执行如下组合命令：

[root@localhost~]#ipcs-s|grepnobody|perl-e'while(){@a=split(/\s+/);print`ipcrmsem$a[1]`}'执行完上述命令后，重新启动Apache，并查看是否有httpd进程启动。经过检查发现，此时httpd进程已启动，表明Apache可以正常工作。“Apache(20014)”错误01问题现象这是一个简单的客户案例：客户反映网站无法访问了，并且Apache也无法启动。客户的网站是基于Apache+Tomcat+MySQL的，其服务器信息如图5-22所示。这里提示httpd.pid文件错误。熟悉Apache的读者应该知道，httpd.pid文件实际上是Apache的进程pid文件，用于存储Apache的启动进程ID。“Apache(20014)”错误02解决思路这是一个简单的客户案例：客户反映网站无法访问了，并且Apache也无法启动。客户的网站是基于Apache+Tomcat+MySQL的，其服务器信息如图5-22所示。这里提示httpd.pid文件错误。熟悉Apache的读者应该知道，httpd.pid文件实际上是Apache的进程pid文件，用于存储Apache的启动进程ID。“Apache(20014)”错误02解决思路既然提示httpd.pid文件错误，那么查看这个文件是否存在及其内容即可。查看httpd.pid文件的操作命令如下：

linux:~#more/usr/local/apache2/logs/httpd.pid发现httpd.pid文件存在，但是内容为空，这里肯定存在问题。要解决这个问题，首先要了解Apache的启动机制及httpd.pid文件的作用。httpd.pid文件为文本文件，其中内容只有一行，记录了httpd进程的PID。通过cat命令可以查看httpd.pid文件的内容。通过这个httpd.pid文件可以防止进程启动多个副本。只有能够获得httpd.pid文件的进程才能正常启动并把自身的PID写入该文件，而同一个程序的多余进程则会自动退出。同时，httpd.pid文件在Apache正常启动时创建，在Apache正常关闭时自动删除。Apache在启动时会查找httpd.pid文件是否存在，如果该文件不存在，则创建此文件，将Apache启动的进程ID写入httpd.pid文件，并提示启动成功。如果该文件存在，但内容为空，则会出现“(20014)Internalerror”错误。在这个案例中，httpd.pid文件存在，但是内容为空，这可能是磁盘空间耗尽导致的，也可能是系统突然断电导致的。总之，导致这个问题的原因有很多种，这里不对其进行深究，因为我们的目的是找到解决问题的方法。“Apache(20014)”错误03解决方法解决这个问题有两种方法：一种方法是直接删除httpd.pid空文件，另一种方法是向httpd.pid文件中写入一个数字，操作命令如下：

linux:~#echo"28976">>/usr/local/apache2/logs/httpd.pid

linux:~#more/usr/local/apache2/logs/httpd.pid 28976再次启动Apache：

linux:~#/usr/local/apache2/bin/apachectlstart此时，Apache可以正常启动了。查看httpd.pid文件中的内容，具体如下：

linux:~#more/usr/local/apache2/logs/httpd.pid 7789由上述内容可以看出，Apache在成功启动后，自动获得了一个新的PID。进程之间即可使用这个PID进行通信。Apache在启动后，会保持这个PID不变，直到下次重新启动时才更新。“couldnotbindtoaddress:80”错误01问题现象客户的一台Web服务器是基于Apache+JK+Tomcat构建的一个电商平台。在更换硬件并重新启动后，客户反映Apache无法启动，但是Tomcat服务可以启动。启动Apache时的错误信息如图5-23所示。“couldnotbindtoaddress:80”错误02解决思路既然这个案例与端口相关，那么需要了解一下Linux系统中的端口。Linux系统中可用的端口范围是0～65535，可分为3类，分别是公认端口、注册端口和动态端口。公认端口的范围为0～1023，属于系统预留端口，主要用于绑定一些服务，如80端口绑定的是HTTP服务，21端口绑定的是ftp服务，22端口绑定的是SSHD服务等。对于公认端口，Linux系统做了一些安全限制，即普通用户无法绑定这类端口，只有root用户才能绑定和使用这类端口。注册端口的范围是1024～49151，主要用于分配给用户进程或应用程序。这些进程主要是用户自定义安装的应用程序。动态端口的范围是49152～65535。动态分配是指当一个系统进程或应用程序需要进行网络通信时，它会向主机申请一个端口；主机