展开讨论

创业与收入经验摘录 · 机器翻译

我们的一个客户报告了一个由于磁盘已满导致生产环境宕机的事件

… 我们的一个客户报告了一个由于磁盘已满导致生产环境宕机的事件。我们获取了该虚拟机的副本并进行了检查。调查发现,根目录(/)已满是因为 /var/log 已满,而我们计划每天运行一次的 'logrotate' 定时任务单元从未运行过,或者只运行过一次……我记不太清到底是哪一种了。进一步调查发现,这个虚拟机与另一个具有正常运行的 logrotate 定时任务单元的虚拟机在软件负载或配置方面没有任何差异。在这个站点的数百个相同虚拟机中(以及在其他客户的站点中更是有成倍的数量),只有这一个虚拟机受到了影响。我们建议客户清理 /var/log 并重启系统,但这并没有让 'logrotate' 恢复正常,我们所能找到的任何诊断或修复方法都无法让它恢复正常。一旦 "systemd-crond" 决定永远不再安排这个任务,它就坚持这个决定。…

源讨论你对 systemd 定时器的热爱还不够原帖 300 条评论 · 导入时统计
2

社区评论 0

还没有社区评论,来聊聊你的看法。

原讨论中的回复 2

仅展示本次导入中包含的直接回复。中文为机器翻译,可查看英文原文。

ED

这个问题? https://github.com/systemd/systemd/issues/6680

完整原文
HT

> 核心开发者的讨论遵循着一种模式,这种模式在遇到由项目中各部分之间极其复杂的、未预料到的相互作用导致的 SystemD 错误时,人们经常能看到。 > SystemD 包含了大量的——并且不断增长的——意外复杂性,而且有一组核心维护者通常对记录那些一个或多个复杂系统结合在一起导致“世界停止”的地方,或者修复这些系统以防止它们结合在一起并不感兴趣。 非常好的评论。谢谢你的长篇大论。我确信这源于过度的挫败感。 我惊讶地发现 Systemd 正是导致我长期对更改 DNS 设置感到困扰的原因。更让我惊讶的是,我发现服务器管理员也有同样的问题,很多人因此转而不再使用 systemd-resolved。

完整原文
在 Hacker News 阅读

尊重不同观点,分享具体经验。

登录后即可发帖、评论、转发和引用。