☰

重新启动与正常重新启动服务时，systemd 是否有不同的超时设置？

tag-icon • tag-icon systemd reboot
重新启动与正常重新启动服务时，systemd 是否有不同的超时设置？

rsyslog重新引导系统时（例如，通过运行reboot）与仅重新启动守护进程（例如，）时，systemd 是否使用不同的超时设置来停止正在运行的守护进程（例如， systemctl restart rsyslog）？

我已经检查过系统服务页面，但我没有发现它。相反，我只找到了TimeoutStopSec和TimeoutStartSec选项。我已经设置了该TimeoutStopSec选项，但似乎 systemd可能是在守护进程有机会安全保存其状态并彻底终止之前杀死它。

编辑1：

正如 @sourcejedi 建议的（谢谢），我应该强调，这不是运行 rsyslog 的桌面安装，而是 rsyslog 的 Ubuntu 16.04 服务器安装，它从客户端节点接收消息，并且当要求终止时，内存中可能仍保留许多消息通过 systemd。

我尝试通过将该选项的值TimeoutStopSec从 90 秒增加到 240 秒来帮助解决一些损坏的磁盘队列问题，但我仍然在相关日志文件中多次观察到此消息：

rsyslogd：队列'strm 0x26b4800'，文件'/var/spool/rsyslog/q_ForwardToNode2.00000003'打开用于非追加写入，但已包含983505字节[v8.29.0尝试http://www.rsyslog.com/e/ 0]

这个想法是，系统可能不耐烦，在将内容保存到磁盘时杀死 rsyslog。

我尝试通过强制 systemd 在尝试启动 rsyslog 之前等待活动网络连接来解决另一个问题。我已经包含了我在下面使用的两个 systemd 的内容Drop-Ins，以供参考，以防它为本条目添加有用的上下文。

cat /etc/systemd/system/rsyslog.service.d/*.conf | grep -Ev '#|^$'

尝试解决 github #1656

[单元]
文档=https://internal/wiki/url/here
之后=网络.目标
想要=network.target

尝试解决 github #1704

[单元]
文档=https://internal/wiki/url/here
[服务]
超时停止秒=240

谢谢您阅读此篇。

答案1

发出重新启动命令是否会导致 systemd 忽略 TimeoutStopSec 值？

不，那将是可怕的，而且事实并非如此。

编辑：v233 以上的某些 systemd 版本添加JobTimeoutSec=30min到reboot.target.因此，在这种情况下，会有一个上限（在此之后设备将强制重新启动），但它比您迄今为止设置的值高几倍。

编辑：关于“这个想法是系统可能不耐烦，并且在仍在将内容保存到磁盘时杀死 rsyslog”，该消息似乎是 rsyslog 中的错误。

队列错误修复：文件写入错误消息不正确#1759#1759

当从磁盘文件重新启动队列时，它几乎总是发出一条消息，声称“文件为非追加写入而打开，但已包含 xxx 字节”。此消息是错误的，并不表示真正的错误情况。谓词检查不正确。

查看 Debian 9 上的服务文件，请注意syslog.socket（由 systemd 提供）有DefaultDependencies=no、 但也 Before=shutdown.target有 和Conflicts=shutdown.target。后一行已注释Don't allow logging until the very end。如果你没有后两个和rsyslog.service 有，syslog 守护进程可以立即重新激活，并被( ) DefaultDependencies=no杀死。使用 SIGTERM 和 SIGKILL 之间的内置默认超时，我认为是 90 秒。systemd-shutdown.servicesystemd-shutdownsystemd-shutdown

相关内容