3

Well, I thought it's just logical that the kernel changes /proc/sys/kernel/random/boot_id during boot, and then keeps that value while running. At least that would make sense to me if the intended use of boot_id is to find out when the machine rebooted.

When monitoring the file using monit, I noticed that the file seems to change even if the machine did not reboot; that means the timestamp of the file changes, not the contents.

So I wonder who changes the file's timestamps.

For reference, here's my monit configuration being used:

 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

When checking the monitoring results I got:

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

Cross-checking I got:

# 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

The system is running SLES12 SP5 on x86_64, and the only "suspects" are cron-jobs and "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
Improve this question

2 Answers 2

Reset to default
10

Timestamps in /proc aren't really meaningful. In particular, the modification time does not indicate when the content changes. I can't find official documentation about that, but from a quick source dive, it looks like all three timestamps (atime, mtime, ctime) are set when the inode is created and then never updated.

Inodes are created on demand. The demand can be an attempt to read the file, an attempt to write to the file, or a stat (ls -l) call on the file. For some files there might be internal demand for a value that fills a data cache and also creates the inode entry, but I don't think that applies to /proc/sys/kernel/random/* which are described as “partly unused legacy knobs”.

So the mtime on the /proc entry is likely either the first time an application wanted the value, or the first time your monitoring software hit it, whichever came first. Or it might be more recent if the inode is removed from the file cache. In any case, it can be arbitrarily older or newer than the creation of the content.

The boot_id value is generated the first time the file is read, and then kept in memory forever since it has to be stable until the next reboot.

In any case, monitoring /proc doesn't make sense. These are not actual files, this is content that's generated on demand.

Improve this answer
3
  • 2
    It's re-created if it got dropped from cache in the meantime, so that's how unexpected timestamp updates may come about. Either way, it should not be relied on... Commented May 7, 2024 at 10:38
  • The explanation makes sense (specifically as the size of the file is virtually zero), so there is a time assigned to a cached inode, and once that inode is overwritten in cache, the next generation gets a new set of timestamps? Commented May 7, 2024 at 10:56
  • @U.Windl Effectively yes, but only because it’s a synthetic filesystem like procfs, and it’s more a matter of the inode being created only as-needed (if you somehow forced it to not be cached, you would always see the current time as the mtime each time you looked, because the inode would have been created on-demand each time you looked). Commented May 8, 2024 at 11:03
4

Basically https://unix.stackexchange.com/a/776000/320598 is right, and I made an experiment to verify that the inode will be re-created if its memory was reclaimed (see also /usr/src/linux/Documentation/sysctl/vm.txt):

  • echo 1 > /proc/sys/vm/drop_caches (free pagecache) had no effect
  • echo 2 > /proc/sys/vm/drop_caches (free reclaimable slab objects (includes dentries and inodes)) caused a refresh of timestamps
  • echo 3 > /proc/sys/vm/drop_caches (free slab objects and pagecache) caused a refresh of timestamps
Improve this answer
1
  • Could you please elaborate what is the goal if the experiment? It shows that you dropped caches, but how does it relate to the original question since it acts on another path? Commented May 8, 2024 at 13:25

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.