In linux a file is not empty but the size is 0 - shell

Question

I test whether a file is empty in Shell.
test -s /sys/fs/cgroup/systemd/docker/d4e311735706485e748513bad611070e223cba76fdf4c72a1102d14b653da750/tasks
It returns false, and I found its size is 0 when I use ls -lh, but when I use cat, I can get 4071 in this file, this means the file is not empty. I think maybe this file is too small, I create a file in my home directory, and echo 4071 to it, I find its size is not 0. Is the file in /sys/fs/cgroup special?

Answer 1

The file that you are dealing with is a special file which is a part of the cgroup file system.
To understand why this happens, let's see what happens when you do test -e $filename.
We will be using strace command which prints the system calls a command does.
If you do strace test -e $filename, you will find this line in the results:
stat("$filename", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
In this case it returns st_size = 0 which is the size of the file.
But the questions is what actually happens on the other side, inside the kernel:
When you try to deal with a file, you do a system call which goes to an intermediate layer in the kernel called the virtual file system which in turn calls the part responsible for the information needed. A stat system call will try to get the status out of the inode corresponding with file. The file system can create and manipulate the inode as it wants.
Cgroup is a special file system, when it adds a file (using the cgroup_add_file function defined in kernel/cgroup.c) it always passes size 0 to __kernfs_create_file so that is why any file inside /sys/fs/cgroups (created by cgroup fs) will always has a zero size regardless of the actual contents of the file.
For the other part, when cat the file. If you do strace cat $filename, that is what you will get:
open("$filename", O_RDONLY) = 3
read(3, "...", 131072) = ###
The read system call will go through the virtual file system to the kernel file system and using the file operations associated with the file, it will get you the needed data.
Cgroup fs has functions to generate the data in its files. This is how tasks file is defined in kernel/cgroup.c
{
.name = "tasks",
.seq_start = cgroup_pidlist_start,
.seq_next = cgroup_pidlist_next,
.seq_stop = cgroup_pidlist_stop,
.seq_show = cgroup_pidlist_show,
.private = CGROUP_FILE_TASKS,
.write = cgroup_tasks_write,
},
So seq_start, seq_next, seq_stop and seq_show are the functions responsible for generating the information needed for the file. You can easily go to kernel/cgroups.c and check for what they do.
Please note that if you are trying to know if the cgroup still has tasks, an easier way is to use notify on release.
from Documentation/cgroup-v1/cgroups.txt
If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the "release_agent" file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup. This enables automatic removal of abandoned cgroups. The default value of notify_on_release in the root cgroup at system boot is disabled (0). The default value of other cgroups at creation is the current value of their parents' notify_on_release settings. The default value of a cgroup hierarchy's release_agent path is empty.