当前位置: 首页 > news >正文

systemd-notify(linux服务状态通知消息)

起因是redis安装systemd配置后,可以启动,但是systemctl start redis命令挂起无法退出,最后查出是因为redis的systemd配置启动类型为Type=notify,但是redis本身并没有编译为支持systemd的版本。

所以详细了解了下Type=notify。

notify启动类型举例(centos8):

例子服务程序:notify-srv.sh

#!/bin/bashsystemd-notify --ready --status="Waiting for data…"
sleep 10do_counter=1
while : ; dosystemd-notify --status="Processing $do_counter"sleep 5do_counter=$[ $do_counter + 1 ]
done

例子服务配置:notify-srv.service

[Unit]
Description=My Notify Test[Service]
Type=notify
ExecStart=/home/work/test/notify-srv.sh[Install]
WantedBy=multi-user.target

安装例子服务:

chmod +x /home/work/test/notify-srv.sh
cp ./notify-srv.service /usr/lib/systemd/system/notify-srv.service
systemctl daemon-reload

测试:

可以看到status文本的变化。

其中:

1、systemd-notify --ready --status 报告服务已启动,同时发送了status文本。

2、systemd-notify --status 报告更多的状态消息。

例子服务和systemd之间的通信通过$NOTIFY_SOCKET进行,$NOTIFY_SOCKET由systemd创建,在服务启动时通过环境变量NOTIFY_SOCKET传递给服务进程。

如:

复现问题一(Type=notify,服务不支持systemd-notify):

注释掉systemd-notify --ready --status

重启服务测试:

systemctl restart notify-srv 会挂起,不退出。

systemctl status notify-srv显示:

可以看到,和第一条status对比,由于systemd一直没有收到ready通知,所以active状态一直是start,systemctl start/restart一直不退出。但服务进程已经启动并正常运行。

复现问题二(Type=simple,服务支持systemd-notify):

修改service的启动类型为simple:

重载配置、重启服务测试:

如上图,服务状态running,但status消息不再显示,多了“$NOTIFY_SOCKET was not set”报错,因为Type=simple启动类型并未向服务进程传递环境变量NOTIFY_SOCKET,所以systemd-notify命令报错。

总结:

不支持systemd-notify的服务不可以使用Type=notify启动类型,可以改用Type=simple或其他启动类型。

以下是网友整理的systemd-notify使用手册:

systemd-notify 中文手册 [金步国]

systemd.service 中文手册 [金步国]

名称

systemd-notify — 向 systemd 报告服务状态的变化

大纲

systemd-notify [OPTIONS...] [VARIABLE=VALUE...]

描述

systemd-notify 可用于 在守护进程脚本中向 systemd 报告进程状态的变化。 可用于发送任意信息, 其中最重要的是 报告"启动已完成"的消息。

此工具基本上就是对 sd_notify() 的简单包装, 以便于在脚本中使用。详见 sd_notify(3) 手册。

注意,在报告状态更新的同时, 还可以传递一系列环境变量。

注意,在默认情况下(也就是调用此命令的服务单元含有 NotifyAccess=none), systemd 并不从此命令接受状态更新消息。

注意,服务单元的 sd_notify() 通知能够正常工作的前提, 是必须满足如下两个条件之一: (1)在 PID=1 的进程处理通知消息时,发送该通知的进程依然在运行; (2)发送该通知的进程是 systemd 派生的子进程(也就是匹配 NotifyAccess=mainNotifyAccess=exec 的进程)。 如果服务单元中的某个辅助进程在发送了 sd_notify() 通知之后就立即退出了, 那么 systemd 将有可能来不及将该通知关联到这个服务单元上。 在这种情况下,即使明确设置了 NotifyAccess=all , 该通知也可能会被忽略掉。

systemd-notify 会首先尝试以调用进程的PID来调用 sd_notify() (此操作仅在确实拥有足够权限的情况下才会成功), 如果失败,将会使用其自身的PID再次调用 sd_notify() 。 这种做法对于从 shell 脚本中调用 systemd-notify 命令非常有用, 特别是当服务的主进程是 shell 的时候(由于 NotifyAccess=all 的限制), 因为在这种情况下, shell 进程(而不是 systemd-notify 进程)将成为消息的发送者。

选项

能够识别的命令行选项如下:

--ready

向 systemd 报告"启动已完成"的消息。 这等价于 systemd-notify READY=1 。 详见 sd_notify(3) 手册。

--pid=

向 systemd 报告主守护进程的 PID 。 如果 PID 参数被省略, 将使用调用 systemd-notify 的进程的 PID 。 这等价于 systemd-notify MAINPID=$PID 。 详见 sd_notify(3) 手册。

--uid=USER

向 systemd 报告此消息来自哪个用户,也就是使用指定的 USER 取代调用此命令的用户,作为此通知消息的发送者。 USER 既可以是一个UID数值也可以是一个用户名字符串。 此选项需要足够的权限才能操作进程的用户标识。

--status=

向 systemd 发送一个任意内容的字符串消息。 这等价于 systemd-notify STATUS=… 。 详见 sd_notify(3) 手册。

--booted

用于检查系统的 init 进程是否为 systemd , 返回 0 表示系统的 init 进程是 systemd ,返回非零表示其他。 此选项并不发送任何消息,因此与其他选项没有任何关系。 详见 sd_booted(3) 手册。 另一种检查方法是 systemctl(1) 的 is-system-running 命令。 若返回 "offline" 则表示 系统的 init 进程不是 systemd

-h, --help

显示简短的帮助信息并退出。

--version

显示简短的版本信息并退出。

退出状态

返回值为 0 表示成功, 非零返回值表示失败代码。

--end--

http://www.xdnf.cn/news/270649.html

相关文章:

  • 视频编解码学习一之相关学科
  • Java框架“若依RuoYi”前后端分离部署
  • 2025年最新嵌入式开发STM32单片机详细教程(更新中)
  • GTS-400 系列运动控制器板(十四)----软限位使用
  • 多元随机变量协方差矩阵
  • 62常用控件_QDial的使用
  • Learning vtkjs之PolyDataNormals
  • Spring MVC注解式控制器开发
  • 计算方法实验五 插值多项式的求法
  • java 洛谷题单【算法2-2】常见优化技巧
  • 纯Java实现STDIO通信的MCP Server与客户端验证
  • 【Java】2025 年 Java 学习路线:从入门到精通
  • 【进阶】C# 委托(Delegate)知识点总结归纳
  • Spring事务管理
  • [计算机网络]数据链路层
  • 1993年地级市民国铁路开通数据(地级市工具变量)
  • Servlet (一)
  • 大数据技术:从趋势到变革的全景探索
  • Servlet+tomcat
  • 链表的回文结构题解
  • Linux 的 epoll 与 Windows 的 IOCP 详解
  • Mybatis学习(上)
  • 04 基于 STM32 的时钟展示程序
  • 《算法导论(第4版)》阅读笔记:p4-p5
  • HTML与CSS实现风车旋转图形的代码技术详解
  • Webug4.0靶场通关笔记10- 第14关链接注入
  • 深度学习助力校园学生自杀预防
  • wsl2 中使用串口
  • 【信息系统项目管理师】【论文】项目背景示例
  • 66. Java 嵌套类