CN106339285A - 一种linux系统意外重启的分析方法 - Google Patents
一种linux系统意外重启的分析方法 Download PDFInfo
- Publication number
- CN106339285A CN106339285A CN201610695628.7A CN201610695628A CN106339285A CN 106339285 A CN106339285 A CN 106339285A CN 201610695628 A CN201610695628 A CN 201610695628A CN 106339285 A CN106339285 A CN 106339285A
- Authority
- CN
- China
- Prior art keywords
- reason
- analysis
- restarted
- surprisingly
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2273—Test methods
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开一种LINUX系统意外重启的分析方法,涉及计算机操作系统技术领域,通过识别系统环境,查看分析系统日志,分析vmcore,检查硬件故障来定位Linux系统意外重启的具体原因,确定是用户行为导致的,还是软件层面的问题,亦或是硬件故障造成的。本发明为系统管理员、售后服务人员分析Linux系统意外重启提供指导,帮助用户快速准确的定位引起系统重启的根本原因,从而解决、彻底规避此类问题的发生,提高了服务器系统的安全性和稳定性。
Description
技术领域
本发明涉及计算机操作系统技术领域,具体的说是一种LINUX系统意外重启的分析方法。
背景技术
通常,在使用电脑的过程中会遇到各种各样的故障,机器意外重启就是其中之一。所谓意外重启,就是由于非操作员本身意愿而发生的电脑重新启动现象,引起这一故障的因素很多,如供电、资源冲突等。系统意外重启的原因主要包括,硬件质量、供电方面(欠压,过载,波动)、震动因素等硬件原因,以及系统不完善、DirectX因素、病毒等软件原因,还包括其他比如系统“瓶颈”、外界灰尘、散热不良等原因。
系统意外重启,是在服务器测试、生产环境中的一个常见的严重问题,尤其是对于生产环境,往往给客户造成重大损失。在发生系统意外重启后,如何快速准确的定位引起系统重启的根本原因,从而解决、彻底规避此类问题的发生,是客户、软硬件提供商、集成商最为关注的问题。
发明内容
本发明针对目前技术发展的需求和不足之处,提供一种ARM平台一种LINUX系统意外重启的分析方法。
本发明所述一种LINUX系统意外重启的分析方法,解决上述技术问题采用的技术方案如下:所述一种LINUX系统意外重启的分析方法,通过识别环境,查看日志,分析vmcore,检查硬件故障来定位Linux系统意外重启的具体原因,确定是用户行为导致的,还是软件层面的问题,亦或是硬件故障造成的;其具体包括如下步骤:1)首先识别系统环境,2)分析系统日志,3)通过vmcore分析原因,4)检查硬件故障。
优选的,所述识别系统环境这一步骤主要包括:
(1)检查问题机器是否是高可用集群中的一个节点,服务器是否配置了健康检查软件,以及服务器是否连接了BMC;并通过查看集群日志和硬件日志,判断否是由于集群软件调用:#echo b>/proc/sysrq-trigger或发送IPMI信号给BMC触发了重启操作,进而找到错误原因;
(2)检查系统软件情况,有哪些软件在执行什么任务,检查系统的负载和性能情况,并利用sysstat包提供的system Activity Reporter工具,判断是否由于CPU、内存、网络、磁盘负载过高导致系统重启。
优选的,所述分析系统日志这一步骤主要包括:(1)首先找到系统重启的位置,检查/var/log/messages,搜索关键字“Command line”,确定日志中记录的发生自动重启的位置及时间点;
(2)从找到的Kernel command line往前查找进一步确定原因。
优选的,所述通过vmcore分析原因这一步骤主要包括:首先检查是否配置了Kernel Panic,若没有配置kdump,进行kdump的配置;在系统再次发生重启后,生成vmcore文件,通过kerneloopsanalyzer工具对文件进行分析,或者通过命令分析原因。
优选的,所述检查硬件故障这一步骤主要包括:使用硬件诊断工具进行全面的硬件诊断。
本发明所述一种LINUX系统意外重启的分析方法与现有技术相比具有的有益效果是:本发明通过识别系统环境,分析系统日志,分析VMCore,检查硬件故障,定位Linux系统意外重启的具体原因,为系统管理员、售后服务人员分析Linux系统意外重启提供方法指导,使其快速准确的找到导致Linux系统意外重启的根本原因,并加以解决和规避,提高了服务器系统的安全性和稳定性。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,以下结合具体实施例,对本发明所述一种LINUX系统意外重启的分析方法进一步详细说明。
本发明所述一种LINUX系统意外重启的分析方法,通过识别环境,查看日志,分析vmcore,检查硬件故障来定位Linux系统意外重启的具体原因,确定是用户行为导致的,还是软件层面的问题,亦或是硬件故障造成的。本发明为系统管理员、售后服务人员分析Linux系统意外重启提供指导,帮助用户快速准确的定位引起系统重启的根本原因,从而解决、彻底规避此类问题的发生。
实施例:
本实施例一种LINUX系统意外重启的分析方法,针对部署了RedHat EnterpriseLinux,SUSE Linux Enterprise Server、Ubuntu、CentOS等Linux系统的服务器,提供了在发生意外重启后的分析查找根本原因的步骤及方法,使得相关人员能够快速准确的定位问题,找到造成系统意外重启的根本原因,从而解决、规避再次发生意外重启问题。
本实施例中,将造成系统意外重启的原因分为三类,主要包括:(一)、用户行为,比如用户关机命令、高可用fence event等;(二)软件错误,比如系统发生Kernel Panic,NMI等;(三)硬件故障,比如供电故障,磁盘或内存损坏等。
为了判断系统意外重启,具体是由于用户行为、软件错误还是硬件故障导致的,本实施例所述LINUX系统意外重启的分析方法,主要包括如下步骤:1)首先识别系统环境,2)分析系统日志,3)通过vmcore分析原因,4)排除以上故障后,检查硬件故障;通过以上步骤定位Linux系统意外重启的具体原因,确定是用户行为导致的,还是软件层面的问题,亦或是硬件故障造成的。
所述识别系统环境这一步骤主要包括:
(1)检查问题机器是否是高可用集群中的一个节点,服务器是否配置了健康检查软件,以及服务器是否连接了BMC;并通过查看集群日志和硬件日志,判断否是由于集群软件调用:#echo b>/proc/sysrq-trigger或发送IPMI信号给BMC触发了重启操作,进而找到错误原因;
很多集群软件,当检测到集群中一个节点发生错误/hang/不响应时会调用#echob>/proc/sysrq-trigger来重启机器;所以需要检查是否配置了sysrq键,#cat/proc/sys/kernel/sysrq值为1时,按下Alt+PrintScreen+b组合键或者#echo b>/proc/sysrq-trigger都会导致重启;因此检查是否有按下组合键或有类似的集群软件做了fencing;
有一些软件感知到性能问题时,就会发送IPMI信号给BMC来重启机器,比如hp-health package里面的Automated System Recovery(ASR);有一些集群软件,比如RHELHA,也会使用IPMI信号去fence不响应的节点,所以需要检查相关的硬件log和集群log来进一步查找原因;
(2)检查系统软件情况,有哪些软件在执行什么任务,检查系统的负载和性能情况,并利用sysstat包提供的system Activity Reporter工具,可以查询到CPU、内存、网络、磁盘、IO的分析数据,判断是否由于CPU、内存、网络、磁盘负载过高导致系统重启。
当以上分析不能确定原因时,通过查看系统日志,查看/var/log/messages可获知大部分的software faults(软件故障)。所述分析系统日志这一步骤主要包括:(1)首先找到系统重启的位置,检查/var/log/messages,搜索关键字“Command line”,确定日志中记录的发生自动重启的位置及时间点;比如找到如下内容,说明系统在9月29日04:18:15发生重启
Sep 29 04:18:15<hostname>kernel:Command line:ro root=LABEL=/rhgbquiet crashkernel=128M@16M
(2)从找到的Kernel command line往前查找,看是否有类似如下的信息,根据这些信息进一步确定原因:
shutdown:shutting down for system reboot
init:Switching to runlevel:6
exiting on signal 15
Got SIGTERM,quitting.
以上是用户发起的重启;
GAB WARNING V-15-1-20138Port h isolated due to client process failure
以上是Veritas集群高可用软件在检测到故障节点后,将故障节点踢出集群并重启故障;
fenced[xxxx]:fencing node"node1.example.com"
[TOTEM]A processor failed,forming new configuration.
[TOTEM]The token was lost in the OPERATIONAL state.
以上是RedHat HA高可用集群软件在检测到故障节点后,将故障节点踢出集群并重启故障;
CPU 1:Machine Check Exception:4Bank 4:ba00000000070f0f
Kernel panic-not syncing:Machine check
Kernel panic-not syncing:Uncorrected machine check
以上是硬件故障导致的系统重启;
kernel:CPUX:Temperature above threshold,cpu clock throttled
kernel:CPUX:Core power limit notification(total events=1)
Power Button Pressed
received event"button/power PWRF 00000000 00000000"
以上是服务器过热导致的重启,建议检查数据中心的制冷系统以及服务器的风扇;
kernel:Uhhuh.NMI received for unknown reason XX.
kernel:NMI received for unknown reason 00
kernel:Dazed and confused,but trying to continue
kernel:Do you have a strange power saving mode enabled?
以上是由于服务器硬件Non-Maskable Interrupt而导致的重启;
kernel:BUG:soft lockup-CPU#7stuck for 10s!
以上是由于软件错误导致的Kernel soft lockup
kernel:INFO:task<process>:60blocked for more than 120seconds.
以上是由于任务被堵塞导致的系统重启。
当通过查看/var/log/messages,仍然不能准确定位错误原因时,进行配置kdump,分析vmcore进一步确定原因。所述通过vmcore分析原因这一步骤主要包括:首先检查是否配置了Kernel Panic,#cat/proc/sys/kernel/panic若值为0,说明没有配置kdump,进行kdump的配置;在系统再次发生重启后,会生成vmcore文件,通过如下命令从vmcore文件中提取kernel log:#makedumpfile--dump-dmesg[path-to-vmcore][kernel-log-file],通过kerneloopsanalyzer工具对文件进行分析,或者通过命令分析原因。
当以上故障都排除,但仍未找到原因时,只能怀疑是硬件故障。所述检查硬件故障这一步骤主要包括:使用硬件诊断工具进行全面的硬件诊断,比如诊断主板,CPU、电源等是否坏掉。
本发明总结提炼出造成Linux系统意外重启的三类原因,并通过识别系统环境,分析系统日志,分析VMCore,检查硬件故障,为系统管理员、售后服务人员分析Linux系统意外重启提供指导,使其快速准确的定位问题,找到导致Linux系统意外重启的根本原因,并加以解决和规避。
上述具体实施方式仅是本发明的具体个案,本发明的专利保护范围包括但不限于上述具体实施方式,任何符合本发明的权利要求书的且任何所属技术领域的普通技术人员对其所做的适当变化或替换,皆应落入本发明的专利保护范围。
Claims (5)
1.一种LINUX系统意外重启的分析方法,其特征在于,通过识别环境,查看日志,分析vmcore,检查硬件故障来定位Linux系统意外重启的具体原因,确定是用户行为导致的,还是软件层面的问题,亦或是硬件故障造成的;其具体包括如下步骤:1)首先识别系统环境,2)分析系统日志,3)通过vmcore分析原因,4)检查硬件故障。
2.根据权利要求1所述一种LINUX系统意外重启的分析方法,其特征在于,所述识别系统环境这一步骤主要包括:
(1)检查问题机器是否是高可用集群中的一个节点,服务器是否配置了健康检查软件,以及服务器是否连接了BMC;并通过查看集群日志和硬件日志,判断否是由于集群软件调用:#echo b>/proc/sysrq-trigger或发送IPMI信号给BMC触发了重启操作,进而找到错误原因;
(2)检查系统软件情况,有哪些软件在执行什么任务,检查系统的负载和性能情况,并利用sysstat包提供的system Activity Reporter工具,判断是否由于CPU、内存、网络、磁盘负载过高导致系统重启。
3.根据权利要求2所述一种LINUX系统意外重启的分析方法,其特征在于,所述分析系统日志这一步骤主要包括:
(1)首先找到系统重启的位置,检查/var/log/messages,搜索关键字“Command line”,确定日志中记录的发生自动重启的位置及时间点;
(2)从找到的Kernel command line往前查找进一步确定原因。
4.根据权利要求3所述一种LINUX系统意外重启的分析方法,其特征在于,所述通过vmcore分析原因这一步骤主要包括:首先检查是否配置了Kernel Panic,若没有配置kdump,进行kdump的配置;在系统再次发生重启后,生成vmcore文件,通过kerneloopsanalyzer工具对文件进行分析,或者通过命令分析原因。
5.根据权利要求4所述一种LINUX系统意外重启的分析方法,其特征在于,所述检查硬件故障这一步骤主要包括:使用硬件诊断工具进行全面的硬件诊断。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610695628.7A CN106339285A (zh) | 2016-08-19 | 2016-08-19 | 一种linux系统意外重启的分析方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610695628.7A CN106339285A (zh) | 2016-08-19 | 2016-08-19 | 一种linux系统意外重启的分析方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106339285A true CN106339285A (zh) | 2017-01-18 |
Family
ID=57825060
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610695628.7A Pending CN106339285A (zh) | 2016-08-19 | 2016-08-19 | 一种linux系统意外重启的分析方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106339285A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112650610A (zh) * | 2020-12-11 | 2021-04-13 | 苏州浪潮智能科技有限公司 | 一种Linux系统崩溃控制方法、系统及介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102929747A (zh) * | 2012-11-05 | 2013-02-13 | 中标软件有限公司 | 基于龙芯服务器的Linux操作系统崩溃转储的处理方法 |
CN103198000A (zh) * | 2013-04-02 | 2013-07-10 | 浪潮电子信息产业股份有限公司 | 一种linux系统下的故障内存位置定位方法 |
CN103226510A (zh) * | 2013-04-27 | 2013-07-31 | 华为技术有限公司 | 解析vmcore文件的方法和装置 |
CN103593387A (zh) * | 2012-08-17 | 2014-02-19 | 国际商业机器公司 | 在多个阶段高效地存储和检索数据和元数据的方法和系统 |
CN103809989A (zh) * | 2012-11-08 | 2014-05-21 | 英华达(南京)科技有限公司 | 操作系统发生核心崩溃情况下读取完整核心日志的方法 |
CN103942113A (zh) * | 2013-11-21 | 2014-07-23 | 小米科技有限责任公司 | 系统重启原因的检测方法、装置及终端设备 |
-
2016
- 2016-08-19 CN CN201610695628.7A patent/CN106339285A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103593387A (zh) * | 2012-08-17 | 2014-02-19 | 国际商业机器公司 | 在多个阶段高效地存储和检索数据和元数据的方法和系统 |
CN102929747A (zh) * | 2012-11-05 | 2013-02-13 | 中标软件有限公司 | 基于龙芯服务器的Linux操作系统崩溃转储的处理方法 |
CN103809989A (zh) * | 2012-11-08 | 2014-05-21 | 英华达(南京)科技有限公司 | 操作系统发生核心崩溃情况下读取完整核心日志的方法 |
CN103198000A (zh) * | 2013-04-02 | 2013-07-10 | 浪潮电子信息产业股份有限公司 | 一种linux系统下的故障内存位置定位方法 |
CN103226510A (zh) * | 2013-04-27 | 2013-07-31 | 华为技术有限公司 | 解析vmcore文件的方法和装置 |
CN103942113A (zh) * | 2013-11-21 | 2014-07-23 | 小米科技有限责任公司 | 系统重启原因的检测方法、装置及终端设备 |
Non-Patent Citations (2)
Title |
---|
DAJKUUWVH 等: "什么情况下CPU会自动复位", 《HTTPS://WENWEN.SOGOU.COM/Z/Q550992035.HTM》 * |
解涛: "Linux 操作系统崩溃故障基础分析", 《科技风》 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112650610A (zh) * | 2020-12-11 | 2021-04-13 | 苏州浪潮智能科技有限公司 | 一种Linux系统崩溃控制方法、系统及介质 |
CN112650610B (zh) * | 2020-12-11 | 2023-01-10 | 苏州浪潮智能科技有限公司 | 一种Linux系统崩溃控制方法、系统及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3121726B1 (en) | Fault processing method, related device and computer | |
KR102268355B1 (ko) | 클라우드 배치 기반구조 검증 엔진 | |
US7607043B2 (en) | Analysis of mutually exclusive conflicts among redundant devices | |
WO2020024376A1 (zh) | 一种处理运维监控告警的方法及设备 | |
CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
EP2518627B1 (en) | Partial fault processing method in computer system | |
CN105677500A (zh) | 一种实时服务器故障诊断的方法 | |
EP3591485B1 (en) | Method and device for monitoring for equipment failure | |
WO2016188100A1 (zh) | 信息系统故障场景信息收集方法及系统 | |
US20080140895A1 (en) | Systems and Arrangements for Interrupt Management in a Processing Environment | |
US11853150B2 (en) | Method and device for detecting memory downgrade error | |
US20030084376A1 (en) | Software crash event analysis method and system | |
CN104320308A (zh) | 一种服务器异常检测的方法及装置 | |
Simache et al. | Event log based dependability analysis of windows nt and 2k systems | |
US20080288828A1 (en) | structures for interrupt management in a processing environment | |
CN108762886A (zh) | 虚拟机的故障检测恢复方法及系统 | |
CN103995759B (zh) | 基于核内外协同的高可用计算机系统故障处理方法及装置 | |
Li et al. | Going through the life cycle of faults in clouds: Guidelines on fault handling | |
CN106339285A (zh) | 一种linux系统意外重启的分析方法 | |
CN113868001B (zh) | 一种内存修复结果的检查方法、系统及计算机存储介质 | |
CN114217925A (zh) | 一种实现异常自动重启的业务程序运行监控方法及系统 | |
CN113742120A (zh) | 一种kdump触发方法、系统、设备以及介质 | |
CN113342596A (zh) | 一种设备指标的分布式监控方法、系统及装置 | |
CN111752741A (zh) | 一种系统性能检测的方法及装置 | |
CN116414609A (zh) | 故障分析方法、装置、电子设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170118 |