Cannot read regular file - IO operations block

Question

I'm writing a program that scans through all files in an Android device, looking for a specific string. A few seconds through the process, I get stuck on the following file:

/sys/power/wakelock_count

I tried using grep, C function fopen, as well as other alternatives, and they all IO block on this file - they simply never return. Its size is exactly 4096 bytes, but using stat or ls -l the file is reported as a regular file - no symlink, no device file. I checked for open handles - this file is open by system_se, which also happens to hold handles to dozens of other files, which I can however read just fine. I also checked for locks and there are no MANDATORY locks that would prevent read access.

What is so special about this file and how can I read or skip it?

EDIT: I am running all operations as SU.

EDIT2: ls -ld result:

-rw-r--r-- 1 system system 4096 1971-10-10 21:59 wakeup_count

Answer 1

Note that /sys/power/wakeup_count is not really a "regular" file because it's not on a "regular" file system. It's almost certain on a "sysfs-power" filesystem, which is similar to the "proc" filesystem in that it's not really representing anything like files on disks.

Per the sysfs-power filesystem documentation:

What:       /sys/power/wakeup_count
Date:       July 2010
Contact:    Rafael J. Wysocki <[email protected]>
Description:
        The /sys/power/wakeup_count file allows user space to put the
        system into a sleep state while taking into account the
        concurrent arrival of wakeup events.  Reading from it returns
        the current number of registered wakeup events and it blocks if
        some wakeup events are being processed at the time the file is
        read from.  Writing to it will only succeed if the current
        number of wakeup events is equal to the written value and, if
        successful, will make the kernel abort a subsequent transition
        to a sleep state if any wakeup events are reported after the
        write has returned.

So, hanging reads might not be a problem, although hanging for a long time doesn't seem to be likely given the above documentation.

However, it's quite possible you may be running into this bug: Reading from /sys/power/wakeup_count is hanging indefinitely That's pretty much exactly the same symptoms you describe.

Answer 2

Whether or not there is a specific problem with /sys/power/wakeup_count, the answer is that files in the /sys filesystem are special virtual files. Reading and writing them provides access to kernel features. It is possible that some files under /sys or other virtual filesystem will block on reads, until a specific event happens.

Exclude /sys and /proc. Just as you would exclude named sockets, named pipes, or device files e.g. found in /dev. If you are writing a general-purpose tool to search any specified directory, you might want to let the user search what they like and expect them to avoid the problem themself - this is the Unix Way (TM).

On current Linuxes, the automatic special virtual filesystem mounts will all be underneath /dev, /sys, /proc, and /var/lib/nfs/rpc_pipefs/. Slightly older ones might also have /selinux. You should not need to worry about new special paths being added in future, because /sys/fs is now used as a dumping-ground for any new special filesystem.

One traditional way to do this is to search specific filesystems only, as in the find -xdev. You can use df to list all the non-special filesystems. Then for example, if / and /home are separate filesystems that you want to search:

find / /home -xdev -type f -exec grep search-string \{\} \+