在运维的世界里,服务器的稳定运行是生命的灯塔,一旦遭遇异常重启,便是暴风雨来临的预兆。作为一名运维工程师,深知在这场与故障斗争的战役中,武器的锋利至关重要。今天,我要介绍的主角/工具——kdump,正是这样一款能在风雨来临之际,为我们捕获那一闪而过的真相的工具。
解决每一类问题都需要消耗大量的时间,特别是重新编译内核这种事情。于是,每一个Linux内核程序员或多或少都会掌握一些Hack技巧,以节省时间提高工作效率。
KDUMP是Linux内核中的一项关键功能,用于在系统崩溃时生成内存转储(core dump)。这对于系统管理员和开发人员来说,分析和调试系统崩溃问题至关重要。本文将详细介绍KDUMP的工作原理、配置方法以及在实际操作中的应用。
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers,Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是,依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题,这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具,掌握 crash 的使用技巧,对于分析定位内核崩溃的问题,有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法,其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件,包括各种常用调试命令的使用方法,最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中,既有详细的工具使用方法,又有丰富的实际案例分析,相信您读过以后定会受益匪浅。
前言: GuestOS中如果发生了一些错误,GuestOS还活着,shell已经hung住了,如何获取到GuestOS中的关键log信息呢? 分析: 1,keyboard interrupt QE
本文主要介绍kdump服务和crash的使用,并结合一个简单的实例演示如何分析内核奔溃的原因。本文基于linux kernel 4.19, 体系结构为aarch64。 kdump概述 kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制,用来捕获kernel crash(内核崩溃)的时候产生的crash dump。当内核产生错误时,kdump会将内存导出为vmcore保存到磁盘。 kdump流程 当系统崩溃时,kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核,以
本文一是为了讨论在Linux系统出现问题时我们能够借助哪些工具去协助分析,二是讨论出现问题时大致的可能点以及思路,三是希望能给应用层开发团队介绍一些Linux内核机制从而选择更合适的使用策略。
前文《[linux][qemu]PVPanic的实现原理以及应用》中,介绍了pvpanic的原理和基本的使用方法,KVM虚拟化场景下,使用pvpanic驱动可以监控到Guest的panic。
Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
我们不久前定位了一个Linux内核bug,这个bug会影响所有在特权容器中启用了use-gss-proxy的Linux环境,表现为容器的网络命名空间(net namespace)无法彻底释放,导致容器终止后关联的虚拟网卡未能自动清除,运行时间长的机器上会观察到内存泄露。目前upstream还没有对这个bug的修复,我们内部已经做好了patch待测。 这个问题的定位过程很有借鉴价值,特此与大家分享。 【问题现象】 在k8s环境里,容器终止之后概率性地发生弹性网卡残留现象,而且只有privileged容器
Linux是一个通用操作系统。一个操作系统要负责任务调度、内存分配、处理外围设备I/O等操作。操作系统通常由内核(运行其他程序,管理像磁盘、打印机等硬件设备的核心程序)和系统程序(设备驱动、底层库、shell、服务程序等)两部分组成。
Linux 内核有个机制叫OOM killer(Out-Of-Memory killer),该机制会监控那些占用内存过大,尤其是瞬间很快消耗大量内存的进程,为了防止内存耗尽而内核会把该进程杀掉。
客户上云过程中将原有在数据中心自建kubernetes集群迁移至腾讯云TKE集群,迁移过程中发现其中有一个容器沙箱环境频繁出现node节点夯死现象,目前已经出现5-6次,亟需定位原因。出现异常时节点无法登陆且需要手动重启才能恢复,"罪犯"逃离,异常后节点状态置为NotReady,无状态化pods会自动驱逐至其他节点,有状态化StatefullSets部署的pods无法驱逐成功。
值此七夕佳节,烟哥放弃了无数妹纸的邀约,坐在电脑面前码字,就是为了给读者带来新的知识,这是一件伟大的事业! 好吧,实际情况是没人约。为了化解尴尬,我决定卖力写文章,嗯,一定是我过于屌丝! 好了,开始说重点。今天讲的这个问题
日志从最初面向人类演变到现在的面向机器发生了巨大的变化。最初的日志主要的消费者是软件工程师,他们通过读取日志来排查问题,如今,大量机器日夜处理日志数据以生成可读性的报告以此来帮助人类做出决策。在这个转变的过程中,日志采集Agent在其中扮演着重要的角色。
最近有个客户报了一个问题:如果运行我们的产品,则每天将会增长大概30M的内存,大概4个多月内存就会耗尽。和大多数程序员的反应一样,“不会吧,在其他客户机器上都跑的好好的啊,从来都没有遇到过这样的问题”。最后的结果,也往往告诉程序员一个铁的事实:你的程序确实出问题了!
如果我们想注入一个Rootkit到内核,同时不想被侦测到,那么我们需要做的是精妙的隐藏,并保持低调静悄悄,这个话题我已经谈过了,诸如进程摘链,TCP链接摘链潜伏等等,详情参见:https://blog.csdn.net/dog250/article/details/105371830
思路:内核timer有回调函数timer->function,可以由function查到crash的内核模块,找到bug的蛛丝马迹。
王竞原,负责网游刀锋铁骑项目,高级开发工程师,使用C++已有10年,非常喜欢C++,特别是C++11。希望能与广大的C++爱好者多交流。 一、什么是Android的C/C++ NativeCrash Android上的Crash可以分两种: 1、Java Crash java代码导致jvm退出,弹出“程序已经崩溃”的对话框,最终用户点击关闭后进程退出。 Logcat 会在“AndroidRuntime”tag下输出Java的调用栈。 2、Native Crash 通过NDK,使用C/C++开发,导致
简单来讲,/dev/mem是系统物理内存的映像文件,这里的 “物理内存” 需要进一步解释。
在上一篇文章中,我们简要地解析了 eBPF 内核独立子系统的基本概念、发展历史、架构模型以及优缺点等,具体可参考:Linux eBPF解析。
这段代码非常简单,就是先用mmap的方式,为该进程分配10GiB的虚拟内存,然后再用page写的方式,让操作系统为这10GiB虚拟内存,分配对应的物理内存,最后sleep,等待我们测试。
线上某个kafka集群由于种种原因,从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看,排除其他客观因素,置换后,CPU总核数少了一半,使用率上升其实也是预期之内的。事实上置换后,集群CPU使用率确实也由原有的 20%提升至 40%,上升了约 1 倍多。但置换后,cpu sys使用率均值约达到了 12%,较为抢眼,系统相关服务却并无异常,令人有些困惑。
Kdump是在系统崩溃、死锁或死机时用来转储内存运行参数的一个工具和服务,是一种新的crash dump捕获机制,用来捕获kernel crash(内核崩溃)的时候产生的crash dump。在第一kernel在运行的时候,系统内部在内存中就已经留存好了给第二kernel(捕获内核)的预留空间(这个预留空间的大小可以自己设定)。在第一kernelcrash的时候,就会进入第二kernel,在第二kernel中执行用户态程序makedumpfile对第一kernel的内存镜像进行裁剪和压缩,最后将第一kernel的vmcore保留在磁盘中并重启。
前文《[x86][linux]AVX512指令引起的进程crash》中,介绍了一次因为avx512指令导致的进程crash。
Cgorup文档: https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
libvirt是一个通用的虚拟化框架,支持xen,kvm,lxc多种虚拟化技术,本文作为一个笔记。
情况是这样的,有一套测试数据库所在的主机在最近几个月,每个月都会重启一至两次,由于数据库配置了开机自启动,且每次重启时间都比较短暂,便没有得到重视。最近由于测试人员的反馈,每当主机重启后呢会导致大片的测试应用由于断连导致无法使用,每次都需要重启应用才会好。那么我们就需要介入认真排查一下问题所在了,恰巧最近一次的重启时间为 11 月 10 日 18:29 左右,需要针对此问题分析 os 重启原因。
公司介绍 遇贤微电子始创于2020年,团队云集了CPU产业专家及技术骨干,致力于为中国市场提供国产云计算高性能CPU芯片,拉动国内云计算架构CPU切换趋势。产品基于ARM架构,采用先进制程技术,自研部分核心IP,与客户软件生态协同发展,具备一流竞争力。 初创公司+ 软件部现在由CEO直接领导负责 = 待遇没有天花板 Linux 内核工程师 工作地: 上海/深圳/西安 岗位职责: 负责针对需求定制Linux内核,结合业务需求移植、开发内核新功能; 负责对crash等疑难问题分析定位; 负责对Linux内核进行
有客户反馈机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
有客户机器频繁出现重启,查看每次的堆栈都是virtio_check_driver_offered_feature访问非法地址的gpf报错,比较像是某个内核bug导致。
GDB(GNU Debugger)是Linux上的调试程序,可用于C/C++、Go、Rust等多种语言。GDB可以让你在被调试程序执行时看到它的”内部“情况,观察程序在特定断点上的状态,并逐行运行代码。
注:本问题影响 3.10.0-862.el7.centos 及之后的 CentOS 7 版本内核,目前问题还未被修复。
一、背景 在Android平台,native crash一直是crash里的大头。native crash具有上下文不全、出错信息模糊、难以捕捉等特点,比java crash更难修复。所以一个合格的异常捕获组件也要能达到以下目的: 支持在crash时进行更多扩展操作,如: 打印logcat和应用日志 上报crash次数 对不同的crash做不同的恢复措施 可以针对业务不断改进和适应 二、现有的方案 其实3个方案在Android平台的实现原理都是基本一致的,综合考虑,可以基于coffeecatch改进。
网上看到一个很有意思的美团面试题:为什么线程崩溃崩溃不会导致 JVM 崩溃,这个问题我看了不少回答,但发现都没答到根上,所以决定答一答,相信大家看完肯定会有收获,本文分以下几节来探讨
日志重要性 Linux系统日志对管理员来说,是了解系统运行的主要途径,因此需要对 Linux 日志系统有个详细的了解。 Linux 系统内核和许多程序会产生各种错误信息、告警信息和其他的提示信息,这些各种信息都应该记录到日志文件中,完成这个过程的程序就是 rsyslog,rsyslog 可以根据日志的类别和优先级将日志保存到不同的文件中。 二、日志系统rsyslog 日志管理基础 rsyslog 日志管理 logrotate日志轮转 一、处理日志的进程 rsyslogd:绝大部分日志记录,和系统操作
| 导语 企鹅FM近几个版本的外网Crash出现很多OutOfMemory(以下简称OOM)问题,Crash的堆栈都在Thread::start方法上。该文详细分析了发生原因。 ---- 有两种栈: 出现次数最多的一种,称之为 堆栈A。 java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory java.lang.Thread.nativeCreate(Native Method)
青囊,喜欢运动T恤加皮裤的非典型程序猿。此时,他正目不转睛注视着屏幕上一行行的代码,内存泄漏这个问题已经让他茶饭不思两三天了,任凭偌大的雨滴捶打着窗户也无动于衷。就这么静悄悄地过了一会儿,突然间,他哼着熟悉的小曲,仿佛一切来的又那么轻松又惬意。
本文介绍了如何使用Windows系统自带的WinDbg工具进行蓝屏死机(BSOD)故障排查和调试。通过介绍WinDbg工具的常见命令和功能,以及实际案例分析,帮助读者掌握如何利用WinDbg工具进行蓝屏死机故障的排除和调试。
ceph Vol 45 Issue 3 1.Crash in ceph_readdir. Hello, I’ve been investigating the following crash with cephfs: ··· According to the state of the ceph_inoide_info this means that ceph_dir_is_complete_ordered would return true and the second condition should a
查看栈信息内核是由于访问了非法地址ffff9d713fffffff触发了异常重启:
今天讲的是纯干货,目的就是为了指导Android开发者如何根据JNI Crash日志顺藤摸瓜,最后直捣黄龙定位磨人的JNI Crash。所以废话不多,直接开干吧。
kdump.conf 配置文件里的coredump存储目录,确认目录位置和目录的空间(或目录所在的挂载点文件系统可用空间)
在之前的一篇博文<<Linux Kernel模块内存泄露的一种查找思路>>中,我介绍了一种查找内核内存泄露的一种方法。这不才几个月,又有客户埋怨:使用了产品5天左右后,Suse服务器由于内存耗尽而Crash。O My God,不会吧,在我机器上跑的好好的哇(程序员常用名言 嘿嘿)。 那么就让我们一起来看看,苦逼的博主是如何确定问题并且找到问题的....
虽然你的网站是可以运行了,但想要网站 7*24 小时高可用不掉线,还远远不够,因为互联网还有一个看不见的手——入侵者。
Fuse有两部分组成:fuse驱动和用户态的daemon.fuse驱动是由内核的fuse设备驱动(/dev/fuse),这个字符设备驱动充当代理,针对不同的文件系统实现提供kernel和用户态daemon的通信桥梁;用户态daemon是从/dev/fuse设备读取,然后处理这些请求,最后把处理的就结果写回到/dev/fuse设备。
在启动一个Springboot工程时,抛出一项“Cannot allocate memory”异常,很明显,是因为内存分配原因导致的OOM异常导致JVM宕掉。跟随log,查看JVM hs_err_pid24442.log文件。
领取专属 10元无门槛券
手把手带您无忧上云