0

Noted for a file in /proc modification timestamp is not changed when file is written to after being open in r+ mode (but changed if opened in w mode). Any particular reason why is it working that way?

TL;DR

When tackling an issue with thinkfan (Why fan gets enabled again and again after thinkfan started and ended once?), noted that /proc/acpi/ibm/fan modification time is not changed as a result of thinkfan operation, I doubted the program uses it. But building modified code myself confirmed it opens it, ((fan = fopen(IBM_FAN, "r+")) == NULL). I opened the file in my c app with w, when I've changed my code to open with r+ timestamp of modification also stopped to change.

Just doing echo level 1 | sudo tee /proc/acpi/ibm/fan also update file modification timestamp. I've read https://stackoverflow.com/questions/21113919/difference-between-r-and-w-in-fopen and the difference r+ and w is that w truncates the file. Just in case checked on ext4 writing to file opened with r+ updates modification timestamp.

Added per comments:

$ sudo cat /proc/acpi/ibm/fan status: disabled speed: 0 level: 0 commands: level <level> (<level> is 0-7, auto, disengaged, full-speed) commands: enable, disable commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds)) $ sudo strace stopfan // r+ execve("/usr/local/bin/stopfan", ["stopfan"], 0x7ffdf26fdc50 /* 25 vars */) = 0 openat(AT_FDCWD, "/proc/acpi/ibm/fan", O_RDWR) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "level 0\n", 8) = 8 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ $ sudo strace ./stopfan // w+ execve("./stopfan", ["./stopfan"], 0x7ffca68b2d40 /* 25 vars */) = 0 openat(AT_FDCWD, "/proc/acpi/ibm/fan", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "level 0\n", 8) = 8 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++
Improve this question
7
  • What is the file content before and after the operation? Can you add the strace output for opening, writing to, and closing that file? Commented Nov 18, 2021 at 15:32
  • @Hauke, content? this is zero length file per ls. I'm not sure how to add strace properly, the app is run with set-user-ID as root fine, but when I've tried strace my_app I saw output indicating it was not run as root. Therefore I've added sudo strace my_app Commented Nov 18, 2021 at 15:44
  • The file sizes in /proc are determined on reading the files so they are not shown correctly in directory listings. Just do (sudo) cat /proc/acpi/ibm/fan. You need to run strace as root: sudo strace my_app Commented Nov 18, 2021 at 15:48
  • @Hauke, added cat and strace Commented Nov 18, 2021 at 15:50
  • 1
    I just did ls -l /proc and all the files there had mtime set to the current time. I doubt proc even tries to be consistent in any way with the times. It also seems to never update atime. The only place I can see mtime mentioned in the source (in fs/proc) is a few places that do inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode). Maybe the update seen on rewrite comes from somewhere else. Commented Nov 18, 2021 at 17:34

1 Answer 1

Reset to default
1

I have no idea whether this is intentional or a bug (maybe useful to ask on the kernel mailing list if noone here explains it).

But I can confirm that this seems to be a general behaviour in /proc. I tried it with /proc/sys/net/ipv4/ip_forward. echo 0 >>ip_forward does change the value from 1 to 0 but does not change mtime. echo 1 >ip_forward does change mtime.

Improve this answer

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.