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:


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
  • 4096 is suspiciously like a directory size; can you post the output of ls -ld /sys/power/wakelock_count – Jeff Schaller Jul 16 '17 at 14:22
  • @JeffSchaller updated main post. – Riuo Jul 16 '17 at 14:40
  • Seems to me that a piece of the android extensions are getting in the way. Try the android stack exchange? – Jeff Schaller Jul 16 '17 at 15:49

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 <rjw@rjwysocki.net>
        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.


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 \{\} \+

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.