search

raboof / nethogs

Linux 'net top' tool
GNU General Public License v2.0
3.14k stars 286 forks source link

nethogs keeps counting network usage for a process that long terminated #277

Open JeckPeppinger opened 3 months ago

JeckPeppinger commented 3 months ago

scary!

nethogs keeps counting network usage for processes that long terminated!

command: sudo nethogs -P 8374 -P 8340 -v 3

process 8340 terminated 7 minutes ago, but nethogs keeps on counting data for that process.

image

raboof commented 3 months ago

-v 3 counts the total number of bytes for the process, and indeed keeps the record around instead of removing it from the report after the process has exited. It's not obvious to me that that is necessarily 'wrong' (let alone 'scary').

JeckPeppinger commented 3 months ago

hello raboof, your reading of the issue is not correct. That a record remains in the display for a terminated process is very expected for the -v 3 option.

What is completely wrong and indeed scary when nethogs KEEPS ON COUNTING TRAFFIC UP FOR A PROCESS THAT LONG TERMINATED. And i do not refer to the "TOTAL" in above picture. How can a non existing process consume network traffic? The process 8340 terminated at about Sent 1821.599 (or so) and kept on counting for hours way beyond the 2000.000 mark. This to me is scary. zombie traffic?

Sadly Nethogs entirely cannot be taken serious.

raboof commented 3 months ago

Ah, that is surprising indeed, thanks for clarifying.

I suspect it's mis-attributing traffic that was used by 8374 to 8340, possibly because it was using the same ip+port pairs. Looks like we should be more aggressively clearing the mapping cache from ip+port pairs to processes. Does that sound like it'd match what you saw?

raboof commented 3 months ago

(I'm not enjoying the all-caps and "cannot be taken serious" hyperbole btw - remember there's a human on the other end)

JeckPeppinger commented 3 months ago

Ah, that is surprising indeed, thanks for clarifying.

I suspect it's mis-attributing traffic that was used by 8374 to 8340, possibly because it was using the same ip+port pairs. Looks like we should be more aggressively clearing the mapping cache from ip+port pairs to processes. Does that sound like it'd match what you saw?

i cannot verify if this is a mapping issue, all i can spot is that traffic is being recorded for a long terminated process. whether this is false attributing, or double counting, or even wrong counting is not visible to me.