主页 / unix / 问题 / 775999
Accepted
U. Windl
Asked: 2024-05-07 18:00:17 +0800 CST

谁在 Linux (SLES) 中更改了 `/proc/sys/kernel/random/boot_id`？

  • 772

好吧，我认为内核/proc/sys/kernel/random/boot_id在启动期间发生变化，然后在运行时保持该值是合乎逻辑的。如果 的预期用途boot_id是找出机器何时重新启动，那么至少这对我来说是有意义的。

当使用监视文件时monit，我注意到即使机器没有重新启动，文件似乎也发生了变化；这意味着文件的时间戳发生变化，而不是内容发生变化。

所以我想知道是谁更改了文件的时间戳。

作为参考，这是我正在使用的监视配置：

  check file bootid with path /proc/sys/kernel/random/boot_id
    #if changed timestamp then alert
    if content !=
       "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
    then alert
    if changed checksum then alert
    group local

在检查监控结果时，我得到：

File 'bootid'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  permission                   444
  uid                          0
  gid                          0
  size                         0 B
  access timestamp             Tue, 07 May 2024 11:01:31
  change timestamp             Tue, 07 May 2024 11:01:31
  modify timestamp             Tue, 07 May 2024 11:01:31
  content match                no
  checksum                     d174a6b860689b62417af5eccd2b17ee (MD5)
  data collected               Tue, 07 May 2024 11:46:11

交叉检查我得到：

# stat /proc/sys/kernel/random/boot_id
  File: '/proc/sys/kernel/random/boot_id'
  Size: 0               Blocks: 0          IO Block: 1024   regular empty file
Device: 4h/4d   Inode: 9770501     Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-05-07 11:01:31.721335498 +0200
Modify: 2024-05-07 11:01:31.721335498 +0200
Change: 2024-05-07 11:01:31.721335498 +0200
 Birth: -
# uptime
 11:49am  up 14 days  0:49,  4 users,  load average: 0.00, 0.00, 0.00

系统在 x86_64 上运行 SLES12 SP5，唯一的“嫌疑人”是 cron-jobs 和“snapper”：

May 07 11:00:01 v04 systemd[1]: Started Session 7426 of user root.
May 07 11:00:01 v04 systemd[1]: Started Session 7428 of user root.
May 07 11:00:01 v04 systemd[1]: Started Session 7427 of user root.
May 07 11:00:01 v04 CRON[5541]: (root) CMD ([ -x /usr/lib64/sa/sa1 ] && exe
May 07 11:00:01 v04 run-crons[5606]: suse.de-snapper: OK
linux

2 个回答

  1. Best Answer

    时间戳并/proc没有真正的意义。特别是，修改时间并不表示内容何时发生变化。我找不到相关的官方文档，但从快速的源代码研究来看，似乎所有三个时间戳（atime、mtime、ctime）都是在创建 inode 时设置的，然后从未更新。

    inode 是按需创建的。该请求可以是尝试读取文件、尝试写入文件或对文件进行stat( ) 调用。ls -l对于某些文件，可能存在对填充数据缓存并创建索引节点条目的值的内部需求，但我认为这不适用于/proc/sys/kernel/random/*被描述为“部分未使用的遗留旋钮”。

    因此，条目上的 mtime/proc可能是应用程序第一次需要该值的时间，或者是监控软件第一次命中该值的时间，以先到者为准。或者，如果从文件缓存中删除该索引节点，则该索引节点可能会更新。在任何情况下，它可以任意早于或晚于内容的创建。

    该boot_id值是在第一次读取文件时生成的，然后永远保存在内存中，因为它必须保持稳定，直到下次重新启动。

    无论如何，监控/proc没有任何意义。这些不是实际的文件，而是按需生成的内容。

    • 8

  2. 基本上https://unix.stackexchange.com/a/776000/320598是对的，我做了一个实验来验证（另见/usr/src/linux/Documentation/sysctl/vm.txt）：

    • echo 1 > /proc/sys/vm/drop_caches（免费页面缓存）没有效果
    • echo 2 > /proc/sys/vm/drop_caches（免费的可回收slab对象（包括目录项和索引节点））导致时间戳刷新
    • echo 3 > /proc/sys/vm/drop_caches（空闲的slab对象和pagecache）导致时间戳刷新
    • 4

相关问题