Re: lsof on Debian FreeBSD
Hi!
On 20/04/12 00:45, Nicholas Bamber wrote:
>> 8.6 Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
>> ... Lsof needs to access elements of that
>> lockf_owner structure to determine if a lock belongs to the
>> process that has a file open.
The goal really is to keep userland tools out of kernel internals to
produce better software; that's one of many good things I hope will
come as a side effect out of the GNU/kFreeBSD effort.
Since the 'freebsd' dialect of lsof has been relying on kernel internals
for some time, I expect that code will be in pretty bad shape. You
could try to get what you need from the kfreebsd source but I think it
would be a bad idea. (A kernel with an incompatible definition might be
booted at any time, and no dpkg dependency can help with that).
However, if the 'linux' dialect does not depend on kernel source code I
think that would make a better starting point.
I tried just now with the freebsd/machine.h and Makefile, but replaced
the symlinks to use dialect/linux code instead, except for node1/2 and
zfs. That way I even managed to build something, which almost looks
like it works:
> steven@kfreebsd-i386:~/lsof-4.81.dfsg.1+wtf$ ./lsof -c lsof
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> lsof 99812 steven cwd DIR 92,2340356138 72 15497 /home/steven/lsof-4.81.dfsg.1+wtf
> lsof 99812 steven rtd DIR 0,71 512 2 /
> lsof 99812 steven txt REG 92,2340356138 145071 15837 /home/steven/lsof-4.81.dfsg.1+wtf/lsof
> lsof 99812 steven mem REG 0,0 15837 /home/steven/lsof-4.81.dfsg.1+wtf/lsof (path dev=92,-1954611158)
> lsof 99812 steven mem REG 0,0 117963 /lib/i386-kfreebsd-gnu/ld-2.13.so (path dev=0,71)
> lsof 99812 steven mem REG 0,0 213682 /etc/ld.so.cache (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117953 /lib/libkvm.so.0 (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117809 /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.13.so (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117827 /lib/i386-kfreebsd-gnu/libbsd.so.0.3.0 (path dev=0,71)
> lsof 99812 steven mem REG 0,0 108648 /usr/lib/locale/locale-archive (path dev=164,284950746)
> lsof 99812 steven mem REG 0,0 117898 /lib/i386-kfreebsd-gnu/i686/cmov/libnss_compat-2.13.so (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117829 /lib/i386-kfreebsd-gnu/i686/cmov/libnsl-2.13.so (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117834 /lib/i386-kfreebsd-gnu/i686/cmov/libnss_nis-2.13.so (path dev=0,71)
> lsof 99812 steven mem REG 0,0 117838 /lib/i386-kfreebsd-gnu/i686/cmov/libnss_files-2.13.so (path dev=0,71)
> lsof 99812 steven NOFD /proc/99812/fd (opendir: No such file or directory)
> lsof 99813 steven cwd DIR 92,2340356138 72 15497 /home/steven/lsof-4.81.dfsg.1+wtf
> lsof 99813 steven rtd DIR 0,71 512 2 /
> lsof 99813 steven txt REG 92,2340356138 145071 15837 /home/steven/lsof-4.81.dfsg.1+wtf/lsof
> lsof 99813 steven mem REG 0,0 15837 /home/steven/lsof-4.81.dfsg.1+wtf/lsof (path dev=92,-1954611158)
> lsof 99813 steven mem REG 0,0 117963 /lib/i386-kfreebsd-gnu/ld-2.13.so (path dev=0,71)
> lsof 99813 steven mem REG 0,0 213682 /etc/ld.so.cache (path dev=0,71)
> lsof 99813 steven mem REG 0,0 117953 /lib/libkvm.so.0 (path dev=0,71)
> lsof 99813 steven mem REG 0,0 117809 /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.13.so (path dev=0,71)
> lsof 99813 steven mem REG 0,0 117827 /lib/i386-kfreebsd-gnu/libbsd.so.0.3.0 (path dev=0,71)
> lsof 99813 steven mem REG 0,0 108648 /usr/lib/locale/locale-archive (path dev=164,284950746)
> lsof 99813 steven NOFD /proc/99813/fd (opendir: No such file or directory)
Sadly though we're missing /proc/*/fd in linprocfs as you can see. :(
No pipes, network or unix-style sockets can be listed either. So it's
not very functional yet, but being able to build something is a start.
To build this I had to change declarations in machine.h to turn off each
bit of code that touches the structs usually guarded by #ifdef _KERNEL
as seen in:
http://fxr.watson.org/fxr/source/sys/file.h?v=FREEBSD9#L40
I'll try to turn this into some sort of diff. The approach I'd like to
take is to add ifdefs into the linux dialect to make that more portable,
rather than invent a new one.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: