是否有任何命令/脚本可以在进程崩溃或终止时自动写入以重新启动进程(在识别进程 ID 之后)。
例如,我正在运行一个可执行的 bin 文件,并希望在每次崩溃或被杀死时自动重新启动。
Dan Bernstein 的daemontools就是为此而设计的,并开始了一系列共享相同原始机制的工具集:
在它们中的几乎任何一个下,一个人编写一个run运行/作为守护进程的程序,一个服务管理器或主管进程使用普通的 Unix 和 Linux 机制将它作为一个分叉的子进程简单地监视。这可以通过以超级用户身份运行的专用服务管理器在系统范围内完成,也可以通过单个服务管理器按用户完成。
所有这些工具集都是连贯的和自洽的,但请注意,除了在任何特定情况下所需的工具之外,它们都不要求使用任何工具。一个人也可以混搭。可以execlineb在 perp 下使用 Laurent Bercot及其所有实用程序,或者nosh在 runit 下使用我的脚本解释器及其所有实用程序;就像chpst在我的service-manager.
同样,您可以使用从 systemd 运行的 systemd 范围或每用户服务。systemd 单元文件与run脚本的简单程度相同,尽管它们不是强制性的,但它们不提供对如何设置服务进程的执行状态的细粒度精确控制。当然,现在是 2017 年,迁移到 systemd 的第一条规则适用。
所有这些都提供了在引导时启动守护进程、在系统运行时在管理员/自动控制下停止和启动它以及在各种故障情况下自动重新启动它的基本基础。
扩展Ipor Sircer关于使用的评论systemd
来自RHEL 7 文档:
Systemd 是 Linux 操作系统的系统和服务管理器。它旨在向后兼容 SysV init 脚本,并提供许多功能,例如在启动时并行启动系统服务、按需激活守护进程、支持系统状态快照或基于依赖关系的服务控制逻辑。在 Red Hat Enterprise Linux 7 中,systemd 取代 Upstart 作为默认的 init 系统。
基本上将systemd服务和系统作为一个整体进行管理。如果您希望进程始终运行,那么您希望它作为服务运行。制作自定义服务文件并不难。
服务文件属于/etc/systemd/system/NAME.service 根据文档
再次来自RHEL 7 文档的自定义服务文件示例:
[Unit]
Description=service_description
After=network.target
[Service]
ExecStart=path_to_executable
Type=simple
[Install]
WantedBy=default.target
Run Code Online (Sandbox Code Playgroud)
他们对这个文件的作用的描述:
在哪里:
service_description 是一个信息性描述,显示在日志日志文件和 systemctl status 命令的输出中。
After 设置确保服务仅在网络运行后启动。添加以空格分隔的其他相关服务或目标的列表。
path_to_executable 代表实际服务可执行文件的路径。
...
WantedBy 声明服务应该在其下启动的一个或多个目标。将这些目标视为对旧的运行级别概念的替代,有关详细信息,请参阅第 9.3 节 “使用 systemd 目标”。
Type=simple是常态,并假设在 中启动的可执行文件ExecStart将保持运行。
回到最初的问题,如果您习惯于systemd将您的流程转换为服务,您可以使用它systemd来确保您的服务始终运行。
再次来自RHEL 7 文档:
另一个例子是一个配置文件,它在主进程退出后重启服务,延迟30秒:
[Service]
Restart=always
RestartSec=30
Run Code Online (Sandbox Code Playgroud)
如果您只是将该Restart=always选项添加到[Service]服务文件的部分中,则该服务应该在它关闭/退出时随时重新启动,除非您使用systemd.