☰

在软件包安装过程中重新启动依赖服务的正确方法是什么？

tag-icon • tag-icon 14.04 upstart services packaging systemd
在软件包安装过程中重新启动依赖服务的正确方法是什么？

我正在创建一个配置包，并希望停止并重新启动受影响配置的服务。现在我正在使用service [stop|restart]in{pre,post}{inst,rm}方式。我在某个问题中读到，这invoke-rc.d是正确的方式，因为它尊重用户对服务的偏好。但是，我找不到有关此方面的任何指南。有人知道这样的指南吗？或者有什么建议告诉我应该选择哪种方式？该软件包是内部使用的，并且在未来两年内可能只适用于 14.04。但是，我想为我的继任者留下尽可能干净的状态，systemd我心里也是这样想的。

来自invoke-rc.d手册页：

Debian 软件包维护者脚本对初始化脚本的所有访问都应该通过调用-rc.d。

来自 Debian 政策手册，第 9 章第 3.3 节：

维护人员应该使用 update-rc.d 和 invoke-rc.d 程序提供的抽象层来处理其软件包脚本中的启动脚本，例如 postinst、prerm 和 postrm。

...

软件包维护者脚本必须使用invoke-rc.d来调用/etc/init.d/* initscripts，而不是直接调用它们。

Debian 一直在使用sysv-init并将直接转向systemd，我想政策手册也会适时更新以参考systemctl。但是，我不确定的是：我应该使用invoke-rc.d而不是service？我可以知道dpkg我对某些文件感兴趣（通过触发器），那么有没有办法知道dpkg我对某些服务也感兴趣并进行dpkg重新启动/重新加载？

澄清：我我没有编写初始化脚本。我提供了一个包含其他应用程序（如 Puppet、NTP 等）配置的包，因此我在脚本中停止并重新启动了相应的服务。

这里例如，这是关于invoke-rc.dvs 的Docker 问题service。该问题仍未解决，其中一人（可能是维护者）评论说他们肯定有兴趣这样做正确的方式——显然我们都不确定那是什么。（我的问题与该问题无关。）

答案1

我将继续使用安装前/安装后脚本，

preinst — 该脚本在软件包从其 Debian 档案（“.deb”）文件中解压之前执行。许多“preinst”脚本会停止服务对于正在升级的软件包，直到它们的安装或升级完成（在成功执行“postinst”脚本之后）。

postinst - 此脚本通常在将 foo 从 Debian 存档（“.deb”）文件中解压后完成对软件包 foo 的任何必需配置。通常，“postinst”脚本会要求用户输入，和/或警告用户，如果他接受默认值，则应记住根据情况返回并重新配置该软件包。然后，许多“postinst”脚本会执行任何启动或重新启动服务所需的命令一旦安装或升级了新的包。

看 -https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html

调用 start|stop|restart 的语法以条件形式写出，请参阅https://www.debian.org/doc/debian-policy/ch-opersys.html第 9.3.3.2 节 运行启动脚本

如果invoke-rc.d >/dev/null 2>&1; 那么

invoke-rc.d 包

别的

/etc/init.d/软件包

菲

所以 ...

if which service >/dev/null 2>&1; then
        service package <action>
elif which invoke-rc.d >/dev/null 2>&1; then
        invoke-rc.d package <action>
else
        /etc/init.d/package <action>
fi

并在需要时为 systemd 添加另一个条件；）

所以是的，启动|停止|重新启动服务的正确方法是使用适当的包装脚本（invoke-rc.d / system），如果可能的话，而不是调用 init 脚本（/etc/init.d/package）并在没有可用的包装器时回退到 /etc/init.d 脚本。

答案2

对于 systemd 系统来说，更好的方法是使用deb-systemd-invoke。

相关内容