Salt 的 rh_service 执行模块在 RHEL 系 sysvinit/upstart 主机上统一管理服务【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt导读rh_service是 Salt 中面向 RHEL 系发行版RedHat、CentOS、ScientificLinux、CloudLinux、Amazon、Fedora、ALT、OEL、SUSE 等的服务管理执行模块负责在基于 sysvinit 或 sysvinit/upstart 混合 init 系统的 minion 上提供service.*一系列服务管理功能。本文以 doc/ref/modules/all/salt.modules.rh_service.rst 为主线结合 salt/modules/rh_service.py 的完整实现与 tests/pytests/unit/modules/test_rh_service.py 的单元测试完整讲解该模块的加载条件、服务类型识别机制、全部公开函数的用法与底层实现原理帮助你在一批运行 sysvinit/upstart 的旧版 RHEL 系服务器上熟练使用 Salt 完成服务的启停、自启配置与状态查询。模块定位什么系统会用 rh_service该 RST 文档是典型的 Sphinxautomodule自动文档桩其全部可读内容函数签名、CLI 示例、版本变更说明都来自 salt/modules/rh_service.py 的模块 docstring 与各函数 docstring。模块顶部明确写道Service support for RHEL-based systems, including support for both upstart and sysvinit即为基于 RHEL 的系统提供服务管理支持同时兼容 upstart 与 sysvinit 两种 init 体系。它注册的虚拟模块名是service见 salt/modules/rh_service.py 的__virtualname__ service意味着在满足加载条件的主机上salt * service.start ...这类调用实际上执行的就是本模块的函数。何时加载、何时拒绝加载模块通过__virtual__()决定是否以虚拟名service加载判定逻辑位于 salt/modules/rh_service.py可归纳为以下规则systemd 优先原则若系统以 systemd 引导通过__utils__systemd.booted判断模块直接拒绝加载返回The rh_service execution module failed to load: this system was booted with systemd.。现代发行版由systemd模块接管。仅限特定发行版允许加载的osgrain 集合为XenServer、XCP-ng、RedHat、CentOS、ScientificLinux、CloudLinux、Amazon、Fedora、ALT、OEL、SUSE Enterprise Server、SUSE、McAfee OS Server、VirtuozzoLinux。版本边界按osrelease_info主版本号判断SUSE 仅当osrelease以11开头时加载SUSE 11 拒绝XenServer / XCP-ng 要求主版本 7Fedora 要求主版本 15RedHat、CentOS、ScientificLinux、OEL、CloudLinux 要求主版本 7。其他未列入集合的发行版返回Cannot load rh_service module: OS not in {enable}。这些边界与事实一致RHEL 7、Fedora 15 起全面转向 systemd因此 rh_service 只服务于旧版 RHEL 系与 SUSE 11 这类仍使用/usr/bin/service的系统。如果发现 Salt 使用了错误的服务模块官方提供了providers配置强制指定模块见 doc/ref/modules/index.rst例如在 minion 配置中providers: service: systemd即可强制 minion 用systemd模块提供service.*功能而不是 rh_service。服务类型识别upstart 还是 sysvinitrh_service 一个关键能力是自动区分服务由 upstart 还是 sysvinit 管理公开函数内部都会先调用对应的判定函数再选择底层命令。三个私有判定函数如下salt/modules/rh_service.py函数判定依据说明_service_is_upstart(name)HAS_UPSTART且存在/etc/init/{name}.confupstart 服务以/etc/init/下的.conf文件为标志_service_is_sysv(name)/etc/init.d/{name}存在且文件模式含用户可执行位stat.S_IXUSR只认可执行的 init 脚本_service_is_chkconfig(name)/sbin/chkconfig --list {name}返回码为 0是否被 chkconfig 管理其中HAS_UPSTART在模块导入时由salt.utils.path.which(initctl)探测决定若系统存在initctl模块会直接复用salt.modules.upstart_service中已有的_upstart_enable、_upstart_disable、_upstart_is_enabled三个辅助函数而不是重新实现见 salt/modules/rh_service.py这一复用而不重复造轮子的设计保证了 upstart 行为与独立 upstart 模块完全一致。运行级别探测_runlevel()salt/modules/rh_service.py执行/sbin/runlevel获取当前运行级别。特殊之处在于当处于 kickstart 环境时输出中会出现unknown此时模块默认按运行级别3处理——因为服务器部署场景通常就是 runlevel 3否则后续所有依赖 runlevel 的服务状态判断都会抛出 out of range 异常。服务枚举get_all / get_enabled / get_disabled / available / missing这三个枚举类函数都支持limit参数取值upstart、sysvinit或空同时包含两者结果一律排序后返回。get_all(limit)L355列出全部已安装服务。sysvinit 列表来自chkconfig --list输出中首列为服务名、次列以0:开头的行且只保留存在可执行 initscript 的服务upstart 列表来自/etc/init/*.conf文件名去掉.conf后缀。get_enabled(limit)L291返回已启用自启动的服务sysvinit 侧按当前 runlevel 判定。get_disabled(limit)L320返回未启用自启动的服务。available(name, limit)L377判断服务是否可用不限limit时等于 upstart、sysvinit、chkconfig 三者取或。missing(name, limit)L402available的逆操作。CLI 示例来自函数 docstringsalt * service.get_all salt * service.get_all limitupstart salt * service.get_all limitsysvinit salt * service.get_enabled salt * service.get_enabled limitupstart salt * service.get_enabled limitsysvinit salt * service.available sshd salt * service.available sshd limitupstart salt * service.available sshd limitsysvinit单元测试 tests/pytests/unit/modules/test_rh_service.py 通过 mock_upstart_services、_sysv_services与各 enabled 判定函数验证了get_enabled/get_disabled/get_all在upstart、sysvinit与不限类型三种场景下的返回值可帮助理解各分支行为。服务生命周期管理start / stop / restart / reload / status生命周期函数遵循同一模式先判断服务类型upstart 服务直接调用start、stop、restart、reload、status原生命令sysvinit 服务则调用/sbin/service {name} action返回值为底层命令返回码取反not retcode。salt * service.start service name salt * service.stop service name salt * service.restart service name salt * service.reload service name salt * service.status service name [service signature]status(name, sigNone)L495有三点值得注意提供sig参数时直接委托status.pid(sig)通过进程签名判断服务是否运行自 2018.3.0 起docstring 中的versionchanged标注name支持 glob 匹配如salt*通过fnmatch.filter(get_all(), name)展开此时返回值为{服务名: True/False}的字典普通单服务查询时upstart 服务检查status输出是否包含start/running字样sysvinit 服务以/sbin/service {name} status的返回码是否为 0 作为判据且ignore_retcodeTrue避免非 0 返回被误报为命令执行错误。对应测试见 tests/pytests/unit/modules/test_rh_service.pyupstart 分支 mock 输出start/running断言返回Truesysvinit 分支分别验证了sig委托status.pid与 retcode0 两种路径。开机自启控制enable / disable / enabled / disabled开机自启控制是 rh_service 与纯 upstart 模块差异最大的部分因为 sysvinit 侧依赖 chkconfig 与/etc/rc.d/rc*.d符号链接enable(name)L562/disable(name)L578upstart 服务委托给 upstart 模块的_upstart_enable/_upstart_disablesysvinit 服务走_sysv_enable/_sysv_disable。enabled(name)L594/disabled(name)L610查询类接口对 upstart 服务调用_upstart_is_enabledsysvinit 服务调用_sysv_is_enableddisabled即取反。salt * service.enable service name salt * service.disable service name salt * service.enabled service name salt * service.disabled service namesysvinit 侧底层逻辑_sysv_enable/_sysv_disableL215若服务未被 chkconfig 管理先执行chkconfig --add {name}注册_chkconfig_add还会将新服务初始配置为所有 runlevel 禁用见 L134-L146再执行chkconfig {name} on/off。_sysv_is_enabled(name, runlevelNone)L178优先询问 chkconfig若 chkconfig 不认为已启用则回退检查当前 runlevel 下是否存在/etc/rc.d/rc{runlevel}.d/S??{name}这样的S前缀启机链接。_chkconfig_is_enabled(name, runlevelNone)L194解析chkconfig --list {name}输出。它同时处理两种输出形态传统形态如atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off逐 runlevel 判断{runlevel}:on以及 xinetd 托管服务的形态xinetd based services: atd on整行[name, on]。测试 test__chkconfig_is_enabled 用 textwrap 构造了这两种输出逐一验证了不同 runlevel 下的判定结果。服务删除deletedelete(name, **kwargs)L5442016.3.0 新增按服务类型分派upstart 服务_upstart_deleteL251并不物理删除而是把/etc/init/{name}.conf重命名为/etc/init/{name}.conf.removed——这是一种可逆的软删除策略sysvinit 服务_sysv_deleteL240执行chkconfig --del {name}。salt * service.delete service name适用边界与排障提示使用 rh_service 时需留意以下边界版本与 init 系统前提本模块只在未以 systemd 引导、且 os grain 命中白名单并满足版本上限的系统上生效。对 RHEL/CentOS 7、Fedora 15、SUSE 11、XenServer/XCP-ng 7Salt 会改由systemd模块提供服务管理这是预期行为而非故障。若出现service.start is not available错误意味着虚拟名service没有匹配到任何可加载模块。可先检查os、osrelease等 grains 是否被正确识别必要时按 doc/ref/modules/index.rst 的说明在 minion 配置中用providers显式指定服务模块。状态查询语义enabled/disabled判断的是开机自启而非当前是否运行运行状态请用status。sysvinit 服务还可能出现 chkconfig 与 rc.d 链接信息不一致的情况此时模块以 chkconfig 结果优先并回退检查 rc 链接作为兜底。相关资源模块完整实现salt/modules/rh_service.py单元测试tests/pytests/unit/modules/test_rh_service.py文档参考页doc/ref/modules/all/salt.modules.rh_service.rst虚拟模块 provider 覆盖机制doc/ref/modules/index.rst【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Salt 的 rh_service 执行模块在 RHEL 系 sysvinit/upstart 主机上统一管理服务【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt导读rh_service是 Salt 中面向 RHEL 系发行版RedHat、CentOS、ScientificLinux、CloudLinux、Amazon、Fedora、ALT、OEL、SUSE 等的服务管理执行模块负责在基于 sysvinit 或 sysvinit/upstart 混合 init 系统的 minion 上提供service.*一系列服务管理功能。本文以 doc/ref/modules/all/salt.modules.rh_service.rst 为主线结合 salt/modules/rh_service.py 的完整实现与 tests/pytests/unit/modules/test_rh_service.py 的单元测试完整讲解该模块的加载条件、服务类型识别机制、全部公开函数的用法与底层实现原理帮助你在一批运行 sysvinit/upstart 的旧版 RHEL 系服务器上熟练使用 Salt 完成服务的启停、自启配置与状态查询。模块定位什么系统会用 rh_service该 RST 文档是典型的 Sphinxautomodule自动文档桩其全部可读内容函数签名、CLI 示例、版本变更说明都来自 salt/modules/rh_service.py 的模块 docstring 与各函数 docstring。模块顶部明确写道Service support for RHEL-based systems, including support for both upstart and sysvinit即为基于 RHEL 的系统提供服务管理支持同时兼容 upstart 与 sysvinit 两种 init 体系。它注册的虚拟模块名是service见 salt/modules/rh_service.py 的__virtualname__ service意味着在满足加载条件的主机上salt * service.start ...这类调用实际上执行的就是本模块的函数。何时加载、何时拒绝加载模块通过__virtual__()决定是否以虚拟名service加载判定逻辑位于 salt/modules/rh_service.py可归纳为以下规则systemd 优先原则若系统以 systemd 引导通过__utils__systemd.booted判断模块直接拒绝加载返回The rh_service execution module failed to load: this system was booted with systemd.。现代发行版由systemd模块接管。仅限特定发行版允许加载的osgrain 集合为XenServer、XCP-ng、RedHat、CentOS、ScientificLinux、CloudLinux、Amazon、Fedora、ALT、OEL、SUSE Enterprise Server、SUSE、McAfee OS Server、VirtuozzoLinux。版本边界按osrelease_info主版本号判断SUSE 仅当osrelease以11开头时加载SUSE 11 拒绝XenServer / XCP-ng 要求主版本 7Fedora 要求主版本 15RedHat、CentOS、ScientificLinux、OEL、CloudLinux 要求主版本 7。其他未列入集合的发行版返回Cannot load rh_service module: OS not in {enable}。这些边界与事实一致RHEL 7、Fedora 15 起全面转向 systemd因此 rh_service 只服务于旧版 RHEL 系与 SUSE 11 这类仍使用/usr/bin/service的系统。如果发现 Salt 使用了错误的服务模块官方提供了providers配置强制指定模块见 doc/ref/modules/index.rst例如在 minion 配置中providers: service: systemd即可强制 minion 用systemd模块提供service.*功能而不是 rh_service。服务类型识别upstart 还是 sysvinitrh_service 一个关键能力是自动区分服务由 upstart 还是 sysvinit 管理公开函数内部都会先调用对应的判定函数再选择底层命令。三个私有判定函数如下salt/modules/rh_service.py函数判定依据说明_service_is_upstart(name)HAS_UPSTART且存在/etc/init/{name}.confupstart 服务以/etc/init/下的.conf文件为标志_service_is_sysv(name)/etc/init.d/{name}存在且文件模式含用户可执行位stat.S_IXUSR只认可执行的 init 脚本_service_is_chkconfig(name)/sbin/chkconfig --list {name}返回码为 0是否被 chkconfig 管理其中HAS_UPSTART在模块导入时由salt.utils.path.which(initctl)探测决定若系统存在initctl模块会直接复用salt.modules.upstart_service中已有的_upstart_enable、_upstart_disable、_upstart_is_enabled三个辅助函数而不是重新实现见 salt/modules/rh_service.py这一复用而不重复造轮子的设计保证了 upstart 行为与独立 upstart 模块完全一致。运行级别探测_runlevel()salt/modules/rh_service.py执行/sbin/runlevel获取当前运行级别。特殊之处在于当处于 kickstart 环境时输出中会出现unknown此时模块默认按运行级别3处理——因为服务器部署场景通常就是 runlevel 3否则后续所有依赖 runlevel 的服务状态判断都会抛出 out of range 异常。服务枚举get_all / get_enabled / get_disabled / available / missing这三个枚举类函数都支持limit参数取值upstart、sysvinit或空同时包含两者结果一律排序后返回。get_all(limit)L355列出全部已安装服务。sysvinit 列表来自chkconfig --list输出中首列为服务名、次列以0:开头的行且只保留存在可执行 initscript 的服务upstart 列表来自/etc/init/*.conf文件名去掉.conf后缀。get_enabled(limit)L291返回已启用自启动的服务sysvinit 侧按当前 runlevel 判定。get_disabled(limit)L320返回未启用自启动的服务。available(name, limit)L377判断服务是否可用不限limit时等于 upstart、sysvinit、chkconfig 三者取或。missing(name, limit)L402available的逆操作。CLI 示例来自函数 docstringsalt * service.get_all salt * service.get_all limitupstart salt * service.get_all limitsysvinit salt * service.get_enabled salt * service.get_enabled limitupstart salt * service.get_enabled limitsysvinit salt * service.available sshd salt * service.available sshd limitupstart salt * service.available sshd limitsysvinit单元测试 tests/pytests/unit/modules/test_rh_service.py 通过 mock_upstart_services、_sysv_services与各 enabled 判定函数验证了get_enabled/get_disabled/get_all在upstart、sysvinit与不限类型三种场景下的返回值可帮助理解各分支行为。服务生命周期管理start / stop / restart / reload / status生命周期函数遵循同一模式先判断服务类型upstart 服务直接调用start、stop、restart、reload、status原生命令sysvinit 服务则调用/sbin/service {name} action返回值为底层命令返回码取反not retcode。salt * service.start service name salt * service.stop service name salt * service.restart service name salt * service.reload service name salt * service.status service name [service signature]status(name, sigNone)L495有三点值得注意提供sig参数时直接委托status.pid(sig)通过进程签名判断服务是否运行自 2018.3.0 起docstring 中的versionchanged标注name支持 glob 匹配如salt*通过fnmatch.filter(get_all(), name)展开此时返回值为{服务名: True/False}的字典普通单服务查询时upstart 服务检查status输出是否包含start/running字样sysvinit 服务以/sbin/service {name} status的返回码是否为 0 作为判据且ignore_retcodeTrue避免非 0 返回被误报为命令执行错误。对应测试见 tests/pytests/unit/modules/test_rh_service.pyupstart 分支 mock 输出start/running断言返回Truesysvinit 分支分别验证了sig委托status.pid与 retcode0 两种路径。开机自启控制enable / disable / enabled / disabled开机自启控制是 rh_service 与纯 upstart 模块差异最大的部分因为 sysvinit 侧依赖 chkconfig 与/etc/rc.d/rc*.d符号链接enable(name)L562/disable(name)L578upstart 服务委托给 upstart 模块的_upstart_enable/_upstart_disablesysvinit 服务走_sysv_enable/_sysv_disable。enabled(name)L594/disabled(name)L610查询类接口对 upstart 服务调用_upstart_is_enabledsysvinit 服务调用_sysv_is_enableddisabled即取反。salt * service.enable service name salt * service.disable service name salt * service.enabled service name salt * service.disabled service namesysvinit 侧底层逻辑_sysv_enable/_sysv_disableL215若服务未被 chkconfig 管理先执行chkconfig --add {name}注册_chkconfig_add还会将新服务初始配置为所有 runlevel 禁用见 L134-L146再执行chkconfig {name} on/off。_sysv_is_enabled(name, runlevelNone)L178优先询问 chkconfig若 chkconfig 不认为已启用则回退检查当前 runlevel 下是否存在/etc/rc.d/rc{runlevel}.d/S??{name}这样的S前缀启机链接。_chkconfig_is_enabled(name, runlevelNone)L194解析chkconfig --list {name}输出。它同时处理两种输出形态传统形态如atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off逐 runlevel 判断{runlevel}:on以及 xinetd 托管服务的形态xinetd based services: atd on整行[name, on]。测试 test__chkconfig_is_enabled 用 textwrap 构造了这两种输出逐一验证了不同 runlevel 下的判定结果。服务删除deletedelete(name, **kwargs)L5442016.3.0 新增按服务类型分派upstart 服务_upstart_deleteL251并不物理删除而是把/etc/init/{name}.conf重命名为/etc/init/{name}.conf.removed——这是一种可逆的软删除策略sysvinit 服务_sysv_deleteL240执行chkconfig --del {name}。salt * service.delete service name适用边界与排障提示使用 rh_service 时需留意以下边界版本与 init 系统前提本模块只在未以 systemd 引导、且 os grain 命中白名单并满足版本上限的系统上生效。对 RHEL/CentOS 7、Fedora 15、SUSE 11、XenServer/XCP-ng 7Salt 会改由systemd模块提供服务管理这是预期行为而非故障。若出现service.start is not available错误意味着虚拟名service没有匹配到任何可加载模块。可先检查os、osrelease等 grains 是否被正确识别必要时按 doc/ref/modules/index.rst 的说明在 minion 配置中用providers显式指定服务模块。状态查询语义enabled/disabled判断的是开机自启而非当前是否运行运行状态请用status。sysvinit 服务还可能出现 chkconfig 与 rc.d 链接信息不一致的情况此时模块以 chkconfig 结果优先并回退检查 rc 链接作为兜底。相关资源模块完整实现salt/modules/rh_service.py单元测试tests/pytests/unit/modules/test_rh_service.py文档参考页doc/ref/modules/all/salt.modules.rh_service.rst虚拟模块 provider 覆盖机制doc/ref/modules/index.rst【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址: https://gitcode.com/gh_mirrors/sa/salt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
