rsyslog在重新引导系统（例如通过运行reboot）时，systemd是否使用了不同的超时设置来停止正在运行的守护程序（例如，），而仅在重新启动守护程序（例如，）时，systemd是否使用了不同的超时设置systemctl restart rsyslog？
我检查了systemd.service页面，但没有发现它。相反，我只找到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之前等待活动的网络连接来解决另一个问题。我在Drop-Ins下面提供了我要使用的两个systemd的内容，以防它为该条目添加有用的上下文。
cat /etc/systemd/system/rsyslog.service.d/*.conf | grep -Ev '#|^$'
尝试解决github＃1656
[单元] 文档= https：// internal / wiki / url /此处 之后= network.target 想要= nework.target
尝试解决github＃1704
[单元] 文档= https：// internal / wiki / url /此处 [服务] 超时停止时间= 240
谢谢您阅读此篇。
发出重新启动命令会导致systemd忽略TimeoutStopSec值吗？
不，那将是可怕的，事实并非如此。
编辑：v233以上的某些systemd版本添加JobTimeoutSec=30min到reboot.target。因此，在这种情况下，会有一个上限（在该上限之后，设备将强制重新启动），但它比您到目前为止设置的值高出几倍。
编辑：关于“想法是系统可能不耐烦并且正在将rsyslog仍保存到磁盘时杀死了rsyslog”，该消息似乎是rsyslog中的错误。
当从磁盘文件重新启动队列时，几乎总是发出一条消息，声称“文件已打开，无法追加写入，但已包含xxx字节”。此消息是错误的，没有表明真正的错误情况。谓词检查不正确。
查看Debian 9上的服务文件，请注意syslog.socket（由systemd提供）具有DefaultDependencies=no，而且还有Before=shutdown.target和Conflicts=shutdown.target。后一行被注释Don't allow logging until the very end。如果没有最后两个AND rsyslog.service DefaultDependencies=no，则可以立即重新激活syslog守护程序，并由systemd-shutdown.service（systemd-shutdown）终止。systemd-shutdown使用SIGTERM和SIGKILL之间的内置默认超时，我认为是90秒。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句