AI 助理
备案控制台
开发者社区 微服务 文章 正文

运维排查 | Systemd 之服务停止后状态为 failed

2024-04-01 113
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云原生网关 MSE Higress，422元/月
注册配置 MSE Nacos/ZooKeeper，118元/月
服务治理 MSE Sentinel/OpenSergo，Agent数量 不受限
简介： 运维排查 | Systemd 之服务停止后状态为 failed

哈喽大家好，我是咸鱼。

我们知道 CentOS 7 之后，Systemd 代替了原来的 SystemV 来管理服务，相比 SystemV ，Systemd 能够很好地解决各个服务间的依赖关系，还能让所有的服务同时启动，而不是串行启动。

通常情况下，yum 安装的软件会由系统的包管理器（如 RPM）安装，并且会配置相应的 systemd 服务，因此由 systemd 来管理。然而，在一些情况下，特别是当采用源码编译安装软件或者软件本身并没有提供 systemd 管理的解决方案时，就需要手动编写 systemd 服务文件（service 文件）来管理这些软件。

那今天我们就来看看手动编写 systemd 服务文件来管理软件时发现的一些问题。

问题出现

我们的 zookeeper 是通过源码编译来安装，为了方便管理，决定改成通过 systemd 来管理。

下面是 zookeeper 的 service 文件

# zookeeper
[Unit]
Description=Zookeeper
After=network.target

[Service]
Type=forking
ExecStart=/opt/zookeeper/bin/zkServer.sh start
ExecStop=/opt/zookeeper/bin/zkServer.sh stop
PIDFile=/var/lib/zookeeper/zookeeper_server.pid

[Install]
WantedBy=multi-user.target

可以看到，配置文件分成几个区块，每个区块包含若干条键值对。

[Unit]

Unit 部分的 Description 字段给出当前服务的简单描述接下来的设置是启动顺序：

  1. After字段：表示 zookeeper.service 应该在哪些服务之后启动。
  2. Before字段，表示 zookeeper.service 应该在哪些服务之前启动。

注意，After和Before字段只涉及启动顺序，不涉及依赖关系。

[Service]

Service 部分定义如何启动当前服务。

  • ExecStart：启动进程时执行的命令。

  • ExecStop：停止服务时执行的命令。

  • Type：定义启动类型

    1. simple（默认值）：ExecStart字段启动的进程为主进程
    2. forking：ExecStart字段将以fork()方式启动，此时父进程将会退出，子进程将成为主进程
    3. oneshot：类似于simple，但只执行一次，Systemd 会等它执行完，才启动其他服务
    4. dbus：类似于simple，但会等待 D-Bus 信号后启动
    5. notify：类似于simple，启动结束后会发出通知信号，然后 Systemd 再启动其他服务
    6. idle：类似于simple，但是要等到其他任务都执行完，才会启动该服务。一种使用场合是为让该服务的输出，不与其他服务的输出相混合

[Install]

Install 部分定义如何安装这个配置文件，即怎样做到开机启动

  • WantedBy：表示该服务所在的 Target。

Target 的含义是服务组，表示一组服务。WantedBy=multi-user.target指的是，kafka 和 zookeeper 所在的 Target 是 multi-user.target。

这个设置非常重要，因为执行systemctl enable命令时，zookeeper .service 的一个符号链接，就会放在/etc/systemd/system目录下面的multi-user.target.wants子目录之中。

Systemd 有默认的启动 Target。

[root@localhost ~]# systemctl get-default
multi-user.target

上面的结果表示，默认的启动 Target 是 multi-user.target。在这个组里的所有服务，都将开机启动。这就是为什么 systemctl enable 命令能设置开机启动的原因。

编写好 service 文件之后，我们执行下面的命令来启动 zookeeper：

[root@localhost ~]# systemctl start zookeeper.service

接着看下 zookeeper 的运行状态

[root@localhost ~]# systemctl status zookeeper.service       
● zookeeper.service - Zookeeper
   Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; enabled; vendor preset: disabled)
   Active: active (running) since 一 2024-04-01 09:10:23 CST; 2s ago
  Process: 60955 ExecStop=/opt/zookeeper/bin/zkServer.sh stop (code=exited, status=0/SUCCESS)
  Process: 61116 ExecStart=/opt/zookeeper/bin/zkServer.sh start (code=exited, status=0/SUCCESS)
 Main PID: 61132 (java)
   CGroup: /system.slice/zookeeper.service
           └─61132 java -Dzookeeper.log.dir=/opt/zookeeper/bin/../logs -Dzookeeper.log.file=zookeeper--server-localhost.localdomain.log -Dzookeepe...

4月 01 09:10:22 localhost.localdomain systemd[1]: Starting Zookeeper...
4月 01 09:10:22 localhost.localdomain zkServer.sh[61116]: /usr/sbin/java
4月 01 09:10:22 localhost.localdomain zkServer.sh[61116]: ZooKeeper JMX enabled by default
4月 01 09:10:22 localhost.localdomain zkServer.sh[61116]: Using config: /opt/zookeeper/bin/../conf/zoo.cfg
4月 01 09:10:23 localhost.localdomain zkServer.sh[61116]: Starting zookeeper ... STARTED
4月 01 09:10:23 localhost.localdomain systemd[1]: Started Zookeeper.

active (running) 表示运行正常

当我们执行 systemctl stop zookeeper.service 命令停止 zookeeper 的时候，问题出现了

[root@localhost ~]# systemctl status zookeeper.service 
● zookeeper.service - Zookeeper
   Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 一 2024-04-01 09:10:30 CST; 906ms ago
  Process: 61183 ExecStop=/opt/zookeeper/bin/zkServer.sh stop (code=exited, status=0/SUCCESS)
  Process: 61116 ExecStart=/opt/zookeeper/bin/zkServer.sh start (code=exited, status=0/SUCCESS)
 Main PID: 61132 (code=exited, status=143)

4月 01 09:10:23 localhost.localdomain systemd[1]: Started Zookeeper.
4月 01 09:10:29 localhost.localdomain systemd[1]: Stopping Zookeeper...
4月 01 09:10:29 localhost.localdomain zkServer.sh[61183]: /usr/sbin/java
4月 01 09:10:29 localhost.localdomain zkServer.sh[61183]: ZooKeeper JMX enabled by default
4月 01 09:10:29 localhost.localdomain zkServer.sh[61183]: Using config: /opt/zookeeper/bin/../conf/zoo.cfg
4月 01 09:10:29 localhost.localdomain systemd[1]: zookeeper.service: main process exited, code=exited, status=143/n/a
4月 01 09:10:30 localhost.localdomain zkServer.sh[61183]: Stopping zookeeper ... STOPPED
4月 01 09:10:30 localhost.localdomain systemd[1]: Stopped Zookeeper.
4月 01 09:10:30 localhost.localdomain systemd[1]: Unit zookeeper.service entered failed state.
4月 01 09:10:30 localhost.localdomain systemd[1]: zookeeper.service failed.

可以看到，zookeeper 服务在停止后并不是 inactive ，而是 failed 状态，最后两行输出里有 Unit zookeeper.service entered failed state./zookeeper.service failed 字段

问题定位

我们接着看上面的输出，可以看到在设置了 Type=forking 后，服务在启动或关闭时执行对应的脚本会开启一个进程，并且两个进程都成功执行了（返回状态码为 0 ）。

  Process: 61183 ExecStop=/opt/zookeeper/bin/zkServer.sh stop (code=exited, status=0/SUCCESS)
  Process: 61116 ExecStart=/opt/zookeeper/bin/zkServer.sh start (code=exited, status=0/SUCCESS)
  Main PID: 61132 (code=exited, status=143)

但是主进程退出时返回的状态码却是 143，而不是状态码 0。

接着看下 zookeeper 进程还在不在：

[root@localhost ~]# jps -l
61287 sun.tools.jps.Jps

[root@localhost ~]# ps -ef | grep zookeeper
root      61300  61250  0 09:49 pts/0    00:00:00 grep --color=auto zookeeper

奇怪，明明 zookeeper 进程已经成功退出了，但是 systemd 却说它退出失败

此时我注意到尽管在停止服务时，状态码为 0，但也只是表明执行 /opt/zookeeper/bin/zkServer.sh stop 命令本身成功完成，这个状态码并不代表脚本内部的执行逻辑一定是成功的。

我们看下 zkServer.sh 脚本中关于 stop 的逻辑

stop)
    echo -n "Stopping zookeeper ... "
    if [ ! -f "$ZOOPIDFILE" ]
    then
      echo "no zookeeper to stop (could not find file $ZOOPIDFILE)"
    else
      $KILL  $(cat "$ZOOPIDFILE")
      rm "$ZOOPIDFILE"
      sleep 1
      echo STOPPED
    fi
    exit 0
    ;;

没有发现有什么不妥，接着我们注释掉 ExecStop 字段，采用 systemd 默认的方式来停止服务。

默认情况下，systemd 将向进程发送 SIGTERM 信号（相当于 kill 命令发送的终止信号），等待一段时间后，如果服务进程未正常退出，则发送 SIGKILL 信号（相当于 kill -9 命令发送的强制终止信号）强制终止服务进程。

然后重新启停一下 zookeeper ，看下状态：

[root@localhost ~]# systemctl status zookeeper.service 
● zookeeper.service - Zookeeper
   Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since 一 2024-04-01 10:03:04 CST; 1s ago
  Process: 61453 ExecStart=/opt/zookeeper/bin/zkServer.sh start (code=exited, status=0/SUCCESS)
 Main PID: 61469 (code=exited, status=143)

4月 01 10:02:55 localhost.localdomain systemd[1]: Started Zookeeper.
4月 01 10:02:55 localhost.localdomain zkServer.sh[61453]: /usr/sbin/java
4月 01 10:02:55 localhost.localdomain zkServer.sh[61453]: ZooKeeper JMX enabled by default
4月 01 10:02:55 localhost.localdomain zkServer.sh[61453]: Using config: /opt/zookeeper/bin/../conf/zoo.cfg
4月 01 10:02:56 localhost.localdomain zkServer.sh[61453]: Starting zookeeper ... STARTED
4月 01 10:03:04 localhost.localdomain systemd[1]: Stopping Zookeeper...
4月 01 10:03:04 localhost.localdomain systemd[1]: zookeeper.service: main process exited, code=exited, status=143/n/a
4月 01 10:03:04 localhost.localdomain systemd[1]: Stopped Zookeeper.
4月 01 10:03:04 localhost.localdomain systemd[1]: Unit zookeeper.service entered failed state.
4月 01 10:03:04 localhost.localdomain systemd[1]: zookeeper.service failed.

[root@localhost ~]# jps -l
61524 sun.tools.jps.Jps
[root@localhost ~]# ps -ef | grep zookeeper
root      61537  61250  0 10:04 pts/0    00:00:00 grep --color=auto zookeeper

还是一样的问题，zookeeper 已经成功退出但是却显示 failed 状态，状态码是 143。

从上面我们得知：无论是通过 zkserver.sh 还是 systemd 默认方式来关闭服务，本质上都是向 zookeeper 进程发送 SIGTERM 信号（数值为 15 ），虽然 zookeeper 进程成功退出，但是 systemd 将此解释为异常退出，因为预期的退出状态码为 0。

而根据 POSIX 规范：【因接收到信号而终止的命令的退出状态应报告为大于 128】，所以被信号中断的进程退出时会返回 128 加上信号数值作为退出状态码。

也就是说，当 zookeeper 进程收到 SIGTERM 信号时，会返回 128 + 15 也就是 143 作为退出状态码，这也就是为什么进程在成功退出后 systemctl 显示为 failed 状态。

解决问题

既然知道了进程在退出时的状态码是 143 但是 systemd 不会解释为成功，因为预期的退出状态码为 0，那么我们只需要让 systemd 把状态码 143 也解释为成功就行。

所以在 zookeeper 的 service 文件中添加下面的配置：

[Service]
...
SuccessExitStatus=143
...

表示当服务进程以状态码 143 正常退出时，systemd 将其视为成功退出而不是异常退出。

文章标签：
微服务引擎
运维
消息中间件
Linux
Kafka
关键词：
运维服务
运维systemd
运维排查
相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作，您将了解并实现在线业务的微服务全链路灰度能力。
咸鱼运维杂谈
目录
相关文章
IT技术分享社区
|
5月前
|
运维 监控 关系型数据库
运维实战：Windows服务挂掉了怎么办，通过Bat脚本实现自动重启
本文介绍了如何使用Bat脚本自动监控并重启Windows服务器上的挂掉服务，例如MySQL，以避免在假期等情况下需要紧急处理问题。首先，创建一个Bat脚本，设定每小时检查一次服务状态，如果服务停止则自动重启。脚本内容包括检查服务是否运行并根据状态执行相应操作。同时，脚本中包含了确保以管理员权限运行的代码。 脚本需设置为ANSI编码以防止乱码。推荐将Bat脚本封装为Windows服务以保证稳定运行，提供了使用NSSM工具、Windows服务程序和开源的Java工具winsw将批处理脚本转化为服务的方法。这些方法可以确保服务在后台可靠运行，即使在服务意外停止时也能自动恢复。
IT技术分享社区
644 2
叫个什么名字
|
3月前
|
机器学习/深度学习 存储 人工智能
智能化运维：构建未来IT服务的蓝图
在数字化浪潮的推动下，运维领域正经历一场革命性的变革。本文将探讨如何通过引入人工智能、机器学习等技术，实现运维工作的智能化，从而提高服务质量和效率。我们将一起探索智能运维的核心要素，包括自动化、实时监控、预测性维护和持续改进策略，并讨论这些技术如何塑造未来的IT服务。
叫个什么名字
59 1
呆呆宝
|
3月前
|
运维 Kubernetes Cloud Native
Kubernetes云原生问题之在托管Kubernetes服务中云服务商和用户的运维责任划分如何解决
Kubernetes云原生问题之在托管Kubernetes服务中云服务商和用户的运维责任划分如何解决
呆呆宝
38 0
游客qf4jmczx4xu2y
|
5月前
|
机器学习/深度学习 数据采集 人工智能
智能运维：AI在现代IT服务管理中的应用
【6月更文挑战第17天】随着人工智能技术的不断进步，智能运维已成为提升IT服务效率和质量的关键手段。本文将探讨如何通过集成机器学习、大数据分析等技术来优化传统运维流程，实现故障预测、自动化处理及持续的性能优化，旨在为IT专业人士提供实施智能运维的洞见与策略。
游客qf4jmczx4xu2y
429 5
游客qf4jmczx4xu2y
|
5月前
|
机器学习/深度学习 存储 人工智能
智能化运维：未来的IT服务管理
【6月更文挑战第14天】本文将探讨智能化运维的概念、优势以及在IT服务管理中的应用。随着人工智能和机器学习技术的发展，智能化运维已经成为了IT服务管理的新趋势。通过引入智能化运维，企业可以提高效率、降低成本并提升服务质量。
游客qf4jmczx4xu2y
59 2
爱你三千遍斯塔克
|
4月前
|
运维 监控 大数据
部署-Linux01,后端开发，运维开发，大数据开发，测试开发，后端软件，大数据系统，运维监控，测试程序，网页服务都要在Linux中进行部署
部署-Linux01,后端开发，运维开发，大数据开发，测试开发，后端软件，大数据系统，运维监控，测试程序，网页服务都要在Linux中进行部署
爱你三千遍斯塔克
83 0
土木林森
|
6月前
|
敏捷开发 运维 监控
【专栏】微服务架构，以敏捷、灵活著称，通过拆分大型应用为小型自治服务，简化开发运维
【4月更文挑战第27天】微服务架构，以敏捷、灵活著称，通过拆分大型应用为小型自治服务，简化开发运维。本文探讨其基本概念、起源，核心优势（如敏捷开发、高可伸缩性）及挑战（系统复杂度、数据一致性），并分享实施策略（服务划分、技术选型、CI/CD）与实践案例（Netflix、Uber、Spotify），展示微服务如何重塑软件开发，并成为未来复杂应用系统的基础。
土木林森
133 1
XPcode7
|
6月前
|
运维 网络协议 Linux
【运维系列】Centos7安装并配置PXE服务
PXE是Intel开发的预启动执行环境，允许工作站通过网络从远程服务器启动操作系统。它依赖DHCP分配IP，DNS服务分配主机名，TFTP提供引导程序，HTTP/FTP/NFS提供安装源。要部署PXE服务器，需关闭selinux和防火墙，安装dhcpd、httpd、tftp、xinetd及相关服务，配置引导文件和Centos7安装源。最后，通过syslinux安装引导文件，并创建pxelinux.cfg/default配置文件来定义启动参数。
XPcode7
332 0
XPcode7
|
6月前
|
运维 网络协议 Linux
【运维系列】Centos7安装并配置postfix服务
安装CentOS7的Postfix和Dovecot，配置Postfix的`main.cf`文件，包括修改完全域名、允许所有IP、启用邮箱等。然后，配置Dovecot的多个配置文件以启用auth服务和调整相关设置。重启Postfix和Dovecot，设置开机自启，并关闭防火墙进行测试。最后，创建邮箱账户并在Windows邮箱客户端中添加账户设置。
XPcode7
222 0
XPcode7
|
6月前
|
运维 Linux 网络安全
【运维系列】Centos7安装配置ntp服务
配置yum并安装ntp，编辑ntp配置文件，取消17行注释，适应本机网段，22行设置使用本地时间。关闭防火墙，重启ntp服务。测试时先关闭防火墙，然后使用ntpdate命令成功同步时间。
XPcode7
539 0

热门文章

最新文章

  • 1
    【运维知识进阶篇】手把手教你搭建OpenVPN（保姆级教程）（一）
  • 2
    运维人员的军刀——ROS
  • 3
    云MSP服务案例|云上Oracle RAC部署运维及实践
  • 4
    IT运维服务商如何将WannaCry拒之门外？恒远志成称安全需防微杜渐
  • 5
    网络运维团队如何应对最新的黑客威胁？
  • 6
    半自动化运维之动态添加数据文件（一)
  • 7
    Oracle运维笔记之DG主备切换后的细节修改
  • 8
    运维调试记录：Ubuntu启动到字符界面和图形界面
  • 9
    考验与机遇并存，传统运维面对新局面可以这样做
  • 10
    阿里云发布CloudOps白皮书，ECS自动化运维套件新升级
  • 1
    揭秘高效运维：如何用kubectl top命令实时监控K8s资源使用情况？
    1760
  • 2
    K8S运维命令必备kubectl命令总结
    91
  • 3
    智能监控系统在运维中的应用与优势
    225
  • 4
    现代运维中的自动化技术应用与挑战
    90
  • 5
    DataWorks旧版的运维中心-->周期任务。对应新版的哪个位置？
    53
  • 6
    构建高效自动化运维体系：基于Docker和Kubernetes的最佳实践
    247
  • 7
    构建高效稳定的容器化运维环境
    155
  • 8
    linux脚本自动化运维任务
    105
  • 9
    现代化运维管理系统的关键特性及实践应用
    62
  • 10
    未来智能运维的发展趋势与挑战
    575

    • 相关课程

    更多
  • 企业运维之弹性计算原理与实践
  • 企业运维之云上网络原理与实践课程
  • 企业级运维之云原生与Kubernetes实战课程
  • 面向运维的 python 脚本速成-1024程序员节创造营公益课
  • Linux企业运维实战 - 入门及常用命令
  • 玩转云上智能运维

    • 相关电子书

    更多
  • 企业运维之云原生和Kubernetes 实战
  • 可视化架构运维实践
  • 2021云上架构与运维峰会演讲合集

    • 相关实验场景

    更多
  • 使用操作系统智能助手OS Copilot解锁操作系统运维与编程
  • 使用物联网平台远程管理运维设备
  • 消息队列RocketMQ版：消费异常运维排查体验
  • 快速开发光伏电站数字孪生运维系统
  • RocketMQ运维自我实践
  • RocketMQ的常规运维实践应用
    • 下一篇
    阿里云无影云电脑免费试用，最长可试用3个月