【Linux】Sudo的隐晦bug引发的一次业务问题排查

news2025/7/14 18:31:31

Sudo的隐晦bug引发的一次业务问题排查

  • 写在前面
  • 问题描述
  • 问题排查
    • 高负载现象排查
    • 日志排查
    • 跟踪任务调度过程
    • Sudo引发的问题
    • 手动复现
  • 问题分析
  • 处理方案

写在前面

记录一次生产环境sudo启动进程频繁被Kill且不报错的异常处理过程，如果遇到同样的问题只想要解决方案，直接跳到处理方案部分即可。

问题描述

这次记录一个比较特殊的问题，先说一下这次的环境情况，大数据底座使用的是Ambari管理的HDP-3.1.5.0-152，在上面部署的二开后的Dolphinscheduler调度服务，操作系统版本是Centos7(对应版本7.6.1810)。

接下来说下问题现象，运维日常巡检应该是没有去查看任务运行的情况，只是看看数据的输入输出，然后前两天客户投诉了项目，项目上也一直没查到问题，运维这个时候去看了任务执行的情况，发现存在大量任务的状态为Kill：

在这里插入图片描述
这个表现，第一印象就是是不是任务上Yarn被干掉了，但是同时期去查了Yarn的任务记录，并没有任何被Kill的任务：

在这里插入图片描述

于是就怀疑是Dolphinscheduler自己杀的任务，项目就安排调度的二开团队上来排查；查了一段时间，开发人员看到日志有大量报负载高的日志，所以认为是服务器负载过高导致的问题，关键日志如下：

[WARN] 2023-03-07 00:31:38.841 org.apache.dolphinscheduler.server.master.dispatch.host.LowerWeightHostManager:[163] - load is too high or availablePhysicalMemorySize(G) is too low, it's availablePhysicalMemorySize(G):247.3,loadAvg:100.42
[WARN] 2023-03-07 00:31:43.842 org.apache.dolphinscheduler.server.master.dispatch.host.LowerWeightHostManager:[163] - load is too high or availablePhysicalMemorySize(G) is too low, it's availablePhysicalMemorySize(G):247.3,loadAvg:100.42
[WARN] 2023-03-07 00:31:48.843 org.apache.dolphinscheduler.server.master.dispatch.host.LowerWeightHostManager:[163] - load is too high or availablePhysicalMemorySize(G) is too low, it's availablePhysicalMemorySize(G):247.46,loadAvg:125.33

这确实也是怀疑方向，随后项目上的维护人员也尝试降低机器负载，减少资源占用之类的方法，不过都没改观这个问题，同事就来找我，看看我有什么头绪。

问题排查

高负载现象排查

接下来说说我的整体排查和定位过程，首先是针对开发人员推断的负载高导致的问题进行了排查，确实存在负载很高的问题，但是和Kill的发生时间无法吻合，不过既然存在这个问题也要稍微排查和处理下，经过定位，发现是客户部署的监控agent有问题，启动大量的线程并且挂死，把负载拉高了，那么先把这部分僵尸进程干掉：
在这里插入图片描述
随着负载降低下来，问题依旧存在：
在这里插入图片描述

日志排查

基本可以确认开发所说的机器负载导致的问题是站不住脚的，Worker日志中还是大量任务被Kill的记录：

[INFO] 2023-03-07 00:35:14.961 org.apache.dolphinscheduler.server.worker.runner.TaskExecuteThread:[151] - task instance id : 1707926,task final status : KILL，exitStatusCode：137
[INFO] 2023-03-07 00:35:14.961 org.apache.dolphinscheduler.server.worker.runner.TaskExecuteThread:[163] - ========任务执行完成，准备发送任务状态，退出状态码137

这里从日志出发，KILL任务的退出码是137，在这一点的认知上，很多人存在误区，这个状态码是由128+9的来的，含义就是程序接受到了一个信号，信号值为9，而9我们都知道代表的信号是SIGKILL。

退出码137很多人以为就代表内存OOM，由内核Kill，这个是误区，一个进程被内核oomkill他的退出状态码确实是137，但是其他发送SIGKILL信号的行为也会表现为退出状态码137，这个Reddit上有个老哥说过：
Article needs correcting. 137 isn't some magic shorthand for out of memory. An exit code of 128+n means the process received signal number n and exited because of it. 137=128+9, signal 9 is SIGKILL. SIGKILL can be sent due to failing liveness probes.

OK，言归正传，这里我去和研发也核实了Dolphinscheduler的逻辑，他们确认不会是Dolphinscheduler自己发动的kill动作，那么我也就不再Dolphinscheduler上继续深入，我去操作系统日志找找头绪，很遗憾，在/var/log/message中也没找到什么有价值的东西；

跟踪任务调度过程

现在因为没有头绪，我决定找一个失败任务来看看执行了哪些命令，以及失败的命令是什么，这个可以在Dolphinscheduler的任务提交日志里找到相关信息:

[INFO] 2023-03-07 10:30:14.824  - [taskAppId=TASK-20230307-228-321408-1714904]:[299] - task run command:
sudo -u root sh /tmp/dolphinscheduler/exec/process/20230307/44/228/321408/1714904/228_321408_1714904.command
[INFO] 2023-03-07 10:30:14.826  - [taskAppId=TASK-20230307-228-321408-1714904]:[193] - process start, process id is: 11958
[INFO] 2023-03-07 10:30:15.562  - [taskAppId=TASK-20230307-228-321408-1714904]:[204] - process has exited, execute path:/tmp/dolphinscheduler/exec/process/20230307/44/228/321408/1714904, processId:11958 ,exitStatusCode:137
[INFO] 2023-03-07 10:30:16.533  - [taskAppId=TASK-20230307-228-321408-1714904]:[138] -  -> ${SPARK_HOME2}/bin/spark-submit --name fact_pm_nr_cellcu_v2_h .....

这里其实可以看到 ，进程启动后，不到一秒的时间久退出了，并且没有任何提交的信息，正常来说，至少会有打印一些Yarn任务的提交信息，比如相关文件的上传，kerberos认证后的连接信息等，这里都没有，也就是说进程已启动就被干掉了，这基本也能排除是Dolphinscheduler自己把它干掉的情况。

接下来我把相关的执行命令粘出来，自己手动跑了一遍，任务不光能执行，还能成功：
在这里插入图片描述

实际上到这里问题已经陷入了僵局，直到研发哥们阴差阳错做的一个操作帮我找到了新的契机。

Sudo引发的问题

接近晚上19点的时候，我由上环境看了下，任务依旧被Kill，没啥变化貌似：

在这里插入图片描述
不对，我又仔细翻看了几页，在16:40以后，图中标记的226服务器就没有任务被Kill了，难道研发已经找到问题了？本着学习的态度，去和他们团队的维护人员沟通了解情况，但他们说只改了堆内存，没有动别的东西：

在这里插入图片描述
我之前已经说过这个和资源没有关系，所以我当即是认为肯定有别的东西发生改动，这个时候我想到，Dolphinscheduler在提交任务的时候，使用的是sudo -u切换root进行的，会不会是和这个有关系，于是我马上去查看了sudo的记录日志，默认一般在/var/log/secure，这下我终于找到了一些端倪，首先这是16:40以及之前的sudo记录：

Mar  7 16:40:32 sudo: dolphinscheduler : PWD=/tmp/dolphinscheduler/exec/process/20230307/43/377/322266/1721369 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/377/322266/1721369/377_322266_1721369.command
Mar  7 16:40:33 sudo: dolphinscheduler : PWD=/tmp/dolphinscheduler/exec/process/20230307/43/377/322261/1721374 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/377/322261/1721374/377_322261_1721374.command
Mar  7 16:40:34 sudo: dolphinscheduler : PWD=/tmp/dolphinscheduler/exec/process/20230307/43/377/322278/1721383 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/377/322278/1721383/377_322278_1721383.command
Mar  7 16:40:34 sudo: dolphinscheduler : PWD=/tmp/dolphinscheduler/exec/process/20230307/43/377/322255/1721380 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/377/322255/1721380/377_322255_1721380.command

这是16:40之后的sudo记录日志：

Mar  7 16:49:46 sudo:    root : TTY=pts/6 ; PWD=/tmp/dolphinscheduler/exec/process/20230307/43/381/322310/1721636 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/381/322310/1721636/381_322310_1721636.command
Mar  7 16:49:46 sudo:    root : TTY=pts/6 ; PWD=/tmp/dolphinscheduler/exec/process/20230307/43/381/322322/1721648 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/381/322322/1721648/381_322322_1721648.command
Mar  7 16:49:47 sudo:    root : TTY=pts/6 ; PWD=/tmp/dolphinscheduler/exec/process/20230307/43/381/322312/1721638 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/381/322312/1721638/381_322312_1721638.command
Mar  7 16:49:47 sudo:    root : TTY=pts/6 ; PWD=/tmp/dolphinscheduler/exec/process/20230307/43/381/322324/1721650 ; USER=root ; COMMAND=/bin/sh /tmp/dolphinscheduler/exec/process/20230307/43/381/322324/1721650/381_322324_1721650.command

执行sudo的用户变了，由原先的dolphinscheduler用户变成了root，这个区别就大了，root直接执行sudo并不会发生任何多余的事情，也就相当于直接使用root执行命令。

为了确认我的推测，我继续去核实研发人员是否改过执行用户等配置，才知道他们调整过配置以后，是通过后台启动的服务，而没有使用Ambari重启，这就导致启动用户变成了root，所以sudo用户变成了root，至此我大概确认问题是由sudo导致的，接下来就是佐证。

手动复现

主要目的是为了捕捉sudo的问题，也要尽可能模拟生产环境的操作，那么久手动写一个command的命令集：

#!/bin/sh
BASEDIR=$(cd `dirname $0`; pwd)
cd $BASEDIR
source ${DOLPHINSCHEDULER_HOME}/bin/dolphinscheduler_env.sh
kinit -k -t /etc/security/keytabs/hdfs.headless.keytab user@BIGDATA.COM || true
${SPARK_HOME2}/bin/spark-submit --version

尝试循环去运行这个命令：

for i in {1..10};do sudo -u root sh /tmp/test.command ;done

很快就看见了sudo启动的命令被Killed了：
在这里插入图片描述
板上钉钉，sudo确实是概率性的触发这个进程被Kill的问题。

问题分析

现在我们找到了问题的诱因，但是sudo为什么会概率性的触发这个问题呢，我接下来查了很多资料，google、Bing都没找到，最后尝试去sudo的github页去搜issues，终于找到了：

Issue-117：Sudo responds with “killed”
在这里插入图片描述
提出者遇到的现象和我们一致，甚至sudo的版本都和我们的相近，我的是1.9.6p1，根据issue的描述，这个问题是sudo在低内核版本下导致的，centos7是3.10的内核，sudo调用到的一个getentropy方法是在3.17引入的，所以使用sudo的时候概率性的会触发这个问题：

在这里插入图片描述
调用的位置是arc4random.c：

static void
_rs_stir(void)
{
        unsigned char rnd[KEYSZ + IVSZ];

        if (getentropy(rnd, sizeof rnd) == -1)
        		// 这里传递了SIGKILL信号
                raise(SIGKILL);

        if (!rs_initialized) {
                rs_initialized = 1;
                _rs_init(rnd, sizeof(rnd));
        } else
                _rs_rekey(rnd, sizeof(rnd));
        explicit_bzero(rnd, sizeof(rnd)); /* discard source seed */

        /* invalidate rs_buf */
        rs_have = 0;
        memset(rs_buf, 0, sizeof(rs_buf));

        rs_count = 1600000;
}

开发者提交了一个commit来规避这个低版本内核导致的问题，commit
在这里插入图片描述

处理方案

现在问题已经明朗，具体的解决方案大致有3中：

  1. 不使用其他用户sudo，直接root，这对于很多生产环境显然不允许；
  2. 重新编译安装sudo命令，1.8.31-1.9.8的版本在编译的时候需要增加ac_cv_func_getentropy=no环境变量；
  3. 升级sudo命令到1.9.9及以上版本；

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

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

相关文章

AWS攻略——初识流量镜像

AWS攻略——初识流量镜像

在实际应用场景下，我们可能需要建立一个测试环境，既能接线上流量，又不希望影响线上业务，这个时候流量镜像就派上用场。它会将一个网络接口中的流量复制到另外一个网络接口中，然后在后者上分发，而前者不受影…
阅读更多...
AQS 源码解读

AQS 源码解读

一、AQS AQS 是 AbstractQueuedSynchronizer 的简称，又称为同步阻塞队列，是 Java 中的一个抽象类。在其内部维护了一个由双向链表实现的 FIFO 线程等待队列，同时又提供和维护了一个共享资源 state ，像我们平常使用的 ReentrantLo…
阅读更多...
OpenCV-PyQT项目实战（12）项目案例08：多线程视频播放

OpenCV-PyQT项目实战（12）项目案例08：多线程视频播放

欢迎关注『OpenCV-PyQT项目实战 Youcans』系列，持续更新中 OpenCV-PyQT项目实战（1）安装与环境配置 OpenCV-PyQT项目实战（2）QtDesigner 和 PyUIC 快速入门 OpenCV-PyQT项目实战（3）信号与槽机制 …
阅读更多...
配置Clion用于STM23开发（Makefile）

配置Clion用于STM23开发（Makefile）

前言 对于Clion配置STM32开发环境的教程在网上一搜一大堆，但是大部分都是22年之前的，使用的方法都是在STM32CubeMX生成SW4STM32工程。但是在22年不知道哪个版本后，CubeMX已经不再支持生成SW4STM32工程了，这也是我本人遇到的问题。…
阅读更多...
10 Wifi网络的封装

10 Wifi网络的封装

概述 Wifi有多种工作模式，比如：STA模式、AccessPoint模式、Monitor模式、Ad-hoc模式、Mesh模式等。但在IPC设备上，主要使用STA和AccessPoint这两种模式。下面分别进行介绍。 STA模式：任何一种无线网卡都可以运行在此模式，这种模式也是无线网卡的默认模式。在此模式下，无线…
阅读更多...
【算法】图的存储和遍历

【算法】图的存储和遍历

作者：指针不指南吗 专栏：算法篇 🐾或许会很慢，但是不可以停下🐾 文章目录1. 图的存储1.1 邻接矩阵1.2 邻接表2. 图的遍历2.1 dfs 遍历2.2 bfs 遍历1. 图的存储 引入 一般来说，树和图有两种存储方式&#…
阅读更多...
【Java】Mybatis查询数据库

【Java】Mybatis查询数据库

文章目录MyBatis查询数据库1. MyBatis 是什么？2. 为什么要学习MyBatis？3. 怎么学MyBatis？4. 第一个MyBatis查询4.1 创建数据库和表4.2 添加MyBatis框架支持4.3 配置连接字符串和MyBatis4.3.1 配置连接数据库配置MyBatis中的XML路径4.4 添加业…
阅读更多...
宝刀未老？VB语言迎来春天，低代码绝地逢生，程序员能淡定吗？

宝刀未老？VB语言迎来春天，低代码绝地逢生，程序员能淡定吗？

一、VB语言迎来春天 “VB语言过时了，早就淘汰了”，不少程序员认为，如今VB上不了台面。 有人说：VB是被微软砍掉的优秀产品之一，当年还和Delphi打对台来着, 那时候真的是如日中天！ 颠覆许多人认知的是28年过…
阅读更多...
postgre8.3跨平台升级大版本的一些问题以及解决方式

postgre8.3跨平台升级大版本的一些问题以及解决方式

背景： 因服务器升级（Windows Server 2012-> 2019）,服务器非直接版本升级，而是从一台2012直接移植到2019，考虑到以后可能还会升级更高版本，因此postgre8.3版本需要升级到新版本，当前时间postg…
阅读更多...
知识蒸馏论文阅读：DKD算法笔记

知识蒸馏论文阅读：DKD算法笔记

标题：Decoupled Knowledge Distillation 会议：CVPR2022 论文地址：https://ieeexplore.ieee.org/document/9879819/ 官方代码：https://github.com/megvii-research/mdistiller 作者单位：旷视科技、早稻田大学、清华大学…
阅读更多...
SpringCloud （Eureka服务注册、发现）

SpringCloud （Eureka服务注册、发现）

本章导学： 微服务各个服务如何调用？服务直接调用出现的问题Eureka的引出及其作用搭建单机Eureka 注册发现一、微服务各个服务之间的调用 很简单，我们只需要在SpringBoot的配置类里把RestTemplate类加载到容器，利用RestTemplate的…
阅读更多...
【目标检测 DETR】通俗理解 End-to-End Object Detection with Transformers，值得一品。

【目标检测 DETR】通俗理解 End-to-End Object Detection with Transformers，值得一品。

文章目录DETR1. 亮点工作1.1 E to E1.2 self-attention1.3 引入位置嵌入向量1.4 消除了候选框生成阶段2. Set Prediction2.1 N个对象2.2 Hungarian algorithm3. 实例剖析4. 代码4.1 配置文件4.1.1 数据集的类别数4.1.2 训练集和验证集的路径4.1.3 图片的大小4.1.4 训练时的批量…
阅读更多...
idea 2022.2.4 导入依赖警告的问题

idea 2022.2.4 导入依赖警告的问题

在我导入依赖的时候，pom文件提示警告如下信息 Provides transitive vulnerable dependency commons-collections:commons-collections:3.2.2 Cx78f40514-81ff 7.5 Uncontrolled Recursion vulnerability pending CVSS allocation Results powered by Checkmarx(c) …
阅读更多...
第十二章：网络编程

第十二章：网络编程

第十二章：网络编程 12.1：网络编程概述 ​ Java是Internet上的语言，它从语言级上提供了对网络应用程序的支持，程序员能够很容易开发常见的网络应用程序。 ​ Java提供的网络类库，可以实现无痛的网络连接，…
阅读更多...
【项目精选】基于struts+hibernate的采购管理系统

【项目精选】基于struts+hibernate的采购管理系统

点击下载 javaEE采购管理系统 本系统是一个独立的系统，用来解决企业采购信息的管理问题。采用JSP技术构建了一个有效而且实用的企业采购信息管理平台，目的是为高效地完成对企业采购信息的管理。经过 对课题的深入分析，采购系统需实现以下功能…
阅读更多...
秒懂算法 | DP概述和常见DP面试题

秒懂算法 | DP概述和常见DP面试题

动态（DP）是一种算法技术，它将大问题分解为更简单的子问题，对整体问题的最优解决方案取决于子问题的最优解决方案。本篇内容介绍了DP的概念和基本操作；DP的设计、方程推导、记忆化编码、递推编码、滚动数组以及常见的DP面试题。 01、DP概述 1. DP问题的特征 下面以斐波那…
阅读更多...
在找docker命令和部署？看这一篇文章就够了。

在找docker命令和部署？看这一篇文章就够了。

一、docker 常用命令 docker ps -a #查看所有容器 docker images #查看所有images docker search rabbitmq #搜索rabbitmq docker pull rabbitmq #拉去rabbitmq docker run -id --namemy_rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq # 创建一个容器并启动 docker exec -it…
阅读更多...
数据结构算法学习记录——线性表之单链表(上)-初始单链表及其头插函数（顺序表缺陷、单链表优点、链表打印）

数据结构算法学习记录——线性表之单链表(上)-初始单链表及其头插函数（顺序表缺陷、单链表优点、链表打印）

单链表的概念单链表是一种链式存取的数据结构，链表中的数据是以结点来表示的。每个结点的构成：元素(数据元素的映象) 指针(指示后继元素存储位置)。元素就是存储数据的存储单元，指针就是连接每个结点的地址数据。以“结点的序列”表示的线性…
阅读更多...
Ubuntu安装Docker

Ubuntu安装Docker

一、安装条件1.操作系统要求需要以下 Ubuntu 版本之一的 64 位版本：Ubuntu Kinetic 22.10Ubuntu Jammy 22.04 (LTS)Ubuntu Focal 20.04 (LTS)Ubuntu Bionic 18.04 (LTS)二、安装1.要是之前安装过，可以进行卸载然后再安装，旧版本的 Docker 的名…
阅读更多...
_Linux (传输层一版本)

_Linux (传输层一版本)

文章目录0. 传输层作用1. 再谈端口号1-1 端口号范围划分1-2 认识知名端口号(Well-Know Port Number)1-3 两个问题1-4 netstat1-5 pidof2. UDP协议2-1 UDP协议端格式1. UDP协议如何分离（封装）？2. UDP协议如何交付（应用层- - 客户&a…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023