Does Proc::Interrupts() have a broken interface?

[danobi]

It looks like /proc/interrupts support was added in #475 .

But it's unclear how this interface works or if it ever worked.

For example:

• Interrupts() calls into p.path() to get the path to the interrupts file

  • procfs/proc_interrupts.go

    Line 45 in bb7727a

    data, err := util.ReadFileNoStat(p.path("interrupts"))

• But p.path() prepends a pid to the path

  • procfs/proc.go

    Line 288 in bb7727a

    return p.fs.Path(append([]string{strconv.Itoa(p.PID)}, pa...)...)

/proc/<pid>/interrupts does not exist. There is only /proc/interrupts.

[rexagod]

/proc/foo is associated with the kernel (all files one level under /proc). On an fresh docker container, with no userland processes running, find /proc -maxdepth 2 -name foo will return nothing for the second level, but doing a sleep 100& followed by cat /proc/$(pgrep sleep)/foo will show you the details about foo associated with the process of PID $(pgrep sleep).

I believe this can be closed now.

[SuperQ]

This is actually a bug. It should probably be p.proc.Path().

[rexagod]

I believe I assumed the issue to only target /proc/<pid>/interrupts, rather than /proc/interrupts too, my bad. We do support the former, but not the latter, as @SuperQ pointed out above. I'll patch this up. :)

[ffyuanda]

Do we have any more updates on this? I'm trying to use the Interrupts() method to access kernel-level /proc/interrupts but the existing method seems to only work on a per-process basis, e.g. open /proc/1146355/interrupts: no such file or directory