Bug 244601 - sysutils/lsof no longer lists open txt files
Summary: sysutils/lsof no longer lists open txt files
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Larry Rosenman
Depends on:
Reported: 2020-03-04 22:37 UTC by Patrick Mackinlay
Modified: 2022-05-21 01:22 UTC (History)
9 users (show)

See Also:
linimon: maintainer-feedback? (ler)

fixes txt on FreeBSD 12 and FreeBSD 11 (431 bytes, patch)
2022-05-21 01:22 UTC, Jamie Landeg-Jones
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Mackinlay 2020-03-04 22:37:43 UTC
The latest changes to this port (lsof-4.93.2_9,8) has broken parts of
the lsof functionality. When the utility is run with -p it no longer
lists open txt files. When the utility is run against a file (i.e. lsof
/lib/libc.so.7) it doesn't list any processes that have opened the file
as a txt segment.
I tried this in both 12.0-RELEASE-p12  and 12.1-RELEASE-p1 (both amd64).
Note that downgrading to lsof-4.93.2_3,8 fixes the problem.
Comment 1 Larry Rosenman freebsd_committer 2020-03-04 22:43:03 UTC
I need kernel folks help with this.
Comment 2 Pawel Biernacki freebsd_committer 2020-03-04 23:31:07 UTC
Did you use prebuild packages or build the port on your own?
Comment 3 Larry Rosenman freebsd_committer 2020-03-04 23:37:32 UTC
It doesn't matter.  It's broken even on self-built.
Comment 4 Gleb Smirnoff freebsd_committer 2020-03-05 17:02:24 UTC
Well, right now it doesn't self built on CURRENT so I can't test it.

My suspicion is vm_map_entry_read_succ() redefinition in dialects/freebsd/dproc.c.
Comment 5 Mateusz Guzik freebsd_committer 2020-03-05 22:53:17 UTC
This code is in a dire need of a rewrite -- not only it keeps using /dev/kmem but has ifdefs for ancient releases. Linux support sticks to kernel-exported data, meaning all this is probably decently localized and it's just a matter of converting the format from libprocstat or filling it from sysctls, whichever is more handy.

If lsof needs something from the vfs layer which happens to not be exported right now I'm happy to add relevant support.

Someone else will have to cover vm.

Bare minimum effort would take care of file access handling as it keeps breaking, I'll do it this week if nobody steps up for this part. Note I wont be fixing the bug at hand.
Comment 6 Larry Rosenman freebsd_committer 2020-03-05 23:18:31 UTC
I've been aking for help from the kernel folks for OVER A YEAR. 

I'm tired of the above type comments, but NO ONE stepping up to do the work.

I was able to maintain lsof while Vic Abell was maintaining the code base, but he has retired (he's 85+).   I need someone from the kernel group to take this by the horns are convert the github code to be more modern and less incestuous on the kernel data.

I'm ALMOST to the point of DEPRECATING and REMOVING the port.
Comment 7 Doug Moore 2020-03-06 04:05:50 UTC
We communicated on 12-17-2019 about a problem like this, and I thought we reached a resolution, but I don't see the patch I gave you in the dialects/freebsd/dnode.c code when I pull the latest master code via git.  Where did it go?  Should I be looking somewhere else?

At any rate, you haven't been ignored for a year.  I even fixed an MPASS problem for you.
Comment 8 Larry Rosenman freebsd_committer 2020-03-06 04:20:54 UTC
Look in the patches in the port. 

I haven't been able to get stuff merged into master on GitHub.
Comment 9 Larry Rosenman freebsd_committer 2020-03-06 04:22:34 UTC
And what I'm complaining about is people wanting to "Modernize" the interfaces from lsof<->kernel, but no one wants to do that work.

I'm not enough of a kernel hacker (not even a little bit) to do that work.
Comment 10 Mateusz Guzik freebsd_committer 2020-03-06 04:41:40 UTC
Well I said I'm going to take care of the vfs part (or at least some of it) this week unless someone else wants to.
Comment 11 Doug Moore 2020-03-06 06:39:39 UTC
Is this a problem that arises for 12.x releases with revision 520539 of the lsof port (which I'm examining at https://svnweb.freebsd.org/ports/head/sysutils/lsof/files/patch-dialects_freebsd_dproc.c?revision=520539&view=markup
Comment 12 Larry Rosenman freebsd_committer 2020-03-06 15:37:54 UTC
yes.  The current port fails to list the txt files.
Comment 13 Doug Moore 2020-03-07 07:21:13 UTC
If that is true, then it's a mechanical process, for someone with access to the ports patches, to undo that change, and then reapply it in a way that is conditioned so that it has no effect if the freebsd version is old enough.  That would leave it out for 12.x and leave it in for CURRENT.

I don't see what's wrong with the definition of vm_map_entry_read_succ I wrote for 12.x and put in that patch, but if the old code is just put back in for 12.x, then it doesn't matter if that definition is right or not.
Comment 14 Larry Rosenman freebsd_committer 2020-03-07 12:05:02 UTC
It also doesn't work on 13.
Comment 15 Doug Moore 2020-03-07 17:50:14 UTC
On 12/17, I sent you a patch to address a problem very much like this one on CURRENT, and you replied, in part:

"that's better, but I still get this warning:"

and so, after unrelated changes to silence that warning, I assumed that the problem was fixed on the current branch, at that time.  Was that understanding correct?

It seems now that you're saying that some change, made to the current branch after 12/17, broke lsof again, but that undoing the 12/17 lsof change fixes it again.  Is that right?

If it is, then I could install latest lsof and go binary searching for the change to current after 12/17 that broke lsof.  But I don't want to bother if my understanding of when the bug appeared is incorrect, and I'm not confident that I'm making the right inferences from your brief responses.

Do you know when lsof-4.93.2_9.8 stopped working on current (a.k.a. 13)?
Comment 16 Larry Rosenman freebsd_committer 2020-03-07 17:58:27 UTC
No, I don't and there is currently a patch from mjg (that I haven't merged in since I'm not 100% sure of what the actual change is (he hard-coded a define, but said to change it) to fix current compile issues against 13.

As to the TXT thing, I'm not 100% sure when it broke.  I had noticed it, but don't have the skills to fix it, so I just left it.

The kernel keeps changing out from under lsof and I'd love to see <someone> modernize the lsof stuff and make better interfaces. 

There is a LOT of ifdef hell for versions of FreeBSD going all the way back to 2.2.

I hope <someone> from the kernel team can help modernize the FreeBSD dialect (including making better lsof<->kernel interfaces).

I'm VERY frustrated right now with this port as I'm NOT a kernel person.
Comment 17 Mateusz Guzik freebsd_committer 2020-03-08 00:25:09 UTC
The following patches lsof to work vfs-wise on fresh -CURRENT:


Package builders which are not yet updated may get a failure until they do, which I think is fine. There was no version associated with structure change so the problem is already there.
Comment 18 Larry Rosenman freebsd_committer 2020-03-08 00:43:54 UTC
when I add that patch on top of the current patches for lsof, I get:
ler in ports/sysutils/lsof at borg
[I] ➜ make
===>  License lsof accepted by the user
===>   lsof-4.93.2_9,8 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by lsof-4.93.2_9,8 for building
===>  Extracting for lsof-4.93.2_9,8
=> SHA256 Checksum OK for lsof-org-lsof-4.93.2_GH0.tar.gz.
===>  Patching for lsof-4.93.2_9,8
===>  Applying FreeBSD patches for lsof-4.93.2_9,8
===>  Configuring for lsof-4.93.2_9,8
Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
./lockf_owner.h creation succeeded.
rm -f ddev.c dfile.c dlsof.h dmnt.c dnode*.c dproc.c dproto.h dsock.c dstore.c dzfs.h kernelbase.h machine.h machine.h.old new_machine.h __lseek.s Makefile Makefile.zfs ./tests/config.cflags
rm -f ./tests/config.cc ./tests/config.xobj ./tests/config.ldflags
Testing C library for localtime() and strftime(), using cc ... present
ln -s dialects/freebsd/dlsof.h dlsof.h
ln -s dialects/freebsd/dmnt.c dmnt.c
ln -s dialects/freebsd/dnode.c dnode.c
ln -s dialects/freebsd/dnode1.c dnode1.c
ln -s dialects/freebsd/dnode2.c dnode2.c
ln -s dialects/freebsd/dproc.c dproc.c
ln -s dialects/freebsd/dproto.h dproto.h
ln -s dialects/freebsd/dsock.c dsock.c
ln -s dialects/freebsd/dstore.c dstore.c
ln -s dialects/freebsd/dzfs.h dzfs.h
ln -s dialects/freebsd/machine.h machine.h
Makefile and lib/Makefile created.
Makefile.zfs created.
./tests/config.cc created
./tests/config.cflags created
./tests/config.ldflags created
./tests/config.xobj created
===>  Building for lsof-4.93.2_9,8
--- version.h ---
--- lib/liblsof.a ---
--- dmnt.o ---
--- dnode.o ---
--- dnode1.o ---
--- dnode2.o ---
--- dproc.o ---
--- dsock.o ---
--- dstore.o ---
--- arg.o ---
--- main.o ---
--- misc.o ---
--- node.o ---
--- print.o ---
--- proc.o ---
--- store.o ---
--- util.o ---
Constructing version.h
--- lib/liblsof.a ---
--- dmnt.o ---
--- dnode.o ---
--- dnode1.o ---
--- dproc.o ---
--- dsock.o ---
--- dstore.o ---
--- arg.o ---
--- main.o ---
--- misc.o ---
--- node.o ---
--- print.o ---
--- proc.o ---
--- store.o ---
--- util.o ---
--- dnode2.o ---
--- dnode2.o ---
cc  -pipe -fstack-protector-strong -fno-strict-aliasing -DNEEDS_BOOL_TYPEDEF -DFREEBSDV=13000 -DHAS_ZFS -DHAS_CV_TIMEDWAIT_SBT -DHAS_V_LOCKF -D_SOLARIS_C_SOURCE -O2 -I/usr/src/sys/cddl/compat/opensolaris -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/zmod -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/cddl/contrib/opensolaris/common -I/home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2/usr/src/include -I`pwd` -c dnode2.c -o dnode2.o
--- lib/liblsof.a ---
--- ckkv.o ---
--- cvfs.o ---
--- dvch.o ---
--- fino.o ---
--- isfn.o ---
--- lkud.o ---
--- pdvn.o ---
--- prfp.o ---
--- ckkv.o ---
--- cvfs.o ---
--- dvch.o ---
--- fino.o ---
--- isfn.o ---
--- pdvn.o ---
--- lkud.o ---
--- usage.o ---
--- lib/liblsof.a ---
--- prfp.o ---
--- usage.o ---
--- lib/liblsof.a ---
--- ptti.o ---
--- rdev.o ---
--- ptti.o ---
--- rdev.o ---
--- dnode2.o ---
In file included from dnode2.c:62:
In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h:33:
In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h:48:
In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_context.h:73:
In file included from /usr/src/sys/cddl/compat/opensolaris/sys/vfs.h:37:
/usr/src/sys/cddl/compat/opensolaris/sys/vnode.h:243:10: warning: implicit declaration of function 'VOP_FSYNC' is invalid in C99 [-Wimplicit-function-declaration]
        error = VOP_FSYNC(vp, MNT_WAIT, curthread);
--- dproc.o ---
dproc.c:144:13: error: variable has incomplete type 'struct pwd'
        struct pwd pwd;
dproc.c:144:9: note: forward declaration of 'struct pwd'
        struct pwd pwd;
dproc.c:334:23: warning: implicit declaration of function 'FILEDESC_KVM_LOAD_PWD' is invalid in C99 [-Wimplicit-function-declaration]
            pwd_addr = (KA_T)FILEDESC_KVM_LOAD_PWD(&fd);
1 warning and 1 error generated.
*** [dproc.o] Error code 1

make[1]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2
--- dnode1.o ---
In file included from dnode1.c:148:
In file included from /usr/src/sys/fs/fuse/fuse_node.h:72:
/usr/src/sys/fs/fuse/fuse_file.h:214:33: warning: declaration of 'struct fuse_open_out' will not be visible outside of this function [-Wvisibility]
                          struct ucred *cred, struct fuse_open_out *foo);
In file included from dnode1.c:148:
/usr/src/sys/fs/fuse/fuse_node.h:142:2: warning: implicit declaration of function 'getbinuptime' is invalid in C99 [-Wimplicit-function-declaration]
/usr/src/sys/fs/fuse/fuse_node.h:174:3: warning: implicit declaration of function 'MPASS' is invalid in C99 [-Wimplicit-function-declaration]
                MPASS(dvp->v_type == VDIR);
/usr/src/sys/fs/fuse/fuse_node.h:187:45: warning: declaration of 'struct fuse_entry_out' will not be visible outside of this function [-Wvisibility]
int fuse_vnode_get(struct mount *mp, struct fuse_entry_out *feo,
4 warnings generated.
--- lib/liblsof.a ---
A failure has been detected in another branch of the parallel make

make[2]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2/lib
*** [lib/liblsof.a] Error code 2

make[1]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2
--- dnode2.o ---
1 warning generated.
A failure has been detected in another branch of the parallel make

make[2]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2
*** [dnode2.o] Error code 2

make[1]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2
3 errors

make[1]: stopped in /home/ler/FreeBSD/ports/sysutils/lsof/work/lsof-4.93.2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

make: stopped in /home/ler/FreeBSD/ports/sysutils/lsof

ler in ports/sysutils/lsof at borg took 8s
[I] ➜

So we still have issues.
ler in ports/sysutils/lsof at borg
[I] ➜ svn diff
Index: files/patch-dialects_freebsd_dproc.c
--- files/patch-dialects_freebsd_dproc.c	(revision 527257)
+++ files/patch-dialects_freebsd_dproc.c	(working copy)
@@ -1,6 +1,98 @@
 --- dialects/freebsd/dproc.c.orig	2019-05-08 07:32:25 UTC
 +++ dialects/freebsd/dproc.c
-@@ -655,7 +655,29 @@ kread(addr, buf, len)
+@@ -37,6 +37,14 @@ static char *rcsid = "$Id: dproc.c,v 1.20 2018/02/14 1
+ #include "lsof.h"
++ * This is not an exact version but it should not matter. At worst there
++ * is a small version window where this lsof does not compile on older
++ * -CURRENT.
++ */
++#if __FreeBSD_version >= 1300081
++#define HAS_PWD
+ _PROTOTYPE(static void enter_vn_text,(KA_T va, int *n));
+ _PROTOTYPE(static void get_kernel_access,(void));
+@@ -132,6 +140,15 @@ gather_proc_info()
+ 	KA_T fa;
+ #endif	/* defined(HAS_FDESCENTTBL) */
++#if	defined(HAS_PWD)
++	struct pwd pwd;
++	KA_T pwd_addr;
++#endif	/* defined(HAS_FDESCENTTBL) */
++	struct vnode *cdir;
++	struct vnode *rdir;
++	struct vnode *jdir;
+ 	static ofb_t *ofb = NULL;
+ 	static int ofbb = 0;
+ 	int pgid, pid;
+@@ -312,6 +329,22 @@ gather_proc_info()
+ 		continue;
+ #endif	/* defined(HAS_FDESCENTTBL) */
++#if	defined(HAS_PWD)
++	    cdir = rdir = jdir = NULL;
++	    pwd_addr = (KA_T)FILEDESC_KVM_LOAD_PWD(&fd);
++	    if (pwd_addr != 0) {
++		    if (!kread(pwd_addr, (char *)&pwd, sizeof(pwd))) {
++			    cdir = pwd.pwd_cdir;
++			    rdir = pwd.pwd_rdir;
++			    jdir = pwd.pwd_jdir;
++		    }
++	    }
++	    cdir = fd.fd_cdir;
++	    rdir = fd.fd_rdir;
++	    jdir = fd.fd_jdir;
+ 	/*
+ 	 * Allocate a local process structure.
+ 	 */
+@@ -347,20 +380,20 @@ gather_proc_info()
+ 	/*
+ 	 * Save current working directory information.
+ 	 */
+-	    if (!ckscko && fd.fd_cdir) {
++	    if (!ckscko && cdir) {
+ 		alloc_lfile(CWD, -1);
+ 		Cfp = (struct file *)NULL;
+-		process_node((KA_T)fd.fd_cdir);
++		process_node((KA_T)cdir);
+ 		if (Lf->sf)
+ 		    link_lfile();
+ 	    }
+ 	/*
+ 	 * Save root directory information.
+ 	 */
+-	    if (!ckscko && fd.fd_rdir) {
++	    if (!ckscko && rdir) {
+ 		alloc_lfile(RTD, -1);
+ 		Cfp = (struct file *)NULL;
+-		process_node((KA_T)fd.fd_rdir);
++		process_node((KA_T)rdir);
+ 		if (Lf->sf)
+ 		    link_lfile();
+ 	    }
+@@ -369,10 +402,10 @@ gather_proc_info()
+ 	/*
+ 	 * Save jail directory information.
+ 	 */
+-	    if (!ckscko && fd.fd_jdir) {
++	    if (!ckscko && jdir) {
+ 		alloc_lfile("jld", -1);
+ 		Cfp = (struct file *)NULL;
+-		process_node((KA_T)fd.fd_jdir);
++		process_node((KA_T)jdir);
+ 		if (Lf->sf)
+ 		    link_lfile();
+ 	    }
+@@ -655,7 +688,29 @@ kread(addr, buf, len)
  	return((br == len) ? 0 : 1);

@@ -30,7 +122,7 @@
   * process_text() - process text information
-@@ -682,20 +704,15 @@ process_text(vm)
+@@ -682,20 +737,15 @@ process_text(vm)
   * Read the vm_map structure.  Search its vm_map_entry structure list.

ler in ports/sysutils/lsof at borg
[I] ➜
Comment 19 Mateusz Guzik freebsd_committer 2020-03-08 00:55:40 UTC
I noted you need fresh head. The patch is valid as of r358734
Comment 20 Larry Rosenman freebsd_committer 2020-03-08 02:53:50 UTC
Ok, it now compiles, but we still have the txt problem.

I'll commit this change, however for the VFS issue.
Comment 21 Larry Rosenman freebsd_committer 2020-03-08 02:54:02 UTC
ler in usr/local/sbin at borg
[I] ➜ sudo ./lsof -p $$
lsof: WARNING: device cache mismatch: /dev/gptid/af5f1ebd-ecda-11e6-a88b-a4badb296695
zsh     4000  ler  cwd   VDIR 3461153700,1844502150        3 3344396 /home/ler/FreeBSD/ports/sysutils/lsof/work/stage/usr/local/sbin
zsh     4000  ler  rtd   VDIR 2806855255,3159875135       31       4 /
zsh     4000  ler    0u  VCHR                 0,244  0t31118     244 /dev/pts/1
zsh     4000  ler    1u  VCHR                 0,244  0t31118     244 /dev/pts/1
zsh     4000  ler    2u  VCHR                 0,244  0t31118     244 /dev/pts/1
zsh     4000  ler   10u  VCHR                 0,244  0t17564     244 /dev/pts/1
zsh     4000  ler   11r  VREG 2058978179,1939660364    60888  287365 /usr/local/share/zsh/5.8/functions/VCS_Info.zwc
zsh     4000  ler   12r  VREG 2058978179,1939660364    79096  287367 /usr/local/share/zsh/5.8/functions/VCS_Info/Backends.zwc
zsh     4000  ler   13r  VREG 2058978179,1939660364   200448  287267 /usr/local/share/zsh/5.8/functions/Misc.zwc
zsh     4000  ler   15r  VREG 2058978179,1939660364   189424  284013 /usr/local/share/zsh/5.8/functions/Completion.zwc
zsh     4000  ler   16r  VREG 2058978179,1939660364    91752  287314 /usr/local/share/zsh/5.8/functions/Prompts.zwc
zsh     4000  ler   17r  VREG 2058978179,1939660364   290328  286134 /usr/local/share/zsh/5.8/functions/Completion/Base.zwc
zsh     4000  ler   19r  VREG 2058978179,1939660364   194512  287463 /usr/local/share/zsh/5.8/functions/Zle.zwc
zsh     4000  ler   21r  VREG 2058978179,1939660364   291592  287120 /usr/local/share/zsh/5.8/functions/Completion/Zsh.zwc
zsh     4000  ler   22r  VREG 2058978179,1939660364  5205696  286444 /usr/local/share/zsh/5.8/functions/Completion/Unix.zwc
lsof: WARNING: /root/.lsof_borg was updated.

ler in usr/local/sbin at borg
[I] ➜ sudo ldd ./lsof
	libkvm.so.7 => /lib/libkvm.so.7 (0x800263000)
	libc.so.7 => /lib/libc.so.7 (0x800276000)
	libelf.so.2 => /lib/libelf.so.2 (0x80068d000)

ler in usr/local/sbin at borg
[I] ➜
Comment 22 Larry Rosenman freebsd_committer 2020-03-08 02:55:28 UTC
SVN r527995.
Comment 23 Jamie Landeg-Jones 2022-05-21 01:20:26 UTC
Hi Larry! I decided to have a look at the missing "txt" entries with lsof.

I'm not a kernel guy, and additionally I couldn't find documentation on some
of the latest vm changes, but here's what I managed to work out.

TL;DR : Attached patch fixes "txt" on FreeBSD 12 (and 11). It doesn't make
things worse on FreeBSD 13, but it could always be ifdef'ed out if you want!

Hopefully there is enough in here to prompt someone familiar with the vm
to know straight away what this issues with 13 are!


"txt" stopped appearing with update lsof-4.93.2_6,8

The particular patch is:


Reverting this patch on freebsd11 and freebsd12 makes 'txt' appear again,
but of course, fails to compile on FreeBSD 13.

Looking at this patch, a new function "vm_map_entry_read_succ" is used in

"vm_map_entry_read_succ" calls "reader" (vm_map_entry_reader) which seems
to always exit with NULL regardless (I cannot find documentation on this
function though, so it's hard to tell for sure)


 | static inline vm_map_entry_t
 | vm_map_entry_read_succ(void *token, struct vm_map_entry *const clone,
 |      vm_map_entry_reader reader)
 | {
 |      vm_map_entry_t next;
 |      next = clone->next;
 |      if (!reader(token, next, clone))
 |              return (NULL);
 |      return (next);
 | }

This is called within the patch as:

|       if (!vm_map_entry_read_succ(NULL, e, vm_map_reader))
|               return;

So, the returned value is only tested to see if the function exited correctly
(the result of the function, "next", is also returned into "e"), and in all my
tests (freebsd11/12/13) it always is NULL, due to the return value of "reader".

So, changing the call to:

        (void) vm_map_entry_read_succ(NULL, e, vm_map_reader);

allows txt to continue to be processed directly (I'm unhappy with not knowing
what's going on with "reader", but can't find out why/what it is returning
NULL to examine it further)

Anyway, with the above change, txt is now working on 11 and 12. On FreeBSD13,
due to structure changes, instead of outputting the vnode filename, it outputs
the partition the vnode resides on.

And here, I'm getting more lost, so this is probably wrong, but here goes:

In addition, on FreeBSD13, the process_text function, which pulls in the text
entries, appears to read the wrong information at times (the kread appears to
read duplicate vnodes. lsof filters out the duplicates, but it means that many
of the txt entries are missing altogether)

I hope this helps a bit, anyway!

Cheers, Jamie
Comment 24 Jamie Landeg-Jones 2022-05-21 01:22:39 UTC
Created attachment 234068 [details]
fixes txt on FreeBSD 12 and FreeBSD 11