[deadlock]死锁导致的设备登录无响应问题

news2024/10/24 15:25:27

[deadlock]死锁导致的设备登录无响应问题

  • 一、问题现象
  • 二、初步观察
  • 三、继续深挖
    • 查看netlink相关信息
    • 查看warnd进程栈
  • 四、再接再厉
    • 查看warnd 用户栈
  • 后记

一、问题现象

实验室一台压力测试设备突然无法登录，无论web页面，ssh或者telnet登录，都是输入用户名密码后卡在哪里，无法进入管理页面。
如果这样子的话，根本无法调试。幸运的是，有个之前就打开的shell窗口可以使用。这给我们分析调试提供了方便。

二、初步观察

在shell中查看现存和hang住的命令行进程，看看有什么线索。

/var/log# ps | grep cli
 2812 root      720m S    cli admin 1 admin telnet(10.10.20.11)
15126 root      720m S    cli admin 1 admin telnet(10.10.20.11)
15264 root      720m S    cli admin 0 admin console
21947 root     16448 S    grep cli

这里有3个cli进程，有除了2812是我们当前在使用的，剩下两个都是无响应的。查看进程的内核栈信息。

/var/log# cat /proc/15264/stack
[<ffffffff8080a819>] netlink_attachskb+0x189/0x1d0
[<ffffffff8080a991>] netlink_unicast+0xa1/0x1f0
[<ffffffff8080ad81>] netlink_sendmsg+0x1c1/0x3e0
[<ffffffff80799b8a>] sock_sendmsg+0x1a/0x30
[<ffffffff8079a376>] ___sys_sendmsg+0x1e6/0x200
[<ffffffff8079b404>] SyS_sendmsg+0x44/0x80
[<ffffffff802016d5>] do_syscall_64+0x75/0x2c0
[<ffffffff80c0008d>] entry_SYSCALL_64_after_hwframe+0x59/0xbe
[<ffffffffffffffff>] 0xffffffffffffffff
/var/log# cat /proc/15126/stack
[<ffffffff8080a819>] netlink_attachskb+0x189/0x1d0
[<ffffffff8080a991>] netlink_unicast+0xa1/0x1f0
[<ffffffff8080ad81>] netlink_sendmsg+0x1c1/0x3e0
[<ffffffff80799b8a>] sock_sendmsg+0x1a/0x30
[<ffffffff8079a376>] ___sys_sendmsg+0x1e6/0x200
[<ffffffff8079b404>] SyS_sendmsg+0x44/0x80
[<ffffffff802016d5>] do_syscall_64+0x75/0x2c0
[<ffffffff80c0008d>] entry_SYSCALL_64_after_hwframe+0x59/0xbe
[<ffffffffffffffff>] 0xffffffffffffffff
/var/log# cat /proc/2812/stack
[<ffffffff80255f6a>] do_wait+0x1aa/0x210
[<ffffffff802570f7>] kernel_wait4+0x97/0x120
[<ffffffff802571ef>] SyS_wait4+0x6f/0x80
[<ffffffff802016d5>] do_syscall_64+0x75/0x2c0
[<ffffffff80c0008d>] entry_SYSCALL_64_after_hwframe+0x59/0xbe
[<ffffffffffffffff>] 0xffffffffffffffff

可以发现 15126和15264进程都卡在了 netlink发送等待上。怀疑netlink socket收包队列有积压，导致发送端处于等待发送状态。

三、继续深挖

查看netlink相关信息

/var/log# cat /proc/net/netlink 
sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks     Drops     Inode
ffff88880b2cb000 0   2851   00000000 0        0        0 2        0        12002   
ffff888806d6e800 0   2707076566 00000000 0        0        0 2        0        12784   
ffff888806d6a000 0   3780   00000551 0        0        0 2        0        12810   
ffff88885a980000 0   0      00000000 0        0        0 2        0        3       
ffff88880a1b6000 0   2825818928 00000111 0        0        0 2        0        20919   
ffff888806d6d800 0   3498   00000111 0        0        0 2        0        12783   
ffff88880c210000 0   3410172620 00000000 0        0        0 2        0        12811   
ffff88880b2cb800 0   2855   00000001 0        0        0 2        0        11851   
ffff88880a5bf800 15  10000038 00000000 33557184 0        0 27       0        1652  --问题socket
//省略部分无关socket

发现socket ffff88880a5bf800 存在大量积压，基本确认是积压导致。

根据Eth 15 和Pid 10000038 ，对照代码发现是发送和接收告警信息的socket，负责接收处理的进程是warnd。

查看warnd进程栈

/var/log# ps | grep warnd
 2849 root     2325m S    /bin/warnd
22135 root     16448 S    grep warnd
/var/log# cat /proc/2849/stack
[<ffffffff802bfe03>] futex_wait_queue_me+0xc3/0x120
[<ffffffff802c01e2>] futex_wait+0x102/0x230
[<ffffffff802c275e>] do_futex+0x14e/0xc30
[<ffffffff802c32ab>] SyS_futex+0x6b/0x140
[<ffffffff802016d5>] do_syscall_64+0x75/0x2c0
[<ffffffff80c0008d>] entry_SYSCALL_64_a

发现warnd在等待futex 锁，是那个操作导致的呢，这就需要查看用户态的调用栈了。

四、再接再厉

查看warnd 用户栈

用gdb attach上warnd进程，查看当前栈

/var/log# gdb
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
//省略无关部分
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) attach 2849
Attaching to process 2849
[New LWP 2945]
[New LWP 2946]
[New LWP 2947]
//省略无关部分
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
0x00007fcab97e4059 in ?? () from /lib/libc.so.6
(gdb) info thread
  Id   Target Id                                 Frame 
* 1    Thread 0x7fcab8929800 (LWP 2849) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  2    Thread 0x7fcab8924640 (LWP 2945) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  3    Thread 0x7fcab8123640 (LWP 2946) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  4    Thread 0x7fcab7922640 (LWP 2947) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
//省略无关部分
  34   Thread 0x7fcaa802b640 (LWP 8217) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  35   Thread 0x7fcaa782a640 (LWP 8238) "warnd" 0x00007fcab9868add in sendmsg () from /lib/libc.so.6
  36   Thread 0x7fcaa7029640 (LWP 8245) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  37   Thread 0x7fcaa611f640 (LWP 8260) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  38   Thread 0x7fcaa590d640 (LWP 8267) "warnd" 0x00007fcab97e4059 in ?? () from /lib/libc.so.6
  39   Thread 0x7fcaa510c640 (LWP 8268) "warnd" 0x00007fcab9867196 in epoll_wait () from /lib/libc.so.6

除了线程35和39外，其他线程全部卡在相同的位置。

查看线程1，可以知道系统调用线程读写锁的写锁时因为得不到调度进入了休眠。那么这个锁被那个线程占有了呢？

(gdb) thread 1
[Switching to thread 1 (Thread 0x7fcab8929800 (LWP 2849))]
#0  0x00007fcab97e4059 in ?? () from /lib/libc.so.6
(gdb) bt full
#0  0x00007fcab97e4059 in ?? () from /lib/libc.so.6
No symbol table info available.
#1  0x00007fcab97ed4f1 in pthread_rwlock_wrlock () from /lib/libc.so.6
No symbol table info available.
#2  0x000000000040d5d3 in ?? ()
No symbol table info available.
#3  0x0000000000404ad9 in ?? ()
No symbol table info available.
#4  0x00007fcab978b1f7 in ?? () from /lib/libc.so.6
No symbol table info available.
#5  0x00007fcab978b2ac in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000404b01 in ?? ()
No symbol table info available.

我们再查看看35线程。通过查看代码发现，在sendmsg之前，线程已经持通过pthread_rwlock_wrlock 持有了写锁。也就是其他线程都在等待35线程释放写锁。那么35线程为什么不释放写锁呢？

  (gdb) thread 35
[Switching to thread 35 (Thread 0x7fcaa782a640 (LWP 8238))]
#0  0x00007fcab9868add in sendmsg () from /lib/libc.so.6
(gdb) bt full
#0  0x00007fcab9868add in sendmsg () from /lib/libc.so.6
No symbol table info available.
#1  0x00007fcab967f81d in fun_nl_sendto0 () from /lib/libfun_nl_ipc.so
No symbol table info available.
#2  0x00007fcab9b2a61a in send_warn () from /lib/libwarnapi.so
No symbol table info available.
#3  0x00000000004159d0 in ?? ()
No symbol table info available.
#4  0x0000000000415dbc in ?? ()
No symbol table info available.
#5  0x000000000040c9c5 in ?? ()
No symbol table info available.
#6  0x00007fcab9b62067 in ?? () from /lib/libevent.so
No symbol table info available.
#7  0x00007fcab9b62314 in ?? () from /lib/libevent.so
No symbol table info available.
#8  0x00007fcab9b62568 in ?? () from /lib/libevent.so
No symbol table info available.
#9  0x000000000040ca8e in ?? ()
No symbol table info available.
#10 0x00007fcab97e731a in ?? () from /lib/libc.so.6
No symbol table info available.
#11 0x00007fcab9866db0 in clone () from /lib/libc.so.6

查代码发现35线程sendmsg就是向 已经积压的netlink socket 发送warn消息。因为netlink socket积压，导致35线程进入休眠等待。

分析到这里，基本逻辑差不多通顺了。

  1. 压力测试导致netlink socket积压
  2. 35线程获取写锁后，向netlink socket发送消息。因为积压导致休眠。
  3. 其他线程包括netlink socket消息接受处理的线程因为获取不到写锁，导致休眠。
  4. 此时：线程35发送消息持有写锁，等待netlink socket buffer空闲。处理netlink socket消息的线程，等待写锁。–根因
  5. cli命令行进程会向warnd发送netlink消息，因为netlink socket消息积压(消息没有得到及时处理)，导致发送进程进入等待休眠。

后记

warnd进程主要处理其他进程发来的warn消息，自己也发送warn消息。在锁的处理上不够完善，导致压力测试下，socket接收队列打满后，形成了死锁。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2222500.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

【升华】一文从0到1到实际性应用大语言模型（LLM）

【升华】一文从0到1到实际性应用大语言模型（LLM）

一、前言 相信网已经很多LLM大模型 的介绍 &#xff0c;概念&#xff0c;发展历史&#xff0c;应用场景的很多文章&#xff0c;但是很多文章都是缺少细节的描述&#xff0c;到底怎么用&#xff0c;需要些什么东西怎么层显出来。所以虽然看了很多大模型的介绍&#xff0c;也仅仅…
阅读更多...
【Linux篇】初学Linux，如何快速搭建Linux开发环境

【Linux篇】初学Linux，如何快速搭建Linux开发环境

文章目录 前言1. Linux背景介绍1.1 UNIX的发展历史1.2 Linux的发展历史 2. 企业应用现状3. 开源3.1 探索Linux源代码3.2 开源 VS 闭源 4. Linux的版本4.1 技术线4.2 商业产品线 5. os概念&#xff0c;定位6. 搭建Linux环境6.1 Linux环境的搭建方式6.2 购买云服务器 7. 使用XShe…
阅读更多...
从一个简单的计算问题，看国内几个大语言模型推理逻辑能力

从一个简单的计算问题，看国内几个大语言模型推理逻辑能力

引言 首先&#xff0c;来看问题&#xff1a; 123456*987654等于多少&#xff0c;给出你计算的过程。 从openai推出chatgpt以来&#xff0c;大模型发展的很快&#xff0c;笔者也经常使用免费的大语言模型辅助进行文档编写和编码工作。大模型推出时间也好久了&#xff0c;笔者想…
阅读更多...
红队-安全见闻篇(上)

红队-安全见闻篇(上)

声明 学习视频来自B站UP主 泷羽sec的个人空间-泷羽sec个人主页-哔哩哔哩视频,如涉及侵权马上删除文章 笔记的只是方便各位师傅学习知识,以下网站只涉及学习内容,其他的都与本人无关,切莫逾越法律红线,否则后果自负 一.编程与开发 1.后端语言学习 C语⾔&#xff1a;⼀种通⽤的…
阅读更多...
[解决]在Arduino IDE 打开 ino 类型文件处于read only editor模式

[解决]在Arduino IDE 打开 ino 类型文件处于read only editor模式

今天打开一个ino类型文件发现这个问题&#xff0c;无法编辑…… 解决方法&#xff1a;右键点击ino类型文件&#xff08;你打开的那个&#xff09;进入属性栏 发现只读被勾上&#xff0c;取消打勾并点击最下方的确认 现在就可以编辑啦
阅读更多...
Unity目录居然这么写就不会被引入到项目内

Unity目录居然这么写就不会被引入到项目内

只要加一个小符号~ 这是一个约定俗成的符号么~~~~ 当然&#xff0c;代码管理器还是识别的 也&#xff0c;只要稍微加一些规则&#xff0c;去避免代码入库 只要一天不死&#xff0c;还是能在程序员这个座位上看到新的东西 什么时候才到尽头&#xff1f;&#xff1f;&#xff1f…
阅读更多...
服务器数据恢复—EXT3文件系统下邮件数据被误删的数据恢复案例

服务器数据恢复—EXT3文件系统下邮件数据被误删的数据恢复案例

服务器数据恢复环境&#xff1a; 邮件服务器中有一组由8块盘组成的RAID5阵列, 上层是Linux操作系统EXT3文件系统。 服务器故障&#xff1a; 由于误删除导致文件系统中的邮件数据丢失。 服务器数据恢复过程&#xff1a; 1、将故障服务器中所有硬盘做好标记后取出&#xff0c;硬…
阅读更多...
面试必备：RabbitMQ与Kafka核心知识点总结

面试必备：RabbitMQ与Kafka核心知识点总结

写在前面 &#x1f525;我把后端Java面试题做了一个汇总&#xff0c;有兴趣大家可以看看&#xff01;这里&#x1f449; ⭐️在无数次的复习巩固中&#xff0c;我逐渐意识到一个问题&#xff1a;面对同样的面试题目&#xff0c;不同的资料来源往往给出了五花八门的解释&#…
阅读更多...
Windows电脑怎么设置局域网内共享磁盘？

Windows电脑怎么设置局域网内共享磁盘？

一、设置局域网磁盘共享 1、假设这是电脑A&#xff0c;先启动公用文件夹共享&#xff1a; &#xff08;1&#xff09;点击【控制面板】 &#xff08;2&#xff09;点击【网络和Internet】 &#xff08;3&#xff09;点击【网络和共享中心】 &#xff08;4&#xff09;点击【…
阅读更多...
【linux网络编程】 | 网络基础Ⅰ| 认识网络

【linux网络编程】 | 网络基础Ⅰ| 认识网络

前言: 在本节几乎不讲任何网络协议的系结&#xff0c; 只是将网络的概念搭建起来。本节将会讲到网络的一些专有名词&#xff0c; 概念&#xff0c; 以及网络的结构划分等等。 主要是带大家做一下前期知识的铺垫。 下面&#xff0c; 开始我们的学习吧&#xff01; ps:本节内容因…
阅读更多...
成功解决pycharm软件中按住Ctrl+点击指定函数却不能跳转到对应库中的源代码

成功解决pycharm软件中按住Ctrl+点击指定函数却不能跳转到对应库中的源代码

成功解决pycharm软件中按住Ctrl点击指定函数却不能跳转到对应库中的源代码 目录 解决问题 解决方法 解决问题 在pycharm软件中按住Ctrl点击指定函数却不能跳转到对应库中的源代码 解决方法
阅读更多...
docker容器无法连接宿主机mysql排查

docker容器无法连接宿主机mysql排查

1、docker无法访问宿主机 在docker容器内&#xff0c;需要访问当前docker容器的网关&#xff0c;例如172.xx.0.1&#xff0c;即可访问宿主机&#xff0c;因此需要保证docker的网络配置正确 查看当前docker容器的网关&#xff1a; docker inspect 你的容器名或者容器id 显示…
阅读更多...
《深度学习》 了解YOLO基本知识

《深度学习》 了解YOLO基本知识

目录 一、关于YOLO 1、什么是YOLO 2、经典的检测方法 1&#xff09;one-stage单阶段检测 模型指标介绍&#xff1a; 2&#xff09;two-stage多阶段检测 二、关于mAP指标 1、概念 2、IOU 3、关于召回率和准确率 4、示例 5、计算mAP 一、关于YOLO 1、什么是YOLO YOL…
阅读更多...
图的最小生成树算法--普里姆（Prim）算法和克鲁斯克尔（Kruskal）算法

图的最小生成树算法--普里姆（Prim）算法和克鲁斯克尔（Kruskal）算法

一、图的最小生成树 最小生成树&#xff08;Minimum spanning tree&#xff0c;MST&#xff09;是最小权重生成树&#xff08;Minimum weight spanning tree&#xff09;的简称&#xff0c;是一个连通加权无向图中一棵权值最小的生成树。 在一给定的无向图 G ( V , E ) G …
阅读更多...
Bug：通过反射修改@Autowired注入Bean的字段，明确存在，报错 NoSuchFieldException

Bug：通过反射修改@Autowired注入Bean的字段，明确存在，报错 NoSuchFieldException

【BUG】通过Autowired注入了一个Bean SeqNo&#xff0c;测试的时候需要修改其中的字段。通过传统的反射&#xff0c;无论如何都拿不到信息&#xff0c;关键是一方面可以通过IDEA跳转&#xff0c;一方面debug也确实能看到这个字段。但是每次调用set方法报错&#xff1a;NoSuchFi…
阅读更多...
C++ [项目] 愤怒的小鸟

C++ [项目] 愤怒的小鸟

现在才发现C游戏的支持率这么高&#xff0c;那就发几篇吧 零、前情提要 此篇为 制作,由于他没有CSDN,于是由我代发 一、基本介绍 支持Dev-C5.11版本(务必调为英文输入法),基本操作看游戏里的介绍,怎么做的……懒得说,能看懂就看注释,没有的自己猜,如果你很固执……私我吧 …
阅读更多...
伺服电动缸用途分析

伺服电动缸用途分析

力姆泰克伺服电动缸是一种先进的电动执行器&#xff0c;由伺服电动机和传动机构组成。它能够提供高精度的位置控制和力量输出&#xff0c;并具有快速响应和高重复性的特点。 力姆泰克伺服电动缸可广泛应用于自动化系统和机械设备中&#xff0c;例如工业机械、机床、自动化生产…
阅读更多...
什么是恶意爬虫，有什么应对措施

什么是恶意爬虫，有什么应对措施

在当今数字化时代&#xff0c;网络爬虫作为一种重要的数据收集工具&#xff0c;广泛应用于搜索引擎、数据分析、商业情报等领域。然而&#xff0c;恶意爬虫的出现&#xff0c;却给网站安全带来了前所未有的挑战。今天我们就来简单了解下什么是恶意爬虫&#xff0c;爬虫对网站的…
阅读更多...
npm install node-sass安装失败

npm install node-sass安装失败

需求&#xff1a;搭建前端开发环境时&#xff0c;npm install报错&#xff0c;错误提示安装node_modules时&#xff0c;node-sass依赖包安装失败&#xff0c;网上找了好久解决方法&#xff0c;大家提示采用淘宝源等方式安装&#xff0c;都失败了了&#xff0c;尝试了很久终于找…
阅读更多...
基于WIFI的智能台灯设计

基于WIFI的智能台灯设计

1系统整体设计 本次围绕LED台灯&#xff0c;来设计一款基于WIFI的智能台灯&#xff0c;结合STM32单片机和多种传感器来共同完成该设计&#xff0c;整个设计的主要功能如下&#xff1a; 1.有自动和手动模式&#xff0c;自动模式自动调节光强&#xff0c;手动模式即手动控制&am…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023