Bug 722364 – app-admin/gkrellm-2.3.11-r1: suble bug in proc panel fork counts

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description G.Wolfe Woodbury 2020-05-11 07:24:20 UTC]

gkrellm is a single process system monitoring stack.  Among the functions it can monitor is a summary of the process table, including a count of forks make by the kernel during the most recent collecting interval.  In is systeminterfaces library, it uses the file src/sysdeps/linux.c to collect information from the OS.

It gets the niumber of forkss for the proc panel from the /proc/loadavg interrface. The problem is that this value is the pid assigned to the latest process forked.  This is a 32-bit value that the kernel consrains to [300-32768] range.  It rolls over to the lowest available pid when it passes 32768.  This creates a negative value when adapted for display of the number of forks. Not only this, but the kernel skips pids thet are not available when assigning pid numbers.

At the same time, the linux.c coe reads and processes a number of values from the /proc/stst interface, but it ignores the "processes" entry in this file, which is, indeed, the number of forks since bootup asa 64-bit (unsigned?) integer.

I suggest that gkrellm should use the number out of /proc/stat instead of the pid read from /proc/loadavg.

---
I have attempted to make such a change in the linux.c code, but I have not been successful in penetrating the complexities of the function that reads /proc/stat to pick up the "processes" entry properly, without messing up the other entries it reads from /proc/stat. [I am getting quite old, and have some cognitive declines due to a complex set of health problems, so I apologize for not presenting a patchset to fix this.]

[Comment 1 Jonas Stein 2020-05-14 00:21:42 UTC]

Did you contact upstream? http://gkrellm.srcbox.net/

[Comment 2 Sam James 2023-02-03 09:43:21 UTC]

Please send this upstream at https://git.srcbox.net/gkrellm/gkrellm/issues.