Systemd 延迟重新启动失败的服务，似乎添加了 30 个睡眠时间

Question

您的服务包含Type=forking.这意味着你的单位期望你的ExecStart=命令fork()然后退出。activating (start)只要该服务ExecStart=仍在运行，就会一直存在。当ExecStart=结束时，systemd将选择一个衍生进程（MainPID）并进入该active (running)状态。

您的ExecStart=程序似乎是一个 bash 脚本。这个脚本可能看起来像这样：

#!/bin/bash
sudo -u admin -i python /path/to/application/myapplication.py start p1 | logger &

while /bin/true; do
    sleep 30
done

该脚本有一些问题，但您应该感兴趣的部分是sleep 30最后的部分。您的主进程正在运行，但 systemdactive (running)在完成之前不会进入该状态sleep 30。您每次都会看到一个新的 PID，因为新的 PIDsleep 30不断被调用。

一个表现良好的脚本会创建您的应用程序，然后立即退出。您的脚本可能正在等待应用程序在退出之前已正确启动的反馈，这很好，但它显然没有得到它正在等待的反馈，因此您需要更深入地挖掘以找出原因不是。

但是，我认为您的脚本更有可能在退出之前等待您的应用程序退出。像这样的东西：

python myapplication.py &
PID=$!

while ps | grep -q $PID; do
    sleep 30
done

我认为这是因为听起来像是你在killing python，而不是ExecStart=剧本。这意味着该装置将一直保留到完成activating (start)为止sleep 30。然后它会检查你的 python 应用程序的 PID 是否仍然存在（不是），然后你的脚本才会停止。

该脚本的另一部分让我困扰的是sudo. sudo旨在验证交互式用户。它并不是为了验证脚本。相反，更优雅的解决方案是User=admin在您的服务中使用。

我看到两个解决方案。选项 2 是迄今为止我最喜欢的：

编辑/path/to/application/myapplication并删除该while循环。
使用简单的服务并完全跳过该脚本。看起来它是为另一个 init 系统编写的（它显式启动自己的记录器，现在不需要），然后修改为在 shell 中调用时阻止。 systemd为您完成所有这些工作，所以我敢打赌根本不需要该脚本。

[Unit]
Description=my application service for %i.

[Service]
Type=simple
ExecStart=/usr/bin/python3 /path/to/application/myapplication.py %i
User=admin
Restart=always

[Install]
WantedBy=multi-user.target

如果这没有帮助，请发布内容/path/to/application/myapplication

Answer 1