我有一个 systemd 服务，我使用 raspberry pi 4 上的命令通过 debian 包安装。在安装包和运行服务时apt，我一直用来journalctl -xef跟踪所有日志输出以进行调试。
我不确定我是如何做到这一点的，但在今天的某个时候，apt日志输出以及我的包的维护者脚本的输出停止出现在日志中。我的软件包的维护者脚本中确实有几个拼写错误，并且有时我倾向于用手指敲键盘或按热键，但我找不到任何可能导致问题的具体内容。日志似乎也默认为内存存储，这很糟糕，因为我尝试解决该问题的第一件事就是重新启动。所以现在我想我什至无法回顾旧的日记条目来看看其中是否有一些东西可以表明发生了什么。
我还认为我今天在服务或包中所做的一些更改可能导致了问题，因此我尝试安装较旧的概念验证服务/包，但它也无法正确写入日志。
我试图找到一种方法来重新安装或修复apt/apt-get/dpkg安装，但不太成功。大多数问题都与修复软件包安装有关使用 apt，不修复自身的安装apt。我还尝试查看是否有一种方法可以配置日志的写入位置，但大多数问题都与运行命令时的apt重定向有关。stdout/stderrapt
我对 Linux 和上面列出的所有技术都很陌生，所以我不确定如何进一步调试/诊断。
有没有办法修复/恢复apt/apt-get/dpkg树莓派上的安装或配置，或者是我尝试恢复到出厂默认设置或重新安装整个操作系统的唯一选择？
更新
今天我了解到了/var/log目录。我在这些日志中没有发现任何导致此问题的原因，但问题似乎也扩展到syslog、messages和user.log（daemon.log即，apt/apt-get这些日志中也缺少来自包维护者脚本的输出）。我可以看到几个apt install/upgrade/purge操作成功记录在这些文件中，然后就没有更多了。但是，我可以知道应该记录更多条目，因为我的程序包调用systemctl daemon-reload并且我可以systemd[1]: Reloading在日志中看到。从浏览来看/var/log/dpkg.log，这些条目似乎都没有显示在 中journald，所以这似乎仍然没问题。来自 的日志/var/log/apt/term.log肯定已丢失journald，但来自 的日志/var/log/auth.log仍然存在。
答案1
事实证明这是用户错误。
apt直接从终端运行的日志是绝不出现在journald.
所讨论的服务systemd是自动更新服务。apt我看到的日志记录是journald因为自动更新服务正在调用而发生apt-get的，因为它是自动更新服务的子进程，我猜日志记录到与其父进程相同的位置（syslog、daemon.log等）。