我有两个 v20.04 系统，其中一个脚本在 /var/log 中创建了多达一百万个文件。在删除垃圾文件（并修复脚本）后，该目录的访问速度在几个月内一直很慢。我曾尝试诊断并修复该问题，但没有成功。
在进行完全重新安装之前，我想尝试对 /var/log 进行干净刷新。本问答旨在记录替换整个 /var/log 目录的正确、最干净、最快捷的方法，同时尽可能减少干扰。是的，我可以在新系统中进行实验，看看什么方法似乎有效，但这并不能告诉我避免长期不可预见后果的“正确”方法。
方法 1：删除目录中的所有内容
我不想这样做，rm -rf /var/log/*因为类似的操作已经让这些系统陷入奇怪的状态。
也许这是旧信息，但我读到过我们不应该简单地删除 /var/log 文件，因为它们可能不会在关机/重启时重新创建。有人可以为 Ubuntu v20+ 验证或更正此问题吗？我怀疑这取决于每个应用程序，以及它们是否假设在初始创建后它们的日志将始终存在，或者它们是否始终以创建/附加的形式写入。
方法 2：替换整个目录
- 初始化
- mv /var/日志 /var/oldlogs
- mkdir -p /var/log
- chown root：系统日志/var/log
- chmod 0775 /var/log
- 初始化 6
由于文件锁定，这可能无法实现。这可能会导致某些可能仍在维护模式下运行的程序出现暂时（无关紧要？）错误。该文件夹可能被某些权限锁定，从而阻止其被删除。我们如何确保上述操作有效？
再次，如上所述，我们需要确保在重新启动时如果预期文件不存在则创建它们。
方法三：清除并替换已知文件
这需要手动操作，并且应该编写脚本，并且每个系统都不同。想法是清除上述所有内容，但在重新启动之前，将已知需要且未损坏的特定文件夹和文件复制回去。这将有助于消除预期文件和目录的潜在问题。
方法 4：长期解决方案：挂载（绑定）新目录
与方法 2 类似，但不允许直接在 /var/log 中创建新日志，而是将其挂载到完全不同的文件夹，例如 /var/local/logs。
方法 5：长期解决方案：对日志使用不同的分区
重建系统，为日志创建一个单独的分区，并将其挂载到 /var/logs。
概括
考虑到我考虑过的上述选项，我希望有人能确认上述选项之一是最有效和最无忧的解决方案，或者提出一些其他的解决方案，让每个找到此问答的人都可以使用。“正确”的解决方案应该是我们知道可以作为正常系统维护的一部分来做的事情。我不知道 Ubuntu 中是否已经内置了一个可以重建 /var/log 的实用程序，无论是实时重建还是在重启时重建，或者 Github 上是否有一些实用程序/要点。