Created attachment 220143 [details] screenshot root@mowa219-gjp4-8570p:~ # uname -v FreeBSD 13.0-CURRENT #72 r367936: Sun Nov 22 21:46:00 GMT 2020 root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@mowa219-gjp4-8570p:~ # pkg query '%o %v %R' net-mgmt/bandwhich net-mgmt/bandwhich 0.20.0 FreeBSD Screenshot attached. If I recall correctly, an earlier version of bandwhich did successfully show process names or IDs.
(In reply to Graham Perrin from comment #0) I tried running the port on my own machine, and it showed names for the various processes I had running at the time ('firefox', 'openvpn' etc.). ❯ uname -v FreeBSD 12.2-RELEASE-p1 GENERIC ❯ pkg query '%o %v %R' net-mgmt/bandwhich net-mgmt/bandwhich 0.20.0_1 FreeBSD I also checked the previous version (0.19.0) just to be sure, and it behaved in the same way. Your screenshot shows a copy of Transmission running, I assume it's the process that is being reported as <UNKNOWN>. The author lists a few reasons why a process might be listed as <UNKNOWN> in a previous GH issue: https://github.com/imsnif/bandwhich/issues/149#issuecomment-593577947 The FreeBSD port uses lsof under the bonnet. Have you checked what it shows when Transmission is running? Do any other processes show up on the list?
Is it a problem with lsof on 13-CURRENT
It continues to show a single <UNKNOWN> whilst (for example) running Firefox; and before, during and after a start of Thunderbird. Apparently a single process with a rising number of connections, as Thunderbird makes its connections. I start Falkon, the number of connections for <UNKNOWN> rises; I quit Falkon, the number drops. And so on. bandwhich aside for a moment, <https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077655.html> there's a suggestion to use fstat. Elsewhere recently I read stronger discouragement from relying upon lsof on FreeBSD. Not bookmarked (sorry) but if I do find the technical discussion again, I'll add something here. Note to self: not found in #freebsd on IRC. In the meantime: <https://www.freebsd.org/cgi/man.cgi?query=lsof#BUGS> I see <https://github.com/imsnif/bandwhich/issues/149#issuecomment-629828150> but whether fstat is feasible for bandwhich, I have no idea.
(In reply to Graham Perrin from comment #3) > … Elsewhere recently I read stronger discouragement from > relying upon lsof on FreeBSD. … Found. I added the relevant quote to <https://github.com/imsnif/bandwhich/issues/149#issuecomment-748452835>
Now there's only occasional appearance of UNKNOWN https://www.freshports.org/net-mgmt/bandwhich/#history Overcome by events?
(In reply to Graham Perrin from comment #5) Good to hear. Just to be clear, are you still on the same revision of 13.0-CURRENT that you we're on when you first reported the problem? That is, can the change in behaviour be attributed to a Rust version update alone?
I lack the knowledge to answer those questions, sorry. I should have added that I moved beyond 13.0-CURRENT. Now: ---- % pkg info -x rust librsvg2-rust-2.50.3_1 rust-1.50.0 % freebsd-version -kru 14.0-CURRENT 14.0-CURRENT 14.0-CURRENT % uname -a FreeBSD mowa219-gjp4-8570p 14.0-CURRENT FreeBSD 14.0-CURRENT #87 main-5ac839029d: Mon Feb 22 04:02:26 GMT 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 % pkg info -x bandwhich bandwhich-0.20.0_3 % ---- <https://www.freshports.org/lang/rust/#history>
(In reply to Graham Perrin from comment #7) > lack the knowledge to answer those questions, I meant, the question about Rust :-)
I no longer see this symptom. Let's close this as overcome by events. There's now a different bug, I should probably await a resolution to <https://github.com/imsnif/bandwhich/issues/254#issuecomment-1272281489> (bug bug 265345 maybe not fixes) before reporting what's new (and different to 265345) …
(In reply to Graham Perrin from comment #9) On a computer with FreeBSD 13.1-RELEASE-p2: * processes such as firefox and ntpd are measured * plus at least one <UNKNOWN> process. Today's first observance of <UNKNOWN> was with bandwhich in one tab in Konsole, whilst running this in an adjacent tab: gitup ports At the time of writing, gitup ports is still: # Scanning local repository... – I can't be certain that <UNKNOWN> related to gitup. From the three linked issues in GitHub, all of which relate to unknown processes, I assume that this bug is upstream.
(In reply to Graham Perrin from comment #10) > … I can't be certain that <UNKNOWN> related to gitup. A few seconds after reopening this bug report, gitup did appear in bandwhich.
Hi all, current bandwhich maintainer here. I would like to notify you all that I am now actively working on diagnosing and fixing this issue, and have already made some progress. More details at https://github.com/imsnif/bandwhich/issues/196. Please come over if you are interested in testing the changes. Thanks all.
^Triage: deassign to non-committer. maintainer-feedback+ is sufficient here.
@Graham Perrin: Bandwhich was recently updated to version 0.22.2 which *should* include a fix for this. Could you please test the new version to see whether you can still reproduce the problem? Thanks!