3
如何负责地在Arch Linux上自动运行更新？
我是Arch Linux的新手，并且仍然习惯于它的某些范例。我从另一个发行版中吸取了很多习惯，该发行版结构化了很多，并且在某些方面可以预见。 我想在少数系统上做的一件事¹是使cron作业能够自动更新所有系统软件包。这似乎很容易，除了我还希望从系统中得到一些有意义的反馈，告诉我事情进展得不是那么冗长，以至于我最终忽略了它，直到发现系统正在运行。 的完整输出pacman是不必要的。我不在乎下载用了多长时间，或者它是否在53的更新46中。 在大多数情况下，我并不关心成功。 我确实关心错误。如果更新运行失败，我想知道它，任何特定的错误消息都应打补丁。 我确实关心安装过程中发出的“通知”。例如，今天的systemd更新说： :: coredumps are no longer sent to the journal by default. To re-enable: echo >/etc/sysctl.d/50-coredump.conf \ "kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e" 或文件系统产生此： warning: /etc/group installed as /etc/group.pacnew warning: /etc/passwd installed as /etc/passwd.pacnew warning: /etc/shadow installed as /etc/shadow.pacnew 最后一个类别实际上是促使我问这个问题的原因，因为似乎在整个包装组中这些不一致。其中一些似乎是由生成的post_upgrade()，其他是由install()等等生成的。有时将它们写入stdout，有时写入stderr。消息的格式差异很大：有时整个块以某种方式以缩进为前缀，而其他时候则只是一个裸露的回显字符串。 我想了解可能需要我干预系统但又不会打扰的事情。是否有工具可以智能地管理这些数据并简化系统管理？有什么方法可以使软件包生成的输出与安装它们的pacman进程分开吗？还是我自己编写一种解析器，以从安装日志中过滤掉良性内容？ ¹在您跳到多么愚蠢的状态之前，请注意，我足够聪明，不会在生产服务器上执行此操作，并且也不会没有基于快照的完整系统备份，如果发生灾难，恢复将很容易。