☰

为什么journaltcl日志只在今天开始，而最后一次重新启动是在5天前完成的？

tag-icon • tag-icon centos systemd-journald journalctl
为什么journaltcl日志只在今天开始，而最后一次重新启动是在5天前完成的？

为什么journaltcl日志仅在今天开始，而最后一次重新启动是在 5 天前完成的？ :

$ journalctl -e | grep Logs.begin
-- Logs begin at Tue 2022-09-06 09:42:37 CEST, end at Tue 2022-09-06 11:04:27 CEST. --
$ last reboot | head -1
reboot   system boot  3.10.0-1160.62.1 Thu Sep  1 23:46 - 11:04 (4+11:18)
$ journalctl -u scality-sfused
-- No entries --
$ egrep -v "^$|^#" /etc/systemd/journald.conf
[Journal]
RateLimitInterval=2s
RateLimitBurst=5000
ForwardToSyslog=yes
$ systemctl status scality-sfused | grep Warning
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
$ ls /etc/logrotate.d/scality-sfused
ls: cannot access /etc/logrotate.d/scality-sfused: No such file or directory
$

EDIT0：这是/var/lib/logrotate/logrotate.status今天的：

$ cat /var/lib/logrotate/logrotate.status | grep $(date +%Y-%-m-%-d)
"/var/log/scality/node/node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-11.log" 2022-9-6-3:11:1
"/var/log/scality-biziod.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.err" 2022-9-6-3:11:1
"/var/log/scality/node/node-11.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-2.log" 2022-9-6-3:11:1
"/var/log/scality/backup/scality-backup.log.out" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-srebuildd.log" 2022-9-6-3:11:1
"/var/log/scality/node/tier1sync-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-12.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-3.log" 2022-9-6-3:11:1
"/var/log/scality-sagentd.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-3.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-1.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-7.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-5.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-9.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-4.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-2.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-8.log" 2022-9-6-3:11:1
"/var/log/scality/node/node-6.log" 2022-9-6-3:11:1
"/var/log/scality/node/chord-node-10.log" 2022-9-6-3:11:1
"/var/log/scality/node/chunkapi-node-11.log" 2022-9-6-3:11:1
$

编辑1：这是/etc/anacrontab文件：

$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

答案1

看一眼logrotate状态输出似乎确实可以确认 scalar 应用程序的日志已轮换。然而，这里有一点混乱，因为有二要考虑的日志集，以及不logrotate影响 返回的内容journalctl，journald 自己的文件也不由 管理logrotate。

日记日志

man systemd-journald.service列出了 Journald 保存和报告的日志的 5 个来源：

  1. 内核日志消息

    这些不是应用程序的输出，尽管它们可能受到应用程序行为的影响——根据名称，它们是来自内核的消息。这与您可以看到的内容相同dmesg。

  2. 简单的系统日志消息，通过 libc syslog(3) 调用

    这是包括持久性服务在内的应用程序可以使用的传统日志记录方法。如果您正在运行传统的 syslog 实现而不是 systemd-journald 或与 systemd-journald 一起运行（它们可以很好地协同工作），那么它们将输出到/var/log诸如messages和 之类的一组文件中syslog。如果没有，它们仍然会被日志捕获并显示在其服务层次结构中。请注意，这不允许使用特定于应用程序的文件，除非记录器本身设置为这样做，而这超出了应用程序的控制范围。发送到 syslog 的内容通常标有应用程序名称，但它们都集中在一起 - 这非常有用，因为内核消息通常也由 syslog 捕获，因此 syslog 是实时系统事件的交错记录。

    然而，许多应用程序根本不使用它，据我所知，没有强烈的约定支持或反对这一点。 请注意，systemd 本身会记录到 syslog通过journald，syslog 是journald 可以提供的东西。

  3. 通过本机 Journal API 构建结构化系统日志消息

    这可能是该命令的journald版本syslog，这意味着它必须在应用程序源代码中显式使用。我不知道这种情况有多普遍，但除了以 Linux 为中心的核心事物（例如桌面环境、包管理器等）之外，可能不会有太多影响。

  4. 服务单位的标准输出和标准误差。

    捕获这些是 systemd-journald 的默认行为，但它们也可以通过服务文件重定向到各个位置。

    根据我的经验，大多数复杂的服务应用程序不会过多使用它。

  5. 审计记录，源自内核审计子系统

    在上下文中，这些实际上是#1 的子类别。

  6. 这个在联机帮助页中没有明确显示，但特定于单元的 Journalctl 输出显然包含来自 systemd 的与相关单元相关的消息（例如Starting XXXXX...）。

这些都不包含 中的一堆内容/var/log/scality，这意味着这些文件与日志或系统日志无关。

应用程序日志

我不是 Scality 用户，但其中的内容肯定/var/log/scality是由应用程序直接创建的内容，而不是外部捕获的任何内容。

systemd 或journald 不使用这些东西的一个明显原因是程序将数据写入各种文件，并且如果没有某种配置协议来指导该过程，像journald 这样的外部实体无法知道什么是记录数据以及什么是记录数据。不是。这种协议也没有太多理由，因为如上所述，已经有应用程序使用系统日志等的机制。

编写大量自己的日志文件的事物通常（这可能是发行版打包者的工作）会安排以logrotate保持整洁。 Logrotate 早于 systemd，与 Journald 无关。 Journald 维护自己的持久存储（如果有）。

简而言之，关于“自单元启动以来日志已轮换”的原始消息是不是因为日志旋转。这是journald 自身运营的一部分。此外，Scality 登录/var/log/scality不是由 Journald 管理的，而是由 Scality 本身管理。

相关内容