Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
最近客户的centos频繁重启,但是由于没有vmcore文件产生,但客户急于解决,无法等待vmcore,所以只能尝试从堆栈角度分析内核,找出问题的根由。
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具,掌握 crash 的使用技巧,对于分析定位内核崩溃的问题,有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法,其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件,包括各种常用调试命令的使用方法,最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中,既有详细的工具使用方法,又有丰富的实际案例分析,相信您读过以后定会受益匪浅。
Kdump是在系统崩溃、死锁或死机时用来转储内存运行参数的一个工具和服务,是一种新的crash dump捕获机制,用来捕获kernel crash(内核崩溃)的时候产生的crash dump。在第一kernel在运行的时候,系统内部在内存中就已经留存好了给第二kernel(捕获内核)的预留空间(这个预留空间的大小可以自己设定)。在第一kernelcrash的时候,就会进入第二kernel,在第二kernel中执行用户态程序makedumpfile对第一kernel的内存镜像进行裁剪和压缩,最后将第一kernel的vmcore保留在磁盘中并重启。
在客户使用我们产品后,发现一个问题:在删除了文件后,磁盘空间却没有释放。是有进程在打开这个文件,还是其他情况?我们一起来看看一下两个场景
作者简介:中年码农,做过电信、手机、安全、芯片等行业,靠Linux混饭吃。 简介 Kdump 提供了一种机制在内核出现故障的时候把系统的所有内存信息和寄存器信息 dump 出来成一个文件,后续通过 gdb/crash 等工具进行分析和调试。和用户态程序的 coredump 机制类似。它的主要流程如下图所示: 可以看到它的核心原理是保留一段内存并且预先加载了一个备用的 kernel,在主 kernel 出现故障时跳转到备用 kernel,在备用 kernel 中把主 kernel 使用的内存和发生故障时的寄
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers,Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是,依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题,这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
最近因为搭建scutosc的论坛,买了一台新的腾讯云的2核4G的服务器,但是开机后发现htop命令显示内存只有3.3G:
本文一是为了讨论在Linux系统出现问题时我们能够借助哪些工具去协助分析,二是讨论出现问题时大致的可能点以及思路,三是希望能给应用层开发团队介绍一些Linux内核机制从而选择更合适的使用策略。
注:本问题影响 3.10.0-862.el7.centos 及之后的 CentOS 7 版本内核,目前问题还未被修复。
系统崩溃,死机,卡顿等问题经常遇到,但又很棘手,这里推荐个分析神器,视频号里也做过类似的分析。 Crash 工具用于解析 kdump 抓取的 vmcore信息,如之前分析,vmcore 实际为系统运行当时的内存镜像,其中包括了所有的内存中可以看到的信息,通过 Crash 工具可以解析 vmcore 中的详细数据,本文主要以 sk_buff 数据结构为例简单说明 Crash 中间中对结构体的解析。 基本用法 Crash中使用struct命令解析结构体,具体用法为: [struct] <结构体名称> <结构体虚
本文主要介绍kdump服务和crash的使用,并结合一个简单的实例演示如何分析内核奔溃的原因。本文基于linux kernel 4.19, 体系结构为aarch64。 kdump概述 kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制,用来捕获kernel crash(内核崩溃)的时候产生的crash dump。当内核产生错误时,kdump会将内存导出为vmcore保存到磁盘。 kdump流程 当系统崩溃时,kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核,以
最近有个客户报了一个问题:如果运行我们的产品,则每天将会增长大概30M的内存,大概4个多月内存就会耗尽。和大多数程序员的反应一样,“不会吧,在其他客户机器上都跑的好好的啊,从来都没有遇到过这样的问题”。最后的结果,也往往告诉程序员一个铁的事实:你的程序确实出问题了!
程序向系统申请内存,使用完不需要之后,不释放内存还给系统回收,造成申请的内存被浪费.
crash 是 Linux 内核开发中流行的调试工具。特别是它提供了强大的使用搜索命令进行内存搜索的功能。但是,它有点不方便,因为在移动每个进程的调用堆栈时没有查看局部变量的功能。 应读者要求,这篇文章,我将介绍如何从 vmcore 中提取堆栈转储并将调用堆栈上传到 Trace32。 使用命令“./crash64 vmcore vmlinux”运行崩溃实用程序。 $./crash64 vmcore vmlinux ...... please wait... (gathering kmem slab cach
有客户机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
Oracle Linux 8.0 发布了,更新包中包括基础 BaseOS 和 Application Streams,其中 BaseOS 提供运行环境的用户空间,Application Streams 提供了一系列以往分发在软件集中的应用,以及可在用户空间内运行的其它产品和程序。
有客户反馈机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
“缺芯少魂”一直是我国信息产业发展的一大难题,而“少魂”就是指操作系统等基础软件薄弱。“拿来主义”这种传统解决方式在给我们带来便利的同时,也桎梏了我们的创新。腾讯的操作系统研发也走过了从拿来主义到创新研发的道路。云计算时代,操作系统向下适配多元化硬件,向上支撑多样化产品,其重要性不言而喻。让我们一起了解下腾讯操作系统的创新之路。
踏上 Linux 内核世界的探险将成为您职业生涯的一段迷人旅程。作为操作系统之心的 Linux 内核涵盖众多领域,如操作系统原理、硬件抽象以及驱动开发等。在这篇文章中,我们将一探 Linux 内核的奥秘,并为具备编程基础的技术人员提供一处学习起点。
PID: 31918 TASK: ffff8820117a8240 CPU: 10 COMMAND: "test_gifconf"
1,查看dmesg日志可以看到node在重启前确实出现频繁的cgroup oom:
网络信息产业中,芯片被比喻为心脏,操作系统被认为是计算机的灵魂。二十年来,国内信息产业始终在“缺芯少魂”的困境中,中国在高端芯片行业缺乏自主创新能力,国产操作系统自研创新,不仅事关信息技术核心竞争力,更关乎国家信息安全。
情况是这样的,有一套测试数据库所在的主机在最近几个月,每个月都会重启一至两次,由于数据库配置了开机自启动,且每次重启时间都比较短暂,便没有得到重视。最近由于测试人员的反馈,每当主机重启后呢会导致大片的测试应用由于断连导致无法使用,每次都需要重启应用才会好。那么我们就需要介入认真排查一下问题所在了,恰巧最近一次的重启时间为 11 月 10 日 18:29 左右,需要针对此问题分析 os 重启原因。
一、proc文件系统是什么? proc是一个伪文件系统,伪文件系统的定义: 它只存在内存当中,而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。用户和应用程序可以通过proc得到系统的信息,并可以改变内核的某些参数。由于系统的信息,如进程,是动态改变的,所以用户或应用程序读取proc文件时,proc文件系统是动态从系统内核读出所需信息并提交的。 我们常常用它来追踪进程的状态、内核的状态、内存信息、CPU使用率、系统启动时间(可以使用系统正常运行时间)等相应的信息; 二、proc文件系统详
客户上云过程中将原有在数据中心自建kubernetes集群迁移至腾讯云TKE集群,迁移过程中发现其中有一个容器沙箱环境频繁出现node节点夯死现象,目前已经出现5-6次,亟需定位原因。出现异常时节点无法登陆且需要手动重启才能恢复,"罪犯"逃离,异常后节点状态置为NotReady,无状态化pods会自动驱逐至其他节点,有状态化StatefullSets部署的pods无法驱逐成功。
CentOS 7 中执行:yum remove iptables 后,一般不会在意输出信息,不好意思,你错过了重点,输出信息中包含了如下一段内容:
最近对一个统计库做了计划内的容灾切换,即主备切换。操作的过程其实还是蛮顺利的。但是灾难切换中如果出现在问题,那就是灾难中的灾难了。 按照计划对配置信息做了同步,然后使用DG Broker做了SwitchOver操作。 这一次切换速度还是蛮快,我开了几个窗口看到日志都在不断输出,角色已经替换过来了。DG Broker切换的日志如下: DGMGRL> switchover to test29; Performing switchover NOW, please wait... New primary datab
Linux内核提供了一种通过/proc文件系统,在运行时访问内核内部数据结构、改变内核设置的机制。proc文件系统是一个伪文件系统,它只存在内存当中,而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。 用户和应用程序可以通过proc得到系统的信息,并可以改变内核的某些参数。由于系统的信息,如进程,是动态改变的,所以用户或应用程序读取proc文件时,proc文件系统是动态从系统内核读出所需信息并提交的。下面列出的这些文件或子文件夹,并不是都是在你的系统中存在,这取决于你的内核配置和装载的模块。另外,在/proc下还有三个很重要的目录:net,scsi和sys。 Sys目录是可写的,可以通过它来访问或修改内核的参数,而net和scsi则依赖于内核配置。例如,如果系统不支持scsi,scsi目录不存在。 除了以上介绍的这些,还有的是一些以数字命名的目录,它们是进程目录。系统中当前运行的每一个进程都有对应的一个目录在/proc下,以进程的 PID号为目录名,它们是读取进程信息的接口。而self目录则是读取进程本身的信息接口,是一个link。
KDUMP是Linux内核中的一项关键功能,用于在系统崩溃时生成内存转储(core dump)。这对于系统管理员和开发人员来说,分析和调试系统崩溃问题至关重要。本文将详细介绍KDUMP的工作原理、配置方法以及在实际操作中的应用。
1. /proc目录 Linux 内核提供了一种通过 /proc 文件系统,在运行时访问内核内部数据结构、改变内核设置的机制。proc文件系统是一个伪文件系统,它只存在内存当中,而不占用外存空间。它以文件系统的方式为访问系统内核数据的操作提供接口。
回顾上篇,解释了场景“2”中的四个标签,也介绍了对应着Windows Server中的四个功能在日常运维中究竟起到什么作用以及如何去驾驭他们。
由于早期的云服务器,大量存量3.10内核作为cvm的操作系统内核。3.10内核存在着很多已知问题,其中的常客之一便是内存不足场景下,内存回收引发的问题。 内存回收和OOM一直是Linux中一个饱受诟病的问题,其路径内核一直在优化,所以从理论上新版本内核一定是优于老版本。 本文通过构造用例测试,来针对3.10和5.4内核在内存不足场景下的表现进行分析对比,以说明5.4会在内存不足的场景下有更好的表现。
kdump.conf 配置文件里的coredump存储目录,确认目录位置和目录的空间(或目录所在的挂载点文件系统可用空间)
找出内存最大的几个进程(按名字统计,同名算一个,但是这么算出来的有可能加上了共享内存,不保证完全准确,要是想刨去共享内存一个办法就是统计时加上uniq): ps -G | sed 's/^>//' | awk '{ m[$9]+=$8/1024 } END { for (item in m) { printf "%20s %10s MiB\n", item, m[item] } }' | sort -k 2 -r -n | head
3.cat /etc/issue 或cat /etc/redhat-release(Linux查看版本当前操作系统发行版信息)
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \
Kubernetes(K8s)是一个开源容器编排系统,可自动执行应用程序部署、扩展和管理。它是云原生世界的操作系统。 K8s 或操作系统中的任何缺陷都可能使用户进程存在风险。作为 PingCAP EE(效率工程)团队,我们在 K8s 中测试 TiDB Operator(一个创建和管理 TiDB 集群的工具)时,发现了两个 Linux 内核错误。这些错误已经困扰我们很长一段时间,并没有在整个 K8s 社区中彻底修复。
简单来讲,/dev/mem是系统物理内存的映像文件,这里的 “物理内存” 需要进一步解释。
解决每一类问题都需要消耗大量的时间,特别是重新编译内核这种事情。于是,每一个Linux内核程序员或多或少都会掌握一些Hack技巧,以节省时间提高工作效率。
kconfig-hardened-check是一款功能强大的安全检测工具,可以帮助广大研究人员检测Linux内核中的安全增强选项。
修改CentOS7网卡名称为传统名称eth0格式 http://oldboy.blog.51cto.com/2561410/1722101
# define RWSEM_ACTIVE_MASK 0xffffffffL
使用tke的过程中,很多时候我们希望对容器内的一些内核参数进行优化修改,可以通过init容器或者securityContext来修改pod内的内核参数。
该问题,疑似rootkit或者哪个软件捆绑安装的模块(apache?),不过谷歌并搜不到相关信息。
在主机入侵检测系统里,也可以通过system, popen, fork/execv之类的函数调用如下命令实现上面目的
一台线上服务器在流量大时挂掉,怀疑是大流量时的抓包行为导致,向我们给出了线索是当时可能存在的三个抓包组件:A、B、C,当三个组件全部开启时,将流量打上去进行压测,很快会报soft lockup错误,且机器会非常卡。但是只开启一个组件压测,则并没有相关soft lockup报错。看现象似乎不符合逻辑?本文记录该问题的分析过程。
为什么cpu在内核收包时突然发生了异常,异常号是14,执行async_page_fault处理异常,处理异常时发现发现cr2中地址处于内核空间中,内核是不会发生page fault的,async_page_fault MMU会触发,kvm环境下kvm也会触发,那一定是kvm的问题了。
作者 | 王鑫 策划 | 王一鹏 审校 | 嘉洋 WebAssembly (简称 Wasm) 是目前备受关注的一门新的计算机语言,本演讲从计算机语言技术的角度解析 WebAssembly 的语言特性,以及 WebAssembly 为应用提供安全沙箱机制的原理。我们将介绍 WebAssembly 在浏览器以外的主要应用场景和其带来的价值,以及目前 W3C 正在定义中的一些主要特性及其对未来的影响。 本文整理自英特尔中国有限公司高级技术经理王鑫在 DIVE 全球基础软件创新大会 2022 的演讲分享,
领取专属 10元无门槛券
手把手带您无忧上云