updated kernel, gkrellm no longer sees eth0, tun0 [FIXED]

Message

ExecutorElassus · Post by **ExecutorElassus** » Sat Aug 16, 2025 1:14 pm

There only seemed to be one new option to set for gentoo-sources-6.16.1, but after I installed it and booted into the new kernel, gkrellm no longer displays network traffic across the two interfaces. Was there some new security measure put in place on the new kernel? Or some other change? The only other packages that changed was removal of zoom and chrome's Talk plugin, and updating rust-bin.

Any ideas how to troubleshoot?

ETA: both interfaces are shown with 'route', which means they're both listed in the routing table. Gkrellm's man page says that it will display "all interfaces that are routed", but this doesn't seem to be working. Previous kernel was 6.16.0.

Cheers,

EE

NichtDerHans · Post by **NichtDerHans** » Sun Aug 17, 2025 1:15 pm

Hi

same "problem" on 6.12.42. Networkinterfaces gone from gkrellm. Still works (visible) on 6.12.41.

Have a nice day
Not the Hans

ExecutorElassus · Post by **ExecutorElassus** » Sun Aug 17, 2025 2:37 pm

Is that a recent kernel update for you? I'm on ~amd64, so I don't know if my kernel is masked for non-testing.

If it was a recent update, maybe it's not the kernel, but some other package?

NichtDerHans · Post by **NichtDerHans** » Sun Aug 17, 2025 4:55 pm

I use the latest ~amd64 6.12.x kernel. 6.12.41 is stable.

Maybe the root cause is another package, but I cannot find it. The update was on 15th august:

Rebuild: net-libs/libnma-1.10.6-r2
Installed: app-office/onlyoffice-bin-9.0.3
Rebuild: dev-qt/qtgui-5.15.17

Maybe gkrellm is a to old dead horse....

tholin · Post by **tholin** » Sun Aug 17, 2025 5:31 pm

Gkrellm reads network traffic speeds from /proc/net/dev. Check if that file exists and has sensible data. Here is what it looks like on a 6.12.38 kernel for me:

Code: Select all

# cat /proc/net/dev | column --table
Inter-|  Receive      |         Transmit                                                                                                               
face     |bytes       packets   errs      drop  fifo  frame  compressed  multicast|bytes  packets    errs      drop  fifo  colls  carrier  compressed  
lo:      44746647     49480     0         0     0     0      0           0                44746647   49480     0     0     0      0        0           0
eth0:    46387519366  31339717  0         4057  0     0      0           677              956076853  10875068  0     0     0      0        0           0
wlan0:   460701       6204      0         11    0     0      0           0                32721394   21612     0     0     0      0        0           0

ExecutorElassus · Post by **ExecutorElassus** » Sun Aug 17, 2025 5:35 pm

Hi tholin,

here's mine:

Code: Select all

# cat /proc/net/dev | column --table
Inter-|  Receive      |        Transmit                                                                                                                                                 
face     |bytes       packets  errs      drop  fifo  frame  compressed  multicast|bytes  packets    errs     drop  fifo  colls                                     carrier  compressed  
lo:      664060       1927     0         0     0     0      0           0                664060     1927     0     0     0                                         0        0                         0
eth0:    10620507817  8826777  0         0     0     0      0           23238            246419500  1620305  0     1     0                                         0        0                         0
sit0:    0            0        0         0     0     0      0           0                0          0        0     0     0                                         0        0                         0
tun0:    878200984    876045   0         0     0     0      0           0                78269932   709323   0     0     0                                         0        0                         0

Do there need to be any special permissions on that file? It's currently -r--r--r-- root:root.

Cheers,

garrison · Post by **garrison** » Mon Aug 18, 2025 5:32 am

I see very similar issue, noticed after updating to kernel 6.15.10 - in fact, interface is shown first then after update delay it disappears.

Traced it down to gkrellm opening /proc/net/route to read it, then it does rewind() which now fails with ESPIPE

If I replace rewind with fclose so gkrellm reopens that file before next read, it does subsequent reads successfully and interface stays displayed. Same workaround for /proc/net/dev allows gkrellm to see transferred bytes too.

Still not sure which kernel change can cause this or if it is a gkrellm implementation issue.

garrison · Post by **garrison** » Mon Aug 18, 2025 5:40 am

Could be caused by lseek handling change https://lkml.kernel.org/r/2025060702135 ... @honor.com though I did not investigated this further.

NichtDerHans · Post by **NichtDerHans** » Mon Aug 18, 2025 7:07 am

I agree, I have just find out that when gkrellm is started, one second the network interface is shown and it disappeared.
I have seen that there is gkrellm-2.4.0-r1 in the tree, but the same behavor.

ExecutorElassus · Post by **ExecutorElassus** » Mon Aug 18, 2025 7:10 am

For what it's worth I opened an issue on what appears to be gkrellm's github page.

garrison · Post by **garrison** » Mon Aug 18, 2025 7:16 am

Still likely a recent kernel issue since seeking to the very beginning worked with older kernels.

garrison · Post by **garrison** » Mon Aug 18, 2025 11:06 am

Reverting this change https://lore.kernel.org/all/20250607021 ... r.com/T/#u works for me to fix gkrellm network interface detection.

NichtDerHans · Post by **NichtDerHans** » Mon Aug 18, 2025 11:42 am

I think there is a reason to change it in the kernel (but I dont know). It is smarter to fix the bug in gkrellm. I try it.

https://git.srcbox.net/gkrellm/gkrellm/ ... ps/linux.c

garrison · Post by **garrison** » Mon Aug 18, 2025 11:54 am

Indeed this was confirmed regression in latest kernels https://lore.kernel.org/regressions/202 ... doxon.rec/

ExecutorElassus · Post by **ExecutorElassus** » Mon Aug 18, 2025 11:57 am

haha, whoops! The kernel broke it!

All right, so a fix seems to be in the pipeline, at least. I can rest easy now.

Cheers,

EE

NichtDerHans · Post by **NichtDerHans** » Mon Aug 18, 2025 12:11 pm

Very good.

NichtDerHans · Post by **NichtDerHans** » Mon Aug 18, 2025 12:22 pm

garrison wrote:I see very similar issue, noticed after updating to kernel 6.15.10 - in fact, interface is shown first then after update delay it disappears.

Traced it down to gkrellm opening /proc/net/route to read it, then it does rewind() which now fails with ESPIPE

If I replace rewind with fclose so gkrellm reopens that file before next read, it does subsequent reads successfully and interface stays displayed. Same workaround for /proc/net/dev allows gkrellm to see transferred bytes too.

Still not sure which kernel change can cause this or if it is a gkrellm implementation issue.

But to this point, I try to change it in gkrellm (because I want to try). Spoiler: I wont work.

I change line 1045 and 1175 ( rewind(f); to fclose(f); ) in https://git.srcbox.net/gkrellm/gkrellm/ ... ps/linux.c.

From the stable gkrellm 2.4 tarball. After "make" I want to start gkrellm with ".src/gkrellm". The error is:

Code: Select all

free(): double free detected in tcache 2
gkrellm aborted:  Net  (update_monitor)
Aborted

How can I find out what file you mean? Or have I completely misunderstood something?

garrison · Post by **garrison** » Mon Aug 18, 2025 12:27 pm

NichtDerHans wrote: I change line 1045 and 1175 ( rewind(f); to fclose(f); ) in https://git.srcbox.net/gkrellm/gkrellm/ ... ps/linux.c.

To apply workaround you need to replace code at lines 822 and 858 and then either remove 'static' from variable declarations for f and f6 or assign them to NULL after fclose(). Similar change to lines reading from /proc/net/dev

Or just wait for kernel fix to appear.

NichtDerHans · Post by **NichtDerHans** » Mon Aug 18, 2025 1:25 pm

Thank you, it works.

ExecutorElassus: I think you can close the bug in the gkrellm issues tracker.

ExecutorElassus · Post by **ExecutorElassus** » Fri Aug 29, 2025 10:33 am

As noted on the linked issue tracker, this is now fixed in the 6.16.4 kernel. Huzzah, my net meters are back!

Marking this as [FIXED].

Gatsby · Post by **Gatsby** » Fri Aug 29, 2025 4:17 pm

Nope.

With latest linux kernel 6.16.4 still no network meters in gkrellm (v.2.4.0-r1) shown.

ExecutorElassus · Post by **ExecutorElassus** » Fri Aug 29, 2025 4:34 pm

@Gatsby: are you sure about that? I updated my kernel and did nothing else, rebooted, and gkrellm is showing my net meters again. The issue tracker for this issue on gkrellm's github reports the same.

Can you confirm that you see your net meters on an unaffected kernel? That is, one that didn't have the offending commit applied?

Cheers,

EE

CachoChantun · Post by **CachoChantun** » Fri Aug 29, 2025 4:49 pm

Gatsby wrote:Nope.

With latest linux kernel 6.16.4 still no network meters in gkrellm (v.2.4.0-r1) shown.

I confirm this for 6.16.3. I am using Fedora 42 fully updated, just updated the kernel to the "official" 6.16.3-200.fc42.x86_64, and gkrellm (v. 2.4.0.3) does not show any network meters.

I suggest to patch gkrellm instead of waiting for the kernel to be fixed. In the meantime, rolling back to kernel 6.15.9.

Post by **sam_** » Sat Aug 30, 2025 12:15 am

Kernels are patched in Gentoo already, see bug 961815. I can't speak for other distributions.

It doesn't make sense to patch gkrellm because other applications are affected too (see https://lore.kernel.org/stable/CALjTZvZ ... gmail.com/).

Gatsby · Post by **Gatsby** » Sat Aug 30, 2025 2:19 pm

ExecutorElassus wrote:@Gatsby: are you sure about that? I updated my kernel and did nothing else, rebooted, and gkrellm is showing my net meters again. The issue tracker for this issue on gkrellm's github reports the same.

Can you confirm that you see your net meters on an unaffected kernel? That is, one that didn't have the offending commit applied?

Cheers,

EE

Hi ExecutorElassus,
Yes, no net meters in gkrellm with kernel 6.16.4. (vanilla-sources).
Today I recompiled a 6.15.7 kernel (vanilla-sources-6.15.7) for testing purposes and the gkrellm net meters are back again.

Regards,
Gasby