[ SEA-GHOST MINI SHELL]
Frequently Asked Questions about lsof
**********************************************************************
| The latest release of lsof is always available via anonymous ftp |
| from lsof.itap.purdue.edu. Look in pub/lsof.README for its |
| location. |
**********************************************************************
______________________________________________________________________
This file contains frequently asked questions about lsof and answers
to them.
Vic Abell <abe@purdue.edu>
January 3, 2013
______________________________________________________________________
Table of Contents:
1.0 General Concepts
1.1 Lsof -- what is it?
1.2 Where do I get lsof?
1.2.1 Are there mirror sites?
1.2.2 Are lsof executables available?
1.2.3 How do I check the validity of an lsof distribution?
1.2.4 Why can't I get the sum(1) result reported in
README.lsof_<revision>?
1.2.5 Why won't gpg accept the lsof-signing PGP public key?
1.3 Where can I get more lsof documentation?
1.4 How do I report an lsof bug?
1.5 Where can I get the lsof FAQ?
1.5.1 How timely is the on-line FAQ?
1.6 Is there a test suite?
1.7 Is lsof vulnerable to the standard I/O descriptor attack?
1.8 Can I alter lsof's make(1) behavior?
1.9 Is there an lsof license?
1.10 Language locale support
1.10.1 Does lsof support language locales? How do I use the support?
1.10.2 Does lsof support wide characters in language locales?
1.11 Are any files in the lsof distribution copyrighted?
1.12 Are there other lsof-related resources?
1.13 What does the "WARNING: unsupported dialect or version" mean?
2.0 Lsof Ports
2.1 What ports exist?
2.2 What about a new port?
2.2.1 User-contributed Ports
2.3 Why isn't there an AT&T SVR4 port?
2.4 Why isn't there an SGI IRIX port?
2.5 Why does lsof's Configure script report "WARNING: unsupported
dialect or version"?
3.0 Lsof Problems
3.1 Configuration Problems
3.1.1 Why can't Configure determine the UNIX dialect version?
3.2 Compilation Problems
3.2.1 Why does the compiler complain about missing header files?
3.2.2 Why does gcc complain about the contents of header files
distributed by the system's vendor?
3.2.3 Other header file problems
3.3 Why doesn't lsof report full path names?
3.3.1 Why do lsof -r reports show different path names?
3.3.2 Why does lsof report the wrong path names?
3.3.3 Why doesn't lsof report path names for unlinked (rm'd) files?
3.3.4 Why doesn't lsof report the "correct" hard linked file path
name?
3.3.5 When will lsof report path names for deleted files?
3.4 Why is lsof so slow?
3.5 Why doesn't lsof's setgid or setuid permission work?
3.6 Does lsof have security problems?
3.7 Will lsof show remote hosts using files via NFS?
3.8 Why doesn't lsof report locks held on NFS files?
3.8.1 Why does lsof report a one byte lock on byte zero as a full
file lock?
3.9 Why does lsof report different values for open files on the
same file system (the automounter phenomenon)?
3.10 Why don't lsof and netstat output match?
3.10.1 Why can't lsof find accesses to some TCP and UDP ports?
3.11 Why does lsof update the device cache file?
3.12 Why doesn't lsof report state for UDP socket files?
3.13 I am editing a file with vi; why doesn't lsof find the file?
3.14 Why doesn't lsof report TCP/TPI window and queue sizes for my
dialect?
3.14.1 Why doesn't lsof report socket options, socket states, and TCP
flags and values for my dialect?
3.14.2 Why doesn't lsof report the partial listen queue connection
count for my dialect?
3.15 What does "no more information" in the NAME column mean?
3.16 Why doesn't lsof find a process that ps finds?
3.17 Why doesn't -V report a search failure?
3.18 Portmap problems
3.18.1 Why isn't a name displayed for the portmap registration?
3.18.2 How can I display only portmap registrations?
3.18.3 Why doesn't lsof report portmap registrations for some ports?
3.18.4 Why doesn't lsof report portmap registrations for some Solaris
versions?
3.19 Why is `lsof | wc` bigger than my system's open file limit?
3.20 Why doesn't lsof report file offset (position)?
3.20.1 What does lsof report for size when the file doesn't really have
one?
3.21 Problems with path name arguments
3.21.1 How do I ask lsof to search a file system?
3.21.2 Why doesn't lsof find all the open files in a file system?
3.21.3 Why does the lsof exit code report it didn't find open files
when some files were listed?
3.21.4 Why won't lsof find all the open files in a directory?
3.21.5 Why are the +D and +d options so slow?
3.21.6 Why do the +D and +d options produce warning messages?
3.22 Why can't my C compiler find the rpcent structure definition?
3.23 Why doesn't lsof report fully on file "foo" on UNIX dialect
"bar?"
3.24 Why do I get a complaint when I execute lsof that some library
file can't be found?
3.25 Why does lsof complain it can't open files?
3.26 Why does lsof warn "compiled for x ... y; this is z."?
3.27 How can I disable the kernel identity check?
3.28 Why don't ps(1) and lsof agree on the owner of a process?
3.29 Why doesn't lsof find an open socket file whose connection
state is past CLOSE_WAIT?
3.30 Why don't machine.h definitions work when the surrounding
comments are removed?
3.31 What do "can't read inpcb at 0x...", "no protocol control
block", "no PCB, CANTSENDMORE, CANTRCVMORE", etc. mean?
3.32 What do the "unknown file system type" warnings mean?
3.33 Installation
3.33.1 How do I install lsof?
3.33.2 How do I install a common lsof when I have machines that
need differently constructed lsof binaries?
3.34 Why do lsof 4.53 and above reject device cache files built
by earlier lsof revisions?
3.35 What do "like block special" and "like character special" mean
in the NAME column?
3.36 Why does an lsof make fail because of undefined symbols?
3.37 Command Regular Expressions (REs)
3.37.1 What are basic and extended regular expressions?
3.37.2 Why can't I put a slash in a command regular expression?
3.37.3 Why does lsof say my command regular expression wasn't found?
3.38 Why doesn't lsof report on shared memory segments?
3.39 Why does lsof report two instances of itself?
3.40 Why does lsof report '\n' in device cache file error messages?
3.41 Kernel Symbol and Address Problems
3.41.1 What does "lsof: WARNING: name cache hash size length error: 0"
mean?
3.41.2 Why does lsof produce "garbage" output?
3.42 Why does lsof report open files when run as super user that
it doesn't report when run with lesser privileges?
3.43 Test Suite Problems
3.43.1 Errors all tests can report:
3.43.1.1 Why do tests complain "ERROR!!! can't execute ../lsof"?
3.43.1.2 Why do tests complain "ERROR!!! can't find ..." a file?
3.43.1.3 Why do some tests fail to compile?
3.43.1.4 Why do some tests always fail?
3.43.1.5 Why does the test suite say it hasn't been validated on
my dialect?
3.43.1.6 Why do the tests complain they can't stat() or open()
/dev/mem or /dev/kmem?
3.43.2 LTbigf test issues
3.43.2.1 Why does the LTbigf test say that the dialect doesn't
support large files?
3.43.2.2 Why does LTbigf complain about operations on its config.LTbigf*
file?
3.43.2.3 Why does LTbigf warn that lsof doesn't return file offsets?
3.43.3 Why does the LTbasic test complain "ERROR!!! lsof this ..."
and "ERROR!!! lsof that ..."?
3.43.4 LTnfs test issues
3.43.4.1 Why does the LTnfs test complain "couldn't find NFS file ..."?
3.43.5 LTnlink test issues
3.43.5.1 Why does the LTnlink test complain that its test file is on
an NFS file system?
3.43.5.2 Why does LTnlink delay and report "waiting for link count
update: ..."?
3.43.5.3 Why does LTnlink fail because of an unlink error?
3.43.6 LTdnlc test issues
3.43.6.1 Why won't the LTdnlc test run?
3.43.6.2 What does the LTdnlc test mean by "... <path> found: 100.00%"?
3.43.6.3 Why does the DNLC test fail?
3.43.7 Why hasn't the test suite been qualified for 64 bit HP-UX
11 when lsof is compiled with gcc?
3.43.8 LTszoff test issues
3.43.8.1 Why does LTszoff warn that lsof doesn't return file offsets?
3.43.9 LTlock test issues
3.44 File descriptor list (the ``-d'' option) problems
3.44.1 Why does lsof reject a ``-d'' FD list?
3.44.2 Why are file descriptors other than those in my FD list
reported?
3.45 How can I supply device numbers for inaccessible NFS file
systems?
3.46 Why won't lsof find open files on over-mounted file systems?
3.47 What can be done when lsof reports no more space?
3.48 What if the lsof build encounters ar and ld problems?
3.49 Why does lsof -i report an open socket file for a process, but
lsof -p on that process' ID report nothing?
4.0 AIX Problems
4.1 What is the Stale Segment ID bug and why is -X needed?
4.1.1 Stale Segment ID APAR
4.2 Gcc Work-around for AIX 4.1x
4.3 Gcc and AIX 4.2
4.4 Why won't lsof's Configure allow the use of gcc for AIX
below 4.1?
4.5 What is an AIX SMT file type?
4.6 Why does AIX lsof start so slowly?
4.7 Why does exec complain it can't find libc.a[shr.o]?
4.8 What does lsof mean when it says, "TCP no PCB, CANTSENDMORE,
CANTRCVMORE" in a socket file's NAME column?
4.9 When the -X option is used on AIX 4.3.3, why does lsof disable
it, saying "WARNING: user struct mismatch; -X option disabled?"
4.10 Why doesn't the -X option work on my AIX 5L or 5.[123] system?
4.11 Why doesn't /usr/bin/oslevel report the correct AIX version?
4.11.1 Why doesn't /usr/bin/oslevel report the correct AIX version
on AIX 5.1?
4.12 Why does lsof for AIX 5.1 or above Power architecture
complain about kernel bit size?
4.13 What can't gcc be used to compile lsof on the ia64 architecture
for AIX 5 and above?
4.14 Why does lsof get a segmentation fault when compiled with gcc
for a 64 bit Power architecture AIX 5.1 kernel?
4.15 Why does lsof ignore AFS on my AIX system?
4.16 Why does lsof report "system paging space is low" and exit?
4.17 Why does lsof have compilation and execution problems on AIX
5.3 above maintenance level 1?
5.0 Apple Darwin Problems
5.1 What do /dev/kmem-based and libproc-based mean?
5.2 /dev/kmem-based Apple Darwin Questions
5.2.1 Why does Configure ask for a path to the Darwin XNU kernel
header files?
5.2.1.1 Why does Configure complain that Darwin XNU kernel header
files are missing?
5.2.2 Why doesn't Apple Darwin lsof report text file information?
5.2.3 Why doesn't Apple Darwin lsof support IPv6?
5.2.4 Why does lsof complain about a mismatch between the release
for which lsof was compiled and the booted Mac OS X release?
5.2.5 Why does lsof for Apple Darwin 8 and higher report
"stat(...): ..." in the NAME column?
5.2.6 What are the limitations of Apple Darwin lsof link count
reporting?
5.2.7 Why does Apple Darwin report process group IDs incorrectly?"ayy
5.3 Libproc-based Apple Darwin Questions
6.0 BSD/OS BSDI Problems
6.0.5 Statement of deprecation
7.0 DEC OSF/1, Digital UNIX, and Tru64 UNIX Problems
7.1 Why does lsof complain about non-existent /dev/fd entries?
7.2 Why does the Digital UNIX V3.2 ld complain about Ots* symbols?
7.3 Why can't lsof locate named pipes (FIFOs) under V3.2?
7.4 Why does lsof use the wrong configuration header files?
For example, why can't the lsof compilation find cpus.h?
7.5 Why does lsof indicate incomplete paths with " -- " for Tru64
UNIX 5.1 files?
7.6 Why doesn't lsof report link count, node number, and size
for some Tru64 5.x CFS files?
7.7 Why does lsof say it can't read the kernel name list or
proc table on Digital UNIX 4.x or Tru64 UNIX?
8.0 FreeBSD Problems
8.1 Why doesn't lsof report on open kernfs files?
8.2 Why doesn't lsof work on my FreeBSD system?
8.3 Why doesn't lsof work on the RELEASE version of CURRENT?
8.4 Why can't kvm_open() can't find some file?
8.5 FreeBSD ZFS Problems
8.5.1 Why does FreeBSD lsof report "WARNING: no ZFS support has been
8.6 Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
8.6.1 Why are there lockf structure compiler errors for FreeBSD 6.0
and higher lsof?
8.6.2 Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h
match?
8.7 FreeBSD and clang
8.7.1 Why does clang complain about VOP_FSYNC?
9.0 HP-UX Problems
9.1 What do /dev/kmem-based and PSTAT-based mean?
9.2 /dev/kmem-based HP-UX lsof Questions
9.2.1 Why doesn't a /dev/kmem-based HP-UX lsof compilation use -O?
9.2.2 Why doesn't the /dev/kmem-based CCITT support work under 10.x?
9.2.3 Why can't /dev/kmem-based lsof be compiled with `cc -Aa` or
`gcc -ansi` under HP-UX 10.x?
9.2.4 Why does /dev/kmem-based lsof complain about no C compiler?
9.2.5 Why does Configure complain about q4 for /dev/kmem-based lsof
for HP-UX 11?
9.2.6 When compiling /dev/kmem-based lsof for HP-UX 11 what do the
"aCC runtime: ERROR..." messages mean?
9.2.7 Why doesn't /dev/kmem-based lsof for HP-UX 11 report VxFS file
link counts, node numbers, and sizes correctly?
9.2.8 Why can't /dev/kmem-based lsof be built with gcc for 64 bit
HP-UX 11?
9.2.8.1 How can I acquire a gcc for building lsof for 64 bit HP-UX 11?
9.2.9 Why does /dev/kmem-based lsof for HP-UX 11 report "unknown file
system type" for VxFS files?
9.2.10 Why does the ANSI-C compiler complain about comments in HP-UX
11 header files?
9.2.11 Why does dnode1.c cause the HP-UX 11 compiler to complain that
<sys/fs/vx_inode.h> is missing or incorrect?
9.3 PSTAT-based HP-UX lsof Questions
9.3.1 Why does PSTAT-based lsof complain about pst_static and
other PSTAT structures?
9.3.2 Why does PSTAT-based lsof complain it can't read pst_*
structures?
9.3.3 Why does PSTAT-based lsof rebuild the device cache file
after each reboot?
9.3.4 Why doesn't PSTAT-based lsof report TCP addresses for
telnetd's open socket files?
9.3.5 Why does PSTAT-based lsof cause an HP-UX 11.11 kernel panic?
9.3.6 Why doesn't PSTAT-based lsof report a CWD that is on a loopback
(LOFS) file system?
9.3.7 Why do some swinstall packages for PSTAT-based HP-UX 11.11
packages complain about setgid and setuid bits?
9.3.8 Why won't the bundled C compiler build PSTAT-based lsof for
PA-RISC HP-UX 11.23?
9.3.9 Why won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?
9.3.10 Why does PSTAT-based lsof complain, "FATAL: pst_stream_size
should be: 672; is 72" on HP-UX 11.11 and above?
9.4 Why won't the HP-UX depot install?
10.0 Linux Problems
10.1 What do /dev/kmem-based and /proc-based lsof mean?
10.2 /proc-based Linux lsof Questions
10.2.1 Why doesn't /proc-based lsof report file offsets (positions)?
10.2.2 Why does /proc-based lsof report "can't identify protocol" for
some socket files?
10.2.3 Why does /proc-based lsof warn about unsupported formats?
10.2.4 Why does /proc-based lsof report "(deleted)" after a path name?
10.2.5 Why doesn't /proc-based lsof report full open file information
for all processes?
10.2.6 Why won't Customize offer to change HASDCACHE or WARNDEVACCESS
for /proc-based lsof?
10.2.7 /proc-based lsof Linux NFS questions
10.2.7.1 Why can't lsof find files on an accessible NFS file system?
10.2.7.2 Why can't lsof find files on an inaccessible NFS file system?
10.2.8 Why doesn't /proc-based Linux lsof report socket options and
values, socket state flags, and TCP options and values?
10.2.9 Does /proc-based Linux lsof use a device cache?
10.2.10 Why doesn't /proc-based Linux lsof report any or all file structure
values for its +fcfgGn option?
10.3 Special Linux file types
10.3.1 Why is ``DEL'' reported as a Linux file type?
10.3.2 Why is ``unknown'' reported as a Linux file type?
10.4 Linux ``mem'' Entry Problems
10.4.1 What do ``path dev=xxx'' and ``path inode=yyy'' mean in the
NAME column of Linux ``mem'' file types?
10.4.2 Why is neither link count nor size reported for some Linux
``DEL'' and ``mem'' file types?
10.5 Special Linux NAME column messages
10.5.1 What does ``(stat: xxx)'' mean in the NAME column of Linux
files?
10.5.2 What does ``(readlink: xxx)'' mean in the NAME column of
Linux files?
10.6 Why is ``NOFD'' reported as a Linux file type?
10.7 Why does Linux lsof report a NAME column value that begins with
``/proc''?
10.8 Linux /proc/net/tcp* and /proc/net/udp* issues
10.8.1 Why use the Linux -X option?
10.8.2 Why does lsof say ``-i is useless when -X is specified''?
10.8.3 Why does lsof say ``can't identify protocol (-X specified)''?
11.0 NetBSD Problems
11.1 Why doesn't lsof report on open kernfs files?
11.2 Why doesn't lsof report on open files on: file descriptor
file systems; /proc file systems; 9660 (CD-ROM) file systems;
MS-DOS (floppy disk) file systems; or kernel file systems?
11.3 Why does lsof produce confusing results for nullfs file
systems?
11.4 NetBSD header file problems
11.4.1 Why can't the compiler find some NetBSD header files?
11.4.2 Why does NetBSD lsof produce incorrect output?
11.5 Why isn't lsof feature xxx enabled for NetBSD?
12.0 NEXTSTEP and OPENSTEP Problems
12.1 Why can't lsof report on 3.1 lockf() or fcntl(F_SETLK)
locks?
12.2 Why doesn't lsof compile for NEXTSTEP with AFS?
13.0 OpenBSD Problems
13.1 Why doesn't lsof support kernfs on my OpenBSD system?
13.2 Will lsof work on OpenBSD on non-x86-based architectures?
13.3 <sys/pipe.h> problems
13.3.1 Why does the compiler claim nbpg isn't defined?
13.3.2 What value should I assign to nbpg?
13.4 Why doesn't lsof report on open MS-DOS file system (floppy
disk) files?
13.5 Why isn't lsof feature xxx enabled for OpenBSD?
14.0 Output problems
14.1 Why do the lsof column sizes change?
14.2 Why does the offset have ``0t' and ``0x'' prefixes?
14.3 What are the values printed in the FILE_FLAG column
and why is 0x<value> sometimes included?
14.3.1 Why doesn't lsof display FILE_FLAG values for my dialect?
14.4 Network Addresses
14.4.1 Why does lsof's -n option cause IPv4 addresses, mapped to
IPv6, to be displayed in IPv6 notation?
14.5 Why does lsof output \x, ^x, or \xnn for characters
sometimes?
14.5.1 Why is space considered a non-printable character in command
names?
14.6 Why doesn't lsof print all the characters of a command name?
14.7 Why does lsof reject some -c command names, saying their lengths
are "> what system provides (nn)"?
14.8 Why does lsof sometimes print TYPE numbers instead of names?
14.9 Marker line format problems
14.9.1 Why won't lsof accept a marker line format?
14.9.2 Why does lsof reject the NL (%n) marker line format?
14.10 How are protocol state name exclusion and inclusion used?
14.10.1 Why doesn't my dialect support state name exclusion and inclusion?
15.0 Pyramid Version Problems
15.0.5 Statement of deprecation
16.0 SCO Problems
16.1 SCO OpenServer Problems
16.1.1 How can I avoid segmentation faults when compiling lsof?
16.1.2 Where is libsocket.a?
16.1.3 Why do I get "warning C4200" messages when I compile lsof?
16.2 SCO|Caldera UnixWare Problems
16.2.1 Why doesn't lsof compile on my UnixWare 7.1.1 or above
system?
16.2.2 Why does lsof complain about node_self() on my UnixWare
7.1.1 or above system?
16.2.3 Why does UnixWare 7.1.1 or above complain about -lcluster,
node_self(), or libcluster.so?
16.2.4 Why does UnixWare 7.1.1 or above lsof complain it can't
read the kernel name list?
16.2.5 Why doesn't lsof report link count, node number, and size
for some UnixWare 7.1.1 or above CFS files?
16.2.6 Why doesn't lsof report open files on all UnixWare 7.1.1
NonStop Cluster (NSC) nodes?
16.2.7 Why doesn't lsof report the UnixWare 7.1.1 NonStop Cluster
(NSC) node a process is using?
16.2.8 Why does the compiler complain about missing UnixWare 2.1[.x]
header files?
17.0 Sun Problems
17.0.5 Statement of deprecation
17.1 My Sun gcc-compiled lsof doesn't work -- why?
17.2 How can I make lsof compile with gcc under Solaris 2.[456],
2.5.1, 7, 8 or 9?
17.3 Why does Solaris Sun C complain about system header files?
17.4 Why doesn't lsof work under my Solaris 2.4 system?
17.5 Where are the Solaris header files?
17.6 Where is the Solaris /usr/src/uts/<architecture>/sys/machparam.h?
17.7 Why does Solaris lsof say ``can't read proc table''?
17.8 Why does Solaris lsof complain about a bad cached clone device?
17.9 Why doesn't Solaris make generate .o files?
17.10 Why does lsof report some Solaris 2.3 and 2.4 lock types as `N'?
17.11 Why does lsof Configure say "WARNING: no cc in ..."?
17.12 Solaris 7, 8 and 9 Problems
17.12.1 Why does lsof say the compiler isn't adequate for Solaris
7, 8 or 9?
17.12.2 Why does Solaris 7, 8 or 9 lsof say "FATAL: lsof was compiled
for..."?
17.12.3 How do I build lsof for a 64 bit Solaris kernel under a 32
bit Solaris kernel?
17.12.4 How do I install lsof for Solaris 7, 8 or 9?
17.12.5 Why does my Solaris 7, 8 or 9 system say it cannot execute
lsof?
17.12.6 What gcc will produce 64 bit Solaris 7, 8 and 9 executables?
17.12.7 Why does lsof on my Solaris 7, 8 or 9 system say, "can't
read namelist from /dev/ksyms?"
17.13 Solaris and COMMON
17.13.1 What does COMMON mean in the NAME column for a Solaris VCHR
file?
17.13.2 Why does a COMMON Solaris VCHR file sometimes seem to have an
incorrect minor device number?
17.14 Why don't lsof and Solaris pfiles reports always match?
17.15 Why does lsof say, "kvm_open(namelist=default, core=default):
Permission denied?"
17.16 Why is lsof slow on my busy Solaris UFS file system?
17.17 Why is lsof so slow on my Solaris 8 or 9 system?
17.18 Solaris and VxFS
17.18.1 Why doesn't lsof support VxFS 3.4 on Solaris 2.6, and above?
17.18.2 Why does lsof report "vx_inode: vxfsu_get_ioffsets error"
for open Solaris 2.6 and above VxFS 3.4 and above files?
17.18.3 Why does Solaris Configure claim there is no VxFS library?
17.18.4 Why doesn't Solaris lsof report VxFS path name components?
17.18.5 Why does Solaris 10 lsof report scrambled VxFS paths?
17.19 Large file problems
17.19.1 Why does lsof complain it can't stat(2) a Solaris 2.5.1
large file?
17.20 Why does lsof get a segmentation fault on 64 bit Solaris
8 using NIS+?
17.21 Will lsof crash the Solaris kernel?
17.22 Why does lsof on Solaris 7, 8, or 9 report a kvm_open()
failure?
17.23 Solaris and SAM-FS
17.23.1 Why does Solaris lsof report "(limited SAM-FS info)"?
17.23.2 Why can't lsof locate named SAM-FS files?
17.24 Lsof and Solaris 10 zones
17.24.1 How can I make lsof list the Solaris zone?
17.24.2 Why doesn't lsof work in a Solaris 10 zone?
17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file
systems?
17.25 Solaris 10 problems
17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name?
17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on
directory and device?
17.25.3 What does "(deleted)" mean in the NAME column of a Solaris 10
open file?
17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open
file?
17.26 Solaris contract file problems
17.26.1 Why doesn't lsof report size, link count and node number for
Solaris 10 contract files?
17.26.2 Why can't lsof locate a Solaris 10 contract file by path name?
17.27 Solaris 10 and above ZFS probblems
17.27.1 Why does Configure warn that ZFS support is not enabled?
17.28 Problems with Solaris 9 and above
17.28.1 Why does the compiler complain about lgrp_root on Solaris 9
and above?
18.0 Lsof Features
18.1 Why doesn't lsof doesn't report on /proc entries on my
system?
18.2 How do I disable the device cache file feature or alter
it's behavior?
18.2.1 What's the risk with a perverted device cache file?
18.2.2 How do I put the full host name in a personal device cache file
path?
18.2.3 How do I put the personal device cache file in /tmp?
18.3 Why doesn't lsof know about AFS files on my favorite dialect?
18.3.1 Why doesn't lsof report node numbers for all AFS volume files,
or how do I reveal dynamic module addresses to lsof?
______________________________________________________________________
1.0 General Concepts
1.1 Lsof -- what is it?
Lsof is a UNIX-specific tool. Its name stands for LiSt
Open Files, and it does just that. It lists information
about files that are open by the processes running on a
UNIX system.
See the lsof man page, the 00DIST file, the 00QUICKSTART
file, and the 00README file of the lsof distribution for
more information.
1.2 Where do I get lsof?
Lsof is available via anonymous ftp from lsof.itap.purdue.edu.
Look in the pub/tools/unix/lsof sub-directory.
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof
Bzip2'd, compressed and gzip'd tar files with GPG certificates
are available.
1.2.1 Are there mirror sites?
On April 28, 2009 these sites appeared to have the lastest
lsof revision:
ftp://ftp.fu-berlin.de/pub/unix/tools/lsof
ftp://sunsite.ualberta.ca/pub/Mirror/lsof
1.2.2 Are lsof executables available?
Some lsof executables are available in the subdirectory
tree pub/tools/unix/lsof/binaries These are neither guaranteed
to be current nor cover every dialect and machine architecture.
I don't recommend you use pre-compiled lsof binaries; I
recommend you obtain the sources and build your own binary.
Even if you're a Sun user without a Sun C compiler, you
can use gcc to compile lsof.
If you must use a binary file, please be conscious of the
security and configuration implications in using an executable
of unknown or different origin. The lsof binaries are
accompanied by GPG certificates. Please use them!
Three additional cautions apply to executables:
1. Don't try to use an lsof executable, compiled for one
version of a UNIX dialect, on another. Patches can
make the dialect version different.
2. If you want to use an lsof binary on multiple systems,
they must be running the same dialect OS version and
have the same patches and feature support.
1.2.3 How do I check the validity of an lsof distribution?
There are two ways to check the validity of an lsof
distribution:
1. Follow the instructions in the CHECKSUMS_<revision>
file found with the lsof distribution.
Checking with GPG is the best method.
2. Follow the instructions in the "Security" section of the
README.lsof_<revision> file found inside the lsof
distribution.
Again, checking with GPG is the best method.
1.2.4 Why can't I get the sum(1) result reported in
README.lsof_<revision>?
The "Security" section of the README.lsof_<revision> file found
inside the lsof distribution gives md5, sum, and GPG certificate
information.
The simplest, the sum(1) signature, seems to be the trickiest.
That's because there are different sum(1) methods, BSD systems
usually have cksum(1) instead of sum(1), and different systems
compute the block size value differently.
First, the lsof sum results are computed with the old,
"alternate" algorithm. On newer systems, you can use sum's
"-r" option to get that computation result.
Second, on BSD systems you usually must use cksum(1) instead
of sum(1), because they have no sum(1). To tell cksum(1)
to use the old, "alternate" algorithm, use its "-o1" option.
Third, the second value that sum reports, the block count, may
be computed differently on different systems -- usually block
size is considered to be 512 or 1,024. The lsof block counts
were computed on a system with a sum(1) option that considers
block size to be 512. The BSD system cksum(1) -o1 option
considers block size to be 1,024. If your sum(1) or cksum(1)
doesn't report a block count that matches the sum(1) signature
given in README.lsof_<revision>, check its man page to see what
block size it uses, then adjust its reported block count
appropriately.
1.2.5 Why won't gpg accept the lsof-signing PGP public key?
An older PGP key that once signed lsof distributions is
included in lsof revisions prior to 4.70. The PGP key is
indeed my key, but is incompatible with GPG. It was created
about ten years ago and is still acceptable to PGP versions
2.6.2 through 6.5.2.
Lsof revisions 4.70 and above are signed with a copy of my PGP
key that has been made acceptable for use with GPG by importing
it under GPG's "--allow-non-selfsigned-uid" option.
You can find my GPG compatible key in lsof revisions 4.70 and
above and at:
ftp://lsof.itap.purdue.edu/pub/Victor_A_Abell.gpg
If you have an older lsof revision with my PGP key, there are
two possible ways to use it:
* Use it with a PGP version from 2.6.2 through 6.5.2.
* Use GPG's "--allow-non-selfsigned-uid" option when you
import my PGP key into your GPG key ring.
$ gpg --allow-non-selfsigned-uid --import Victor_A_Abell.pgp
1.3 Where can I get more lsof documentation?
A significant set of documentation may be found in the lsof
distribution (See "Where can I get lsof?). There is a
manual page, copious documentation in files whose names
begin with 00, and a copy of this FAQ in the file 00FAQ
(perhaps slightly less recent than this file if you're
reading it via a web browser.)
Two URLs provide some documentation that appears in the
lsof distribution:
FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
1.4 How do I report an lsof bug?
If you believe you have discovered a bug in lsof, you can
report it via e-mail to <abe@purdue.edu>. Do NOT report lsof
bugs to the UNIX dialect vendor. Make sure "lsof" appears in
the "Subject:" line so my e-mail filter won't classify your
letter as Spam.
Before you send me a bug report, please read the "Bug Reports"
section of the 00README file of the lsof distribution. It
lists the steps you should take before and when reporting a
suspected bug.
1.5 Where can I get the lsof FAQ?
This lsof FAQ is available in the file 00FAQ in the lsof
distribution and at the URL:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
1.5.1 How timely is the on-line FAQ?
The on-line FAQ is sometimes too timely. :-)
I update it as soon as new information is available. That may
include information about support that won't appear in the lsof
source distribution until the next revision. If you encounter
something like that, please send me e-mail at <abe@purdue.edu>. I
may be able to point you at a pre-release distribution that contains
the support of interest. Make sure "lsof" appears in the "Subject:"
line so my e-mail filter won't classify your letter as Spam.
1.6 Is there a test suite?
Yes, as of lsof revision 4.63 there's an automated lsof
test suite in the tests/ sub-directory of the lsof top-level
directory.
More information on using the test suite, what it does,
how to use it and how to configure it may be found in the
00TEST file of the lsof distribution. That file also
explains where the test suite has been tested.
Frequently asked questions about the test suite will be
asked and answered here in the FAQ. (See "Test Suite
Problems.")
After lsof has been configured with the Configure script,
lsof can be made and tested with:
$ make
$ cd tests
$ make
Under normal conditions -- i.e., unless the lsof tree has
been cleaned or purged severely -- all tests or individual
tests may be run by:
$ cd test
$ make
or
$ <run a single test> (See 00TEST.)
1.7 Is lsof vulnerable to the standard I/O descriptor attack?
Lsof revisions 4.63 and above are not vulnerable.
Lsof revisions 4.62 and below are vulnerable, but no damage
scenarios have so far been demonstrated.
The standard I/O descriptor attack is a local programmed
assault on setuid and setgid programs that tricks them into
opening a sensitive file with write access on a standard
descriptor, usually stderr (2), and writing error messages
to stderr. If the attacker can control the content of the
error message, the attacker may gain elevated privileges.
The attack was first described in Pine Internet Advisory
PINE-CERT-20020401, available at:
http://www.pine.nl/advisories/pine-cert-20020401.txt
If you are using an lsof revision below 4.63, you should
remove any setuid or setgid permissions you might have
given its executable. Then you should upgrade to lsof
revision 4.63.
1.8 Can I alter lsof's make(1) behavior?
Yes. There are at least two ways to do that.
You can put replacements for lsof Makefile strings in your
environment. If you specify the -e make option, make will
give environment variable values precedence over strings
from the Makefile. For example, to change the compiler
string CC from the environment, you might do this with the
Bourne shell:
$ CC=foobar; export CC
$ make -e
You can also replace lsof Makefile strings in the make
command invocation. Here's the previous example done that
way:
$ make CC=foobar
Changing the CFGF, CFGL, and DEBUG strings used in lsof
Makefiles, either from the environment or from the make
invocation, can significantly alter lsof make(1) behavior.
I commonly use DEBUG to change the -O option to -g so I
can build an lsof executable for debugging -- e.g.,
$ make DEBUG=-g
(Look for DEBUG in this FAQ for other examples of its use.)
Consult the Makefiles to see what CFGL, CFGL, and other
lsof Makefile strings contain, and to see what influence
their alteration might have on lsof make(1) behavior.
1.9 Is there an lsof license?
No.
The only restriction on the use or redistribution of lsof
is contained in this copyright statement, found in every
lsof source file. (The copyright year in or format of the
notice may vary slightly.)
/*
* Copyright 2002 Purdue Research Foundation, West Lafayette,
* Indiana 47907. All rights reserved.
*
* Written by Victor A. Abell
*
* This software is not subject to any license of the American
* Telephone and Telegraph Company or the Regents of the
* University of California.
*
* Permission is granted to anyone to use this software for
* any purpose on any computer system, and to alter it and
* redistribute it freely, subject to the following
* restrictions:
*
* 1. Neither the authors nor Purdue University are responsible
* for any consequences of the use of this software.
*
* 2. The origin of this software must not be misrepresented,
* either by explicit claim or by omission. Credit to the
* authors and Purdue University must appear in documentation
* and sources.
*
* 3. Altered versions must be plainly marked as such, and must
* not be misrepresented as being the original software.
*
* 4. This notice may not be removed or altered.
*/
1.10 Language locale support
1.10.1 Does lsof support language locales? How do I use the support?
Most UNIX dialect versions of lsof support 8 bit language
locale characters -- e.g., the ability to print 8 bit
characters that have accents and other marks over them.
See the answer to the "Does lsof support wide characters in
language locales?" question for information on when lsof's
language locale support covers characters wider than 8 bits.
To see if lsof supports language locales for your dialect, look
in the dialect's machine.h header file for the HASSETLOCALE
definition. If it is present and not disabled, then lsof has
language locale support for the dialect.
To enable lsof's language locale support, you must specify in a
locale environment variable (e.g., LANG) a language locale
known to your system that supports the printing of marked
characters -- e.g, en_US. (On some dialects locale(1) may be
used to list the known language locales.)
Note that LANG=C and LANG=POSIX are NOT language locales that
support the printing of marked characters.
If the language locale doesn't support the printing of marked
characters, lsof's OUTPUT of them follows the rules for
non-printable characters described in the OUTPUT section of
lsof(8).
Consult your dialect's setlocale(3) man page for the names of
environment variables other than LANG -- e.g., LC_ALL,
LC_TYPE, etc. -- which may be used to define language locales.
1.10.2 Does lsof support wide characters in language locales?
When lsof's language locale support is enabled with the
HASSETLOCALE definition, for selected dialects lsof will also
print wide characters (e.g., from UTF-8) when iswprint(3)
reports them to be printable.
Wide character support is available when HASWIDECHAR is defined
in a dialect's machine.h header file. As of this writing on
July 22, 2004, the following dialect versions have wide character
support:
AIX >= 4.3.2
Apple Darwin >= 7.3.0
FreeBSD >= 5.2
HP-UX >= 11.00
/proc-based Linux
NetBSD >= 1.6
SCO OpenServer >= 5.0.6
Solaris >= 2.6
Tru64 UNIX 5.1
1.11 Are any files in the lsof distribution copyrighted?
Yes. Most files carry the copyright of the Purdue Research
Foundation and may be redistributed under the terms that
accompany the copyright notice. Those terms may also be found
in the answer to the question, "Is there an lsof license?")
A few files carry other copyright notices. Some are BSD
notices and they explain the terms under which they are
included in the lsof distribution.
Those that carry vendor copyright notices have been reproduced
in their original or modified forms with permission from the
copyright owners. That permission is indicated in the README
files that accompany the files.
1.12 Are there other lsof-related resources?
There are other resources available, connected to lsof. Among
them are FreeBSD and Linux packages whose products use lsof and
two particularly interesting resources.
The two interesting resources are a Gnome Tool Kit (GTK) GUI
for lsof and a Perl wrapper module.
The GTK GUI is called Glsof and was developed by Gnele. It can
be found at:
http://www.sourceforge.net
The Perl wrapper module by Marc Beyer can be found at:
http://search.cpan.org/dist/Unix-Lsof/
1.13 What does the "WARNING: unsupported dialect or version" mean?
The lsof configure script issues that message for UNIX dialects
or their versions where I have been unable to test the current
revision of lsof. The message doesn't mean that lsof won't
work, just that I have no direct evidence that it will.
If the COnfigure script succeeds, except for the warning, try
compiling) lsof. If that succeeds, try the lsof test suite.
2.0 Lsof Ports
2.1 What ports exist?
The pub/lsof.README file carries the latest port information:
AIX 5.[23] and 5.3
FreeBSD 4.9 and 6.4 for x86-based systems
FreeBSD 8.2, 9.0 and 10.0 for AMD64-based systems
Linux 2.1.72 and above for x86-based systems
Solaris 9, 10 and 11
In the above list the only UNIX dialects present are ones for
which I test the current lsof revision. Lsof may still support
unlisted dialect versions -- e.g., HP-UX 10.20, Solaris 7, etc.
-- but I don't have access to systems where I could test lsof
on them, so I can't claim lsof works on them. If your dialect
isn't in the list, you should try building lsof on it anyway.
Lsof version 4 predecessors, versions 2 and 3, may support older
version of some dialects. Contact me via e-mail at <abe@purdue.edu>
if you're interested in their distributions. Make sure "lsof"
appears in the "Subject:" line so my e-mail filter won't classify
your letter as Spam.
2.2 What about a new port?
The 00PORTING file in the distribution gives hints on doing
a port. I will consider doing a port in exchange for
permanent access to a test host. I require permanent access
so I can test new lsof revisions, because I will not offer
distributions of dialect ports I cannot upgrade and test.
2.2.1 User-contributed Ports
Sometimes I receive contributions of ports of lsof to
systems where I can't test future revisions of lsof. Hence,
I don't incorporate these contributions into my lsof
distribution.
However, I do make descriptions of these contributions
available. You can find them in the 00INDEX and README
files at:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/contrib
Consult the 00INDEX file in the contrib/ directory for a
list of the available contributions and consult README
there for information on how to obtain them.
2.3 Why isn't there an AT&T SVR4 port?
I haven't produced an AT&T SVR4 port because I haven't seen
a UNIX dialect that is strictly limited to the AT&T System
V, Release 4 source code. Every one I have seen is a
derivative with vendor additions.
The vendor additions are significant to lsof because they
affect the internal kernel structures with which lsof does
business. While some vendor derivatives of SVR4 are similar,
each one I have encounted so far has been different enough
from its siblings to require special source code.
If you're interested in an SVR4 version of lsof, here are
some existing ports you might consider:
DC/OSx (This obsolete port is only available upon
special request.)
Reliant UNIX (This obsolete port is only available
upon special request.)
SCO|Caldera UnixWare (This is the most likely choice.)
Solaris
2.4 Why isn't there an SGI IRIX port?
Lsof support for IRIX was terminated at lsof revision 4.36,
because it had become increasingly difficult for me to
obtain information on the IRIX kernel structures lsof needs
to access.
At IRIX 6.5 I decided the obstacles were too large for me
to overcome, and I stopped supporting lsof on IRIX. I have
sources to the last revision of lsof (4.36) for IRIX, but
that version of lsof does not work on IRIX 6.5 and is
vulnerable to the standard I/O descriptor attack. (See
the "Is lsof vulnerable to the standard I/O descriptor
attack?" Q&A for more information.) Contact me to discuss
obtaining those sources.
If you wish to pursue the issue, don't contact me, contact
SGI. This case was opened with SGI on the subject:
Case ID: 0982584
Category: Unix
Priority: 30-Moderate Impact
Problem Summary:
kernel structure header files needed for continued lsof
support
Problem Description:
Email In 07/17/98 19:09:23
2.5 Why does lsof's Configure script report "WARNING: unsupported
dialect or version"?
Lsof's Configure script issues this message when it encounters
a dialect or its version that lsof once supported, but no
longer does. Usually I drop support for a dialect or version
when I can no longer test lsof on it.
However, it's worth trying to compile and use lsof. Be sure to
run the test suite. (See the answer to the "Is there a test
suite? question for information on the test suite.)
If you have problems with an unsupported dialect or version,
contact me via e-mail at <abe@purdue.edu> and I may be able to help.
Make sure "lsof" appears in the "Subject:" line so my e-mail filter
won't classify your letter as Spam.
3.0 Lsof Problems
3.1 Configuration Problems
3.1.1 Why can't Configure determine the UNIX dialect version?
The lsof Configure script uses UNIX shell commands, often in a
command pipeline, to determine the UNIX dialect version.
(Consult the dialect stanza in Configure to determine which
commands are used.) If Configure can't determine the dialect
version, probably one of the commands is not behaving as
Configure expects.
Symptoms of the failure include Configure warning messages and
incorrect version definitions in the Makefile CFLAGS.
If you suspect that the lsof Configure script is failing to
determine the dialect version correctly, try running the
commands from Configure stanza one at a time. That will
usually reveal the source of the problem. Be particularly
mindful that the PATH environment variable can cause commands
to be executed from non-standard directories.
If you can't determine the source of the problem, there is a
work-around. You can supply the UNIX dialect version in the
LSOF_VSTR environment variable. Use Configure as a guide to
forming what it expects in LSOF_VSTR. There is also some
information on LSOF_VSTR in the 00XCONFIG documentation file
of the lsof distribution.
3.2 Compilation Problems
3.2.1 Why does the compiler complain about missing header files?
When you use make to build lsof, the compiler may complain
that it can't find header files -- e.g.,
$ make
(cd lib; make DEBUG="-O" CFGF="-DAIXA=0 -DAIXV=4330 \
-DLSOF_VSTR=\"4.3.3.0\"")
gcc -DAIXA=0 -DAIXV=4330 -DLSOF_VSTR="4.3.3.0" -O \
-c ckkv.c
In file included from ckkv.c:33: ../machine.h:70: \
sys/types.h: A file or directory in the path name \
does not exist. \
That type of complaint doesn't represent an lsof problem.
It represents a problem with a missing system header file
that probably should be found in /usr/include or in the
system source tree.
As a first step try using find(1) to locate the problem
header file. If it's a system header file and can't be
found, here are some possible causes:
1. The file set, RPM or package containing the header files
has not been installed. Instructions for doing that
are specific to the UNIX dialect and beyond the scope
of this document.
2. If the compiler is gcc, the private gcc header files:
* May not have been installed;
* May have been installed incorrectly;
* May not have been updated properly after the last
compiler or system update;
* Ones from a previous installation may not have been
removed.
A path leading to the gcc private header files can be
found with `gcc -v`. Consult the gcc documentation for
instructions on proper installation of the private gcc
header files.
3. On some dialects -- e.g., FreeBSD, NetBSD, OpenBSD --
lsof may need to use header files that are located in
the system source tree -- /sys or /usr/src/sys, for
example. Make sure the system source tree has been
installed.
3.2.2 Why does gcc complain about the contents of header files
distributed by the system's vendor?
When you use make to build lsof and gcc to compile it, gcc
may complain that it finds errors in system header files
-- e.g.,
$ make
(cd lib; make DEBUG="-O" CFGF="-Dsolaris=80000 \
-DHASPR_GWINDOWS -m64 -DHASIPv6 -DHAS_VSOCK \
-DLSOF_VSTR=\"5.8\"")
gcc -Dsolaris=80000 -DHASPR_GWINDOWS -m64 -DHASIPv6 \
-DHAS_VSOCK -DLSOF_VSTR="5.8" -O -c dvch.c
In file included from /usr/include/sys/proc.h:31, \
from /homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/ \
3.2.1/include/sys/user.h:267, from /usr/include/kvm.h:13, \
from ../dlsof.h:53, from ../lsof.h:172, from dvch.c:43: \
/homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/\
3.2.1/include/sys/task.h:59: parse error before "uint_t"
Errors like the above are most likely not problems in the
system's header files, but in the private copies of them
that were created when gcc was made or installed. Note
the presense of
".../gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/3.2.1/include/..."
in the paths for user.h and task.h. It indicates both
header files are gcc-specific.
To solve errors like this requires comparing the header
files in the vendor's /usr/include tree to the gcc-specific
ones in gcc's private gcc-lib/.../include tree. It may be
necessary to regenerate gcc-specific header files, correct
them or remove them. See the gcc distribution for the
appropriate tools.
A possible temporary work-around is to direct gcc to use
the vendor's header files instead of its temporary ones by
declaring -I/usr/include in the compilation flags.
3.2.3 Other header file problems
Don't overlook any vendor tools that might validate the
vendor header files installed on the system -- e.g., the
Solaris pkgchk tool can be used to check the header files
that were installed from the SUNWhea package.
For other header file problems contact me at <abe@purdue.edu>.
Please follow the reporting guidelines in the "How do I
report an lsof bug?" section of this FAQ.
3.3 Why doesn't lsof report full path names?
Lsof reports the full path name when it is specified as a
search argument for open files that match the argument.
However, if the argument is a file system mounted-on
directory, and lsof finds additional path name components
from the kernel name cache, it will report them.
Lsof reports path name for file system types that have path
name lookup features -- e.g., some versions of AdvFS for
Digital and Tru64 UNIX. The Linux /proc-based lsof reports
full path names, because the Linux /proc file system provides
them. Lsof on recent builds of Solaris 10 also report full
path names, because those Solaris kernels record the full path
name in the vnode structure.
Otherwise, lsof uses the kernel name cache, where it exists
and can be accessed, and reports some or all path name
components (e.g., the sys and proc.h components of
/usr/include/sys/proc.h) for these dialects:
Apple Darwin
DC/OSx
FreeBSD
HP-UX, /dev/kmem and PSTAT based
Linux, /dev/kmem-based
NetBSD
NEXTSTEP
OpenBSD
OPENSTEP
Reliant UNIX
SCO OpenServer
SCO|Caldera UnixWare
Solaris 2.x, 7, 8 and 9 (except for some VxFS versions;
see the "Why doesn't Solaris
lsof report VxFS path name
components?" section for more
information)
Solaris 10 (early builds) Tru64 UNIX
As far as I can determine, AFS path lookups don't share in
kernel name cache operations, so lsof can't identify open AFS
path name components. Apparently Solaris VxFS versions 4 and
above don't share in kernel name cache operations, either, so
lsof can't display path name components for those open files.
Since the size of the kernel name cache is limited and the
cache is in constant flux, it does not always contain the names
of all components in an open file's path; sometimes it contains
none of them.
Lsof reports the file system directory name and whatever
components of the file's path it finds in the cache, starting
with the last component and working backwards through the
directories that contain it. If lsof finds no path
components, lsof reports the file system device name instead.
When lsof does report some path components in the NAME
column, it prefixes them with the file system directory
name, followed by " -- ", followed by the components --
e.g., /usr -- sys/path.h for /usr/include/sys/path.h. The
" -- " is omitted when lsof finds all the path name components
of a file's name.
The PSTAT-based HP-UX lsof relies on kernel name cache
contents, too, even though its information comes to lsof
via pstat() function calls. Consequently, PSTAT-based
HP-UX lsof won't always report full paths, but may use the
" -- " partial path name notation, or may occasionally
report no path name at all but just the file system mounted-on
directory and device names.
Lsof can't obtain path name components from the kernel name
caches of the following dialects:
AIX
Only the Linux kernel records full path names in the
structures it maintains about open files; instead, most
kernels convert path names to device and node number doublets
and use them for subsequent file references once files have
been opened.
To convert the device and node number doublet into a
complete path name, lsof would have to start at the root
node (root directory) of the file system on which the node
resides, and search every branch for the node, building
possible path names along the way. That would be a time
consuming operation and require access to the raw disk
device (usually implying setuid-root permission).
If the prospect of all that local disk activity doesn't
concern you, think about the cost when the device is
NFS-mounted.
Try using the file system mount point and node number lsof
reports as parameters to find -- e.g.,
$ find <mount_point> -inum <node_number> -print
and you may get an appreciation of what a file system
directory tree search would cost.
3.3.1 Why do lsof -r reports show different path names?
When you run lsof with its repeat (``-r'') option, you may
notice that the extent to which it reports path names for
the same files may vary from cycle to cycle. That happens
because other processes are making kernel calls affecting
the cache and causing entries to be removed from and added
to it.
3.3.2 Why does lsof report the wrong path names?
Under some circumstances lsof may report an incorrect path
name component, especially for files in a rapidly changing
directory like /tmp.
In a rapidly changing directory, like /tmp, if the kernel
doesn't clear the cache entry when it removes a file, a
new file may be given the same keys and lead lsof to believe
that the old cache entry with the same keys belongs to the
new file.
Lsof tries to avoid this error by purging duplicate entries
from its copy of the kernel name cache when they have the
same device and inode number, but different names.
This error is less likely to occur in UNIX dialects where the
keys to the name cache are node address and possibly a
capability ID. The Apple Darwin, Digital UNIX, FreeBSD, HP-UX,
NEXTSTEP, OPENSTEP, Solaris, Tru64 UNIX, and UnixWare dialects
use node address. Apple Darwin, FreeBSD, NetBSD, OpenBSD,
Tru64 UNIX, and also use a capability ID to further identify
name cache entries.
3.3.3 Why doesn't lsof report path names for unlinked (rm'd) files?
When lsof gets path name components from the kernel's name
cache, it does not report the path names of a file that has
been unlinked from its parent directory -- e.g., deleted via
rm, or the unlink() system call -- even when some process may
still hold the file open; lsof reports only the file system's
mounted-on directory and device. That's because path name
components are removed from the kernel name cache when the file
is unlinked.
Unlinked open files are sometimes used by applications for
temporary, but invisible storage (i.e., ls won't show them,
and no other process can open them.) However, they may
occasionally consume disk space to excess and cause concern
for a system administrator, who will be unable to locate
them with find, ls, du, or other tools that rely on finding
files by examining the directory tree.
By using lsof's +L option you can see the link count of
open files -- in the NLINK column. An unlinked file will
have an NLINK value of zero. By using the option +L1 you
can tell lsof to display only files whose link count is
less than one (i.e., zero).
There are some UNIX dialect-specific exceptions to lsof's
inability to report unlinked path names. They are described in
the answer to the "When will lsof report path names for deleted
files?" question.
3.3.4 Why doesn't lsof report the "correct" hard linked file path
name?
When lsof reports a rightmost path name component for a
file with hard links, the component may come from the
kernel's name cache. Since the key which connects an open
file to the kernel name cache may be the same for each
differently named hard link, lsof may report only one name
for all open hard-linked files. Sometimes that will be
"correct" in the eye of the beholder; sometimes it will
not. Remember, the file identification keys significant
to the kernel are the device and node numbers, and they're
the same for all the hard linked names.
3.3.5 When will lsof report path names for deleted files?
Lsof will report path names for deleted files for two
dialects: Linux and later builds of Solaris 10.
Deleted Linux path names are reported by default and have
"(deleted)" at their ends.
The display of Solaris 10 deleted path names may be selected
with the -X option. When selected they are also reported with
"(deleted)" at their ends.
3.4 Why is lsof so slow?
Lsof may appear to be slow if network address to host name
resolution is slow. This can happen, for example, when the
name server is unreachable, or when a Solaris PPP cache daemon
is malfunctioning.
To see if name lookup is causing lsof to be slow, turn it off
with the ``-n'' option.
Port service name lookup or portmap registration lookup may
also be causes of slow-down. To suppress port service name
lookup, specify the ``-P'' option.
Lsof doesn't usually make direct portmap calls -- only when +M
is specified, or when HASPMAPENABLED is defined during lsof
construction. (The lsof help panel, produced with `lsof -h`
will display the default portmap registration reporting
state.) The quickest first step in checking if lsof is slow
because of the portmapper is to use lsof's ``-M'' option.
Lsof may be slow if UID to login name lookups are slow.
Suppress them with ``-l''.
On dialects where lsof uses the kernel name cache, try
disabling its use with ``-C''. (You can tell if lsof uses the
kernel name cache by looking for ``-C'' in lsof's ``-h''
output.) Of course, disabling kernel name cache use will mean
that lsof won't report full or partial path names, just file
system and character device names.
If you're just interested in the open files of one process, try
using the ``-p <Process-ID>'' option to limit lsof to that
process. (The ``-p'' option may also be followed with a list
of Process-IDs.)
If you're interested in including or excluding certain
commands, try lsof's "-c[^]cmd" option.
If you're interested in certain Internet TCP and UDP states
(e.g., ESTABLISHED) or in excluding some (e.g., CLOSE_WAIT),
try lsof's "-s p:s" option, available where shown on the lsof
help output, obtained with -h or -?. More information on it
may be found in the answer to the "How are protocol state name
exclusion and inclusion used?" question.
Your UNIX dialect may not support "-s p:s" and its associated
performance improvments to Internet-only file processing. You
can find more information on those topics in the answer to the
"Why doesn't my dialect support state name exclusion and
inclusion?" question.
Older AIX lsof may be slow to start because of its oslevel
identity comparison. (Newer AIX lsof uses uname(2).) See the
"Why does AIX lsof start so slowly?" and "Why does lsof warn
"compiled for x ... y; this is z.?" sections for more
information.
3.5 Why doesn't lsof's setgid or setuid permission work?
If you install lsof on an NFS file system that has been
mounted with the nosuid option, lsof may not be able to
use the setgid or setuid permission you give it, complaining
it can't open the kernel memory device -- e.g., /dev/kmem.
The only solution is to install lsof on a file system that
doesn't inhibit setgid or setuid permission.
3.6 Does lsof have security problems?
I don't think so. However, lsof does usually start with
setgid permission, and sometimes with setuid-root permission.
Any program that has setgid or setuid-root permission,
should always be regarded with suspicion.
Lsof drops setgid power, holding it only while it opens
access to kernel memory devices (e.g., /dev/kmem, /dev/mem,
/dev/swap). That allows lsof to bypass the weaker security
of access(2) in favor of the stronger checks the kernel
makes when it examines the right of the lsof process to
open files declared with -k and -m. Lsof also restricts
some device cache file naming options when it senses the
process has setuid-root power.
On a few dialects lsof requires setuid-root permission
during its full execution in order to access files in the
/proc file system. These dialects include:
DC/OSx 1.1 for Pyramid systems
Reliant UNIX 5.4[34] for Pyramid systems
When lsof runs with setuid-root permission it severely
restricts all file accesses it might be asked to make with
its options.
The device cache file (typically .lsof_hostname in the home
directory of the real user ID that executes lsof) has 0600
modes. (The suffix, hostname, is the first component of
the host's name returned by gethostname(2).) However, even
when lsof runs setuid-root, it makes sure the file's
ownerships are changed to that of the real user and group.
In addition, lsof checks the file carefully before using
it (See the question "How do I disable the device cache
file feature or alter it's behavior?" for a description of
the checks.); discards the file if it fails the scrutiny;
complains about the condition of the file; then rebuilds
the file.
See the 00DCACHE file of the lsof distribution for more
information about device cache file handling and the risks
associated with the file.
3.7 Will lsof show remote hosts using files via NFS?
No. Remember, lsof displays open files for the processes
of the host on which it runs. If the host on which lsof
is running is an NFS server, the remote NFS client processes
that are accessing files on the server leave no process
records on the server for lsof to examine.
3.8 Why doesn't lsof report locks held on NFS files?
Generally lock information held by local processes on remote
NFS files is not recorded by the UNIX dialect kernel. Hence,
lsof can't report it.
One exception is some patch levels of Solaris 2.3, and all
versions of Solaris 2.4 and above. Lsof for those dialects
does report on locks held by local processes on remotely
mounted NFS files.
3.8.1 Why does lsof report a one byte lock on byte zero as a full
file lock?
When a process has a lock of length one, starting at byte
zero, lsof can't distinguish it from a full file lock.
That's because most UNIX dialects represent both locks the
same way in their file lock (flock or eflock) structures.
3.9 Why does lsof report different values for open files on the
same file system (the automounter phenomenon)?
On UNIX dialects where file systems may be mounted by an
automounter with the ``direct'' type, lsof may sometimes
report difference DEVICE, SIZE/OFF, INODE and NAME values
when asked to report files open on the file system.
This happens because some files open on the file system --
e.g., the current directory of a shell that changed its
directory to the file system as the file system's first
reference -- may be characterized in the kernel with
temporary automounter node information. The cd doesn't
cause the file system to be mounted.
A subsequent reference to the file system -- e.g., an ls
of any place in it -- will cause the file system to be
mounted. Processes with files open to the mounted file
system are characterized in the kernel with data that
reflects the mounted file system's parameters.
Unfortunately some kernels (e.g., some versions of Solaris
2.x) don't revisit the process that did only a change-directory
for the purpose of updating the data associated with the
open directory file. The file continues to be characterized
with temporary automounter information until it does another
directory change, even a trivial ``cd .''.
Lsof will report on both reference types, when supplied
the file system name as an argument, but the data lsof
reports will reflect what it finds in the kernel. For the
different types lsof will display different data, including
different major and minor device numbers in the DEVICE
column, different lengths in the SIZE/OFF column, different
node numbers in the INODE column, and slightly different
file system names in the NAME column.
In contrast, fuser, where available, can only report on
one reference type when supplied the file system name as
an argument. Usually it will report on the one that is
associated with the mounted file system information. If
the only reference type is the temporary automounter one,
fuser will often be silent about it.
3.10 Why don't lsof and netstat output match?
Lsof and netstat output don't match because lsof reports
the network information it finds in open file system objects
-- e.g., socket files -- while netstat often gets its
information from separate kernel tables.
The information available to netstat may describe network
activities never or no longer associated with open files,
but necessary for proper network state machine operation.
For example, a TCP connection in the FIN_WAIT_[12] state
may no longer have an associated open file, because the
connection has been closed at the application layer and is
now being closed at the TCP/IP protocol layer.
3.10.1 Why can't lsof find accesses to some TCP and UDP ports?
Lsof stands for LiSt Open Files. If there is no open file
connected to a TCP or UDP port, lsof won't find it. That's
the most common reason why lsof doesn't find a port netstat
might report open.
One reason I've found on some UNIX dialects is that their
kernels set aside TCP and UDP ports for communicating with
support activities, running in application layer servers
-- the automounter daemons, and the NFS biod and nfsd
daemons are examples. Netstat may report the ports are in
use, but lsof doesn't.
Another reason is that netstat may also be able to report
a port is open on a particular dialect, because it uses a
source of data different from what lsof uses -- e.g.,
netstat might examine kernel tables or use streams messages
to MIB2, while lsof relies on the information it finds in
open file structures and their descendants.
Sometimes it's possible to search the data netstat and lsof
use. For example, on Linux /proc/tcp and /proc/udp can be
examined. There might an entry there for a particular
protocol and port, but if the line on which the port appears
doesn't have an inode number that matches an inode number
of an open file, lsof won't be able to identify the process
using the port.
This is a tough question to which there is no easy answer.
3.11 Why does lsof update the device cache file?
At the end of the lsof output you may see the message:
lsof: WARNING: /Homes/abe/.lsof_vic was updated.
In this message /Homes/abe/.lsof_vic is the path to the
private device cache file for login abe. (See 00DCACHE.)
Lsof issues this message when it finds it necessary to
recheck the system device directory (e.g., /dev or /devices)
and rebuild the device cache file during the open file
scan. Lsof may need to do these things it finds that a
device directory node has changed, or if it cannot find a
device in the cache.
3.12 Why doesn't lsof report state for UDP socket files?
Lsof reports UDP TPI connection state -- TS_IDLE (Idle),
TS_BOUND (Bound), etc. -- for some, but not all dialects.
TPI state is stream-based TCP/IP information that isn't
available in many dialects.
A fairly weak general rule is if netstat(1) reports UDP
TPI state, lsof may be able to report it, too. But don't
be surprised if lsof fails to report UDP TPI state for your
dialect. Other factors influence lsof's ability to report
UDP TPI state, including the availability of state number
data in kernel structures, and state number to state name
conversion data.
3.13 I am editing a file with vi; why doesn't lsof find the file?
Classic implementations of vi usually don't keep open the file
being edited. (Newer ones may do so in order to maintain an
advisory lock.) Instead classic vi opens the file, makes a
temporary copy (usually in /tmp or /usr/tmp), and does its work
in that file. When you save the file being edited from a
classic vi implementation, it reopens and rewrites the file.
During a classic vi session, except for the brief periods when
vi is reading or rewriting the file, lsof won't find an open
reference to the file from the vi process, because there is
none.
3.14 Why doesn't lsof report TCP/TPI window and queue sizes for my
dialect?
Lsof only reports TCP/TPI window sizes for Solaris, because
only its netstat reports them. The intent of providing
TCP/TPI information in lsof NAME column output is to make
it easier to match netstat output to lsof output.
In general lsof only reports queue sizes for both TCP and
UDP (TPI) connections on BSD-derived UNIX dialects, where
both sets of values appear in kernel socket queue structures.
SYSV-derived UNIX dialects whose TCP/IP implementations
are based on streams generally provide only TCP queue sizes,
not UDP (TPI) ones.
While you may find that netstat on some SYSV-derived UNIX
dialects with streams TCP/IP may report UDP (TPI) queue
sizes, you will probably also find that the sizes are always
zero -- netstat supplies a constant zero for UDP (TPI)
queue sizes to make its headers align the same for TCP and
UDP (TPI) connections. Solaris seems to get it right --
i.e., its netstat does not report UDP (TPI) queue sizes.
When in doubt, I chose to avoid reporting UDP (TPI) queue
sizes for UNIX dialects whose netstat-reported values I
knew to be a constant zero or whose origin I couldn't
determine. OSR is a dialect in this category.
3.14.1 Why doesn't lsof report socket options, socket states, and TCP
flags and values for my dialect?
The lsof -T argument, 'f', that selects the reporting of socket
options, socket states and TCP flags was implemented at lsof
revision 4.71 for the following UNIX dialects, providing the
indicated information:
AIX 4.3.2 and 5.1 and above
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
Apple Darwin 7.2 and above
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
Digital UNIX and Tru64 UNIX 4.0
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
FreeBSD 4.9 and above
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
HP-UX 11.00 (/dev/kmem-based lsof)
All socket options and values are reported. No socket
states are reported. Only the TF_NODELAY TCP flag and
the TF_MSS value are reported.
HP-UX 11.11 and iiiv2 (PSTAT-based lsof)
All socket options and values, and socket states are
reported. No TCP flags or values are reported.
Linux
No socket options and values, socket states, or TCP
flags and values are reported. The support for "-Tf"
could not be added to Linux, because socket options,
socket states, and TCP flags and values are not
available via the /proc file system.
NetBSD 1.6G and above
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
OpenBSD 3.4 and above
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
OPENSTEP 4.2
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
OpenUNIX 8
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
SCO OpenServer Release 5.0.6
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
Solaris 2.6, 8 and above
The socket option display is limited to BROADCAST,
DEBUG, DGRAM_ERRIND, DONTROUTE and OOBINLINE. Socket
values are limited to KEEPALIVE and LINGER. No socket
states are reported. The TCP DELACK, NODELAY and
SENTFIN flags are reported. The TCP MSS value is
reported.
UnixWare 7.1.[134]
All socket options and values, socket states, and TCP
flags and values described in lsof(8) are reported.
3.14.2 Why doesn't lsof report the partial listen queue connection
count for my dialect?
The reporting of partial listen queue connections was added to
-Tf processing at lsof revision 4.76. Currently it is reported
for these dialects:
AIX 4.3.2
This dialect is no longer supported, so no attempt
was made to add partial listen queue length support
for it.
AIX 5.1 and above
Partial listen queue information is available.
Apple Darwin 7.2 and above
Partial listen queue information is available.
Digital UNIX 4.0
This dialect is no longer supported, so no attempt
was made to add partial listen queue length support
for it.
FreeBSD 4.9 and above
Partial listen queue information is available.
HP-UX 11.00 (/dev/kmem-based lsof)
No partial listen queue information is available.
HP-UX 11.11 and iiiv2 (PSTAT-based lsof)
No partial listen queue information is available.
Linux
No partial listen queue information is available.
NetBSD 1.6G and above
Partial listen queue information is available.
OpenBSD 3.4 and above
Partial listen queue information is available.
OPENSTEP 4.2
Partial listen queue information is available.
OpenUNIX 8
This dialect is no longer supported, so no attempt
was made to add partial listen queue length support
for it.
SCO OpenServer Release 5.0.6
No partial listen queue information is available.
Solaris 2.6, 8 and above
Partial listen queue information is available.
Tru64 UNIX 5.0
This dialect is no longer supported, so no attempt
was made to add partial listen queue length support
for it.
Tru64 UNIX 5.1
Partial listen queue information is available.
UnixWare 7.1.[134]
Partial listen queue information is available.
3.15 What does "no more information" in the NAME column mean?
When lsof can find no successor structures -- a gnode,
inode, socket, or vnode -- connected to the file structure
of an open descriptor of a process, it reports "no more
information" in the NAME column. The TYPE, DEVICE, SIZE/OFF,
and INODE columns will be blank.
Because the file structure is supposed to contain a pointer
to the next structure of a file's processing support, if
the pointer is NUL, lsof can go no further.
Some UNIX dialects have file structures for system processes
-- e.g., the sched process -- that have no successor
structure pointers. The "no more information" NAME will
commonly appear for these processes in lsof output.
It may also be the case that lsof has read the file structure
while it is being assembled and before a successor structure
pointer value has been set. The "no more information" NAME
will again result.
Unless lsof output is filled with "no more information"
NAME column messages, the appearance of a few should be no
cause for alarm.
3.16 Why doesn't lsof find a process that ps finds?
If lsof fails to display open files for a process that ps
indicates exists, there may be several reasons for the
difference.
The process may be a "zombie" for which ps displays the
"(defunct)" state. In that case, the process has exited
and has no open file information lsof can display. It does
still have a process structure, sufficient for the needs
of ps.
Another possible explanation is that kernel tables and
structures may have been changing when lsof looked for the
process, making lsof unable to find all relevant process
structures. Try repeating the lsof request.
3.17 Why doesn't -V report a search failure?
The usual reason that -V won't report a search failure is
that lsof located the search item, but was prevented from
listing it by an option that doesn't participate in search
failure reporting.
For example, this lsof invocation:
$ lsof -V -i TCP@foobar -a -d 999
won't report it can't find the Internet address TCP@foobar,
even if there is an open file connected to that address,
unless the open file also has a file descriptor number of
999 (the ``-a -d 999'' options).
Compile-time options can also affect -V results in much the
same way. For example, if HASSECURITY and HASNOSOCKSECURITY
are defined at compile time, this lsof invocation, run by a
non-root user:
$ lsof -V -c inetd
won't report that it can't find the inetd command, even if
there is a process running the inetd command, because the
HASSECURITY and HASNOSOCKSECURITY options prevent the
listing of all but the socket files of another user, and
no socket file selector (e.g., "-i") was specified.
3.18 Portmap problems
3.18.1 Why isn't a name displayed for the portmap registration?
When portmap registration reporting is enabled, any time
there is a registration for a local TCP or UDP port, lsof
displays it in square brackets, following the port number
or service name -- e.g., ``:1234[name]'' or ``:name[100083]''.
The TCP or UDP port number or service number (what follows
the `:') is displayed under the control of the lsof -P
option. The registration identity is held by the portmapper
and may be a name or a number, depending on how the
registration's owner declared it. Lsof reports what the
port map holds and cannot derive a registration name from
a registration number.
Lsof can be compiled with registration reporting enabled
or disabled by default, under the control of the HASPMAPENABLED
#define (usually in machine.h). The lsof help panel (`lsof
-h`) will show the default. Lsof is distributed with
reporting disabled by default.
3.18.2 How can I display only portmap registrations?
Lsof doesn't have an option that will display only TCP or
UDP ports with portmap registrations. The +M option only
enables the reporting of registration information when
Internet socket files are displayed; +M doesn't select
the displaying of Internet socket files -- the -i option
does that.
This simple lsof pipe to grep will do the job:
$ lsof -i +M | grep "\["
This works because -i selects Internet socket files, +M
enables portmap registration reporting, and only output
lines with opening square brackets will have registrations.
When portmap registration reporting is enabled by default,
because the lsof builder constructed it that way, +M is
not necessary. (The lsof help panel, produced with `lsof
-h` will display the default portmapper registration
reporting state.) However, specifying +M when reporting
is already enabled is acceptable, as is specifying -M when
reporting is already disabled.
Digression: lsof will accept `+' or `-' as a prefix to most
options. (That isn't documented in the man page or help
panel to reduce confusion and complexity.) The -i option
is as acceptable as +i, so the above example could be
written a little more tersely as:
$ lsof +Mi | grep "\["
But be careful to use the ``Mi'' ordering, since ``iM''
implies M is an address argument to `i'.
3.18.3 Why doesn't lsof report portmap registrations for some ports?
Lsof reports portmap registrations for local TCP and UDP
ports only. It identifies local ports this way:
* The port appears in the local address section of the
kernel structure that contains it.
* The port appears in the foreign address section of a
kernel structure whose local and foreign Internet
addresses are the same.
* The port appears in the foreign address section of a
kernel address structure whose Internet address is
INADDR_LOOPBACK (127.0.0.1).
Following these rules, lsof ignores foreign portmapped
ports. That's done for reasons of efficiency and possible
security prohibitions. Contacting all remote portmappers
could take a long time and be blocked by network difficulties
(i.e., be inefficient). Many firewalls block portmapper
access for security reasons.
Lsof may occasionally ignore portmap registration information
for a legitimate local port by virtue of its local port
rules. This can happen when a port appears in the foreign
part of its kernel structure and the local and foreign
Internet addresses don't match (perhaps because they're on
different interfaces), and the foreign Internet address
isn't INADDR_LOOPBACK (127.0.0.1).
3.18.4 Why doesn't lsof report portmap registrations for some Solaris
versions?
In some versions of Solaris -- 9 and 10 are known to exhibit
this problem -- lsof is unable to display portmap registrations.
This portmap registration reporting failure occurs when the
Solaris netconfig field (in /etc or etc/inet) has its first two
non-comment lines enabling tcp6 and udp6. When netconfig is
configured in that fashion, lsof's attempt to read the portmap
via an RPC function fails.
I don't have an explanation for the failure, but this comment
in the netconfig(4) man page appears to have some bearing on
the problem:
# The following two entries starting with udp6 and tcp6 are
# meant to be used for IPv6. If you have Ipv6 enabled on your
# machine then you can uncomment these two lines to enable
# RPC and NFS to use the Ipv6 stack.
...
#udp6 tpi_clts v inet6 udp /dev/udp6 -
#tcp6 tpi_cots_ord v inet6 tcp /dev/tcp6 - "
My interpretation of that comment is that there is a different
RPC interface to the portmap when IPv6 is enabled. However, I
can't find any documentation on it in the RPC man pages. If
anyone has information on it, please send it to me at
<abe@purdue> and put "lsof Solaris portmap" in the subject
line.
A work-around may be to move the ucp6 and tcp6 lines after the
udp and tcxp lines in netconfig. I don't know if that change
has any unacceptable consequences, but it works for me on my
Solaris 9 test system, and I have a report that it also works
on Solaris 10.
3.19 Why is `lsof | wc` bigger than my system's open file limit?
There is a strong temptation to count open files by piping
lsof output to wc. If your purpose is to compare the number
you get to some Unix system parameter that defines the
number of open files your system can have, resist the
temptation.
One reason is that lsof reports a number of "files" that
don't occupy Unix file table space -- current working
directories, root directories, jail directories, text files,
library files, memory mapped files are some. Another reason
is that lsof can report a file shared by more than one
process that itself occupies only one file table slot.
If you want to know the number of open files that occupy
file table slots, use the +ff option and process the lsof
output's FILE_ADDR column information with standard Unix
tools like cut, grep, sed, and sort.
You might also consider using use lsof's field output with
+ff, selecting the file struct address with -FF, and
processing the output with an AWK or Perl script. See the
list_fields.awk, list_fields.perl, and shared.perl5 scripts
in the scripts/ subdirectory of the lsof distribution for
hints on file struct post-processing filters.
3.20 Why doesn't lsof report file offset (position)?
Lsof won't report a file offset (position) value if the -s
option (without parameters) has been specified, or if the
dialect doesn't support the displaying of file offset
(position). (Note that on selected dialects the help output,
obtained with -h or -?, may show that the -s option can also be
supplied the "p:s" parameters; for more information on that
addition, see the answer to the "How are protocol state name
exclusion and inclusion used?" question.)
That lsof is reporting only file size is indicated by the
fact that the appropriate column header says SIZE instead
of SIZE/OFF.
If lsof doesn't support the displaying of file offset
(position) -- e.g., for Linux /proc-based lsof -- the -h
or -? output panel won't list the -o option.
Sometimes the availability of file offset information
depends on the dialect's kernel. This is particularly true
for socket file offsets.
Maintenance of offsets for pseudo-terminal devices varies
by UNIX dialect and is related to how the dialect kernel
implements pseudo-terminal support. Kernels like AIX, for
example, that short-circuit the transfer of data between
socket and pseudo devices to reduce TCP/IP daemon interrupt
rates won't advance offsets in the TCP/IP daemon socket
files. Instead they will advance offsets in the open
standard I/O files of the shell child precess where the
pseudo-terminal devices are used.
When in doubt about the behavior of lsof in reporting file
offset information, do some carefully measured experiments,
consult the lsof sources, or contact me at <abe@purdue.edu>
to discuss the matter. Please follow the reporting guidelines
in the "How do I report an lsof bug?" section of this FAQ.
3.20.1 What does lsof report for size when the file doesn't really have
one?
When a file has no true size -- e.g., it's a socket, a
FIFO, or a pipe -- lsof tries to report the information it
finds in the kernel that describes the contents of associated
kernel buffers.
Thus, for example, size for most TCP/IP files is socket
buffer size. The size of the socket read buffer is reported
for read-only files; the size of the write buffer for
write-only files; and the sum of the buffers sizes for
read-write files.
3.21 Problems with path name arguments
3.21.1 How do I ask lsof to search a file system?
You can ask lsof to search for all open files on a file
system by specifying its mounted path name as an lsof
argument -- e.g.,
$ lsof /
Output of the mount command will show file system mounted
path names. It will also show the mounted-on device path
for the file system.
If the mounted-on device is a block device (the permission
field in output of `ls -l <device>` starts with a `b/),
you can specify it's name, too -- e.g.,
$ lsof /dev/sd0a
If the mounted-on device isn't a block device -- for example,
some UNIX dialects call a CD-ROM device a character device
(ls output starts with a `c') -- you can force lsof to
assume that the specified device names a file system with
the +f option -- e.g.,
$ lsof +f -- /dev/sd0a
(Note: you must use ``--'' after +f or -f if a file name
follows immediately, because +f and -f can be followed by
characters that specify flag output selections.)
When you use +f and lsof can't match the device to a file
system, lsof will issue a complaint.
The +f option may be used in some dialects to ask lsof to
search for an NFS file system by its server name and server
mount point. If the mount application reports an NFS file
system mounted-on value that way, then this sample lsof
request should work.
$ lsof +f -- fleet:/home/fleet/u5
Finally, you can use -f if you don't want a mounted file
system path name to be considered a request to report all
open files on the file system. This is useful when you
want to know if anyone is using the file system's mounted
path name. This example directs lsof to report on open
access to the `/' directory, including when it's being used
as a current working or root directory.
$ lsof -f -- /
The lsof -f option performs the same function as -f does
in some fuser implementations. However, since the lsof -c
option was chosen for another purpose before the `f' option
was added to lsof, +f was selected as the analogue to the
fuser -c option. (Sorry for the potential confusion.)
3.21.2 Why doesn't lsof find all the open files in a file system?
Lsof may not find all the open files in a file system for
several reasons.
First, some processes with files open on the file system
may have been changing status when lsof examined the process
table, and lsof "missed" them. Remember, the kernel changes
much faster than lsof can respond to the changes.
Second, be sure you have specified the file system correctly.
Perhaps you specified a file instead. You can use lsof's
-V option to have lsof report in detail on what it couldn't
find. Make sure the report for the file system you specified
says "file system." Here's some -V output:
$ /lsof -V /tmp ./lsof.h ./lsof
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
lsof 2688 abe txt VREG 18,1,7 1428583 226641 ./lsof
lsof 2689 abe txt VREG 18,1,7 1428583 226641 ./lsof
lsof: no file use located: ./lsof.h
You can also use lsof's +f option to force it to consider
a path name as a file system. If lsof can't find a file
system by the specified name, it will issue a complaint --
e.g.,
$ lsof +f -- /usr
lsof: not a file system: /usr
(/usr is a directory in the / file system.)
3.21.3 Why does the lsof exit code report it didn't find open files
when some files were listed?
Sometimes lsof will list some open files, yet return a
non-zero exit code, suggesting it hasn't found all the
specified files.
The first thing you should when you suspect lsof is incorrect
is to repeat the request, adding the -V option. In the
resulting report you may find that your file system
specification really wasn't a file system specification,
just a file specification.
Finally, if you specify two files or two file systems twice,
lsof will credit all matches to the first of the two and
believe that there were no matches for the second. It's
possible to specify a single file system twice with different
path names by using both its mounted directory path name
and mounted-one device name.
$ lsof +f -V spcuna:/sysprog /sysprog
COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
ksh 11092 abe cwd VDIR 39,0,1 1536 226562 /sysprog
(spcuna:/sysprog)
...
lsof: no file system use located: spcuna:/sysprog
All matches were credited to /sysprog; none to spcuna:/sysprog.
3.21.4 Why won't lsof find all the open files in a directory?
When you give lsof a simple directory path name argument
(not a file system mounted-on name), you are asking it to
search for processes that have the directory open as a
file, or as a process-specific directory -- e.g., root or
current working directory.
If you want to list instances of open files inside the
directory, you need to specify the individual path names
of those files, or use the lsof +D and +d options.
See the answer to the question "Why are the +D and +d
options so slow?" before you use +D or +d casually.
See the answer to the question "Why do the +D and +d options
produce warning messages?" for an explanation of some
process authority limitations of +D and +d.
3.21.5 Why are the +D and +d options so slow?
The +D and +d options cause lsof to build a path name search
list for a specified directory. +D causes lsof to descend
the directory to its furthest subdirectory, while +d
restricts it to the top level. In both cases, the specified
directory itself is included in the search list. In both
symbolic links are ignored.
Building such a search list can take considerable time,
especially when the specified directory contains many files
and subdirectories -- lsof must call the system readlink()
and stat() functions for each file and directory. Storing
the search list can cause lsof to use more than its normal
amount of dynamic memory -- each file recorded in the search
list consumes dynamic memory for its path name, characteristics,
and search linkages. Using the list means lsof must search
it for every open file in the system.
Building the search list for a directory specified on some
file systems can be slow -- e.g., for an NFS directory with
many files. Some file systems have special logging features
that can introduce additional delays to the building of
the search list -- e.g., NFS logging, or logging on a
Solaris UFS file system. The bottom line is that slow
search list construction may not be so much an lsof problem
as a file system problem. (Hint: if you're using Solaris
UFS logging, consider specifying the "logging,noatime"
option pair to reduce the number of atime writes to the
UFS logging queue and disk.)
A somewhat risky way to speed up lsof's building of the
search list is to use lsof's ``-O'' option. It forces lsof
to do all system calls needed to build the search list
directly, rather than in a child process. While direct
system calls are much faster, they can block in the kernel
-- e.g., when an NFS server stops responding -- stopping
lsof until the kernel operation unblocks.
As an example of the load +D can impose, consider that an
`lsof +D /` on a lightly loaded NeXT '040 cube with a 1GB
root file system disk took 4+ minutes of real time. It
also generated several hundred error messages about files
and directories the lsof process didn't have permission to
access with stat(2).
The bottom line is that +D and +d should be used cautiously.
+D is more costly than +d for deeply nested directory trees,
because of the full directory descent it causes. So use
+d where possible. And you might need to consider the
performance of the file system that holds the directory
you name with +d or +D.
In view of these warnings, when is it appropriate to use
+D or +d? Probably the most appropriate time is when you
would specify the directory's contents to lsof with a shell
globbing construct -- e.g., `lsof *`. If that's what you
need to do, `lsof +d .` is probably more efficient than
having the shell produce a directory list, form it into an
argument vector, and pass the vector to lsof for it to
unravel.
See the answer to the question "Why do the +D and +d options
produce warning messages?" for an explanation of some
process authority limitations of +D and +d.
3.21.6 Why do the +D and +d options produce warning messages?
+D and +d option processing is limited by the authority of
the lsof process -- i.e., lsof can only examine (with
lstat(2) and stat(2)) files the owner of the process can
access.
If the ownership, group membership, or permissions of the
specified directory, file within it, or directory within
it prevents the owner of the lsof process from using lstat(2)
or stat(2) on it, lsof will issue a warning message, naming
the path and giving the system's (lstat(2's or stat(2)'s)
reason (errno explanation text) for refusing access.
As an example, assume user abc has a subdirectory in /tmp,
owned by abc and readable, writable and searchable by only
its owner. If user def asks lsof to search for all /tmp
references with +D or +d, lsof will be unable to lstat(2)
or stat(2) anything in abc's private subdirectory, and will
issue an appropriate warning.
Lsof warnings can usually be suppressed with the -w option.
However, using -w with +D or +d means that there will be
no indication why lsof couldn't find an open reference to
a restricted directory or something contained in it.
Hint: if you need to use +D or +d and avoid authority
warnings, and if you have super-user power, su and use lsof
with +D or +d as root.
3.22 Why can't my C compiler find the rpcent structure definition?
When you try to compile lsof your compiler may complain
that the rpcent structure is undefined. The complaints
may look like this:
>print.c: In function `fill_portmap':
>print.c:213: dereferencing pointer to incomplete type
>...
The most likely cause is that someone has allowed a BIND
installation to update /usr/include/netdb.h (or perhaps
/usr/include/rpc/netdb.h), removing the rpcent structure
definition that lsof expects to find there.
Only Solaris has an automatic work-around. (See dlsof.h
in dialects/sun.). The Solaris work-around succeeds because
there is another header file, <rpc/rpcent.h>, with the rpcent
structure definition, and there is a Solaris C pre-processor
test that can tell when the BIND <netdb.h> is in place and
hence <rpc/rpcent.h> must be included.
Doubtlessly there are similar work-arounds possible in
other UNIX dialects whose header files have been "touched"
by BIND, but in general I recommend restoration of the
vendor's <netdb.h> and any other header files BIND might
have replaced. (I think BIND replaces <resolv.h>,
<sys/bitypes.h>, <sys/cdefs.h> -- and maybe others.)
3.23 Why doesn't lsof report fully on file "foo" on UNIX dialect
"bar?"
Lsof sometimes won't report much information on a given
file, or may even report an error message in its NAME
column. That's usually because the file is of a special
type -- e.g., in a file system specific to the UNIX dialect
-- and I haven't used a system where the file appeared
during my testing.
If you encounter such a situation, send me e-mail at
<abe@purdue.edu> and we may be able to devise an addition to
lsof that will report on the file in question. Please follow
the reporting guidelines in the "How do I report an lsof bug?"
section of this FAQ. Make sure "lsof" appears in the
"Subject:" line so my e-mail filter won't classify your letter
as Spam.
3.24 Why do I get a complaint when I execute lsof that some library
file can't be found?
On systems where the LIBPATH (or the equivalent) environment
variable is used to record the library search path in
executable files when they are built, an incorrect value
may make it impossible for the system to find the shared
libraries needed to load lsof for execution.
This may be particularly true on systems like AIX >= 4.1.4,
where the lsof Makefile takes the precautionary step of
using the -bnolibpath loader flag to insure that the path
to the private static lsof library is not recorded in the
lsof binary. Should LIBPATH be invalid when lsof is built,
it will be recorded in the lsof binary as the default
library path search order and lead to an inability to find
libraries when lsof is executed.
So, if you get missing library complaints when you try to
execute lsof, check LIBPATH, or whatever environment variable
is used on your system to define library search order in
executable files. Use the tools at your disposal to look
at the library paths recorded in the lsof binary -- e.g.,
chatr on HP-UX, dump on AIX, ldd on Solaris.
Make sure, too, that when the correct library search path
has been recorded in the executable file, the required
library files exist at one or more of the search paths.
3.25 Why does lsof complain it can't open files?
When lsof begins execution, unless it has been asked to
report only help or version information, typically it will
attempt to access kernel memory and symbol files -- e.g.,
/unix, /dev/kmem. Even though lsof needs only permission
to open these files for reading, read access to them might
be restricted by ownerships and permission modes.
So the first step to diagnosing lsof problems with opening
files is to use ls(1) to examine the ownerships and permission
modes of the files that lsof wants to open. You may find
that lsof needs to be installed with some type of special
ownership or permission modes to enable it to open the
necessary files for reading. See the "Installing Lsof"
section of 00README for more information.
3.26 Why does lsof warn "compiled for x ... y; this is z."?
Unless warnings are suppressed (with -w) or the kernel
identity check symbol (HASKERNIDCK) definition has been
deleted, all but one lsof dialect version (exception:
/proc-based Linux lsof) compare the identity of the running
kernel to that of the one for which lsof was constructed.
If the identities don't match, lsof issues a warning like
this:
lsof: WARNING: compiled for Solaris release 5.7; this is 5.6.
Two kernel identity differences can generate this warning
-- the version number and the release number.
Build and running identity differences are usually significant,
because they usually indicate kernels whose structures are
different -- kernel structures commonly change at dialect
version releases. Since lsof reads data from the kernel
in the form of structures, it is sensitive to changes in
them. The general rule is that an lsof compiled for one
UNIX dialect version will not work correctly when run on
a different version.
There are three work-arounds: 1) use -w to suppress the
warning -- and risk missing other warnings; 2) permanently
disable the identity check by deleting the definition of
HASKERNIDCK in the dialect's machine.h header file -- with
the same risk; or 3) rebuild lsof on the system where it
is to be run. (Deleting HASKERNIDCK can be done with the
Customize script or by editing machine.h.)
Generally checking kernel identity is a quick operation
for lsof. However, it is potentially slow under AIX, where
lsof must run /usr/bin/oslevel. To speed up lsof, use -w
to suppress the /usr/bin/oslevel test. See "Why does AIX
lsof start so slowly?" for more information.
3.27 How can I disable the kernel identity check?
The kernel identity check is controlled by the HASKERNIDCK
definition. When it is defined, most dialects (exclusion:
/proc-based Linux lsof) will compare the build-time kernel
identity with the run-time one.
To disable the kernel identity check, disable the HASKERNIDCK
definition in the dialect's machine.h header file. The
Customize script can be used to do that in its section
about the kernel identity check.
Caution: while disabling the kernel identity check may
result in smaller lsof startup overhead, it comes with the
risk of executing an lsof that may produce warning messages,
error messages, incorrect output, or no output at all.
3.28 Why don't ps(1) and lsof agree on the owner of a process?
Generally the user ID lsof reports in its USER column is
the process effective user ID, as found in the process
structure. Sometimes that may not agree with what ps(1)
reports for the same process.
There are sundry reasons for the difference. Sometimes
ps(1) uses a different source for process information,
e.g., the /proc file system or the psinfo structure.
Sometimes the kernel is lax or confused (e.g., Solaris
2.5.1) about what ID to report as the effective user ID.
Sometimes the system carries only one user ID in its process
structure (some BSD derivatives), leaving lsof no choice.
The differences between lsof and ps(1) user identifications
should be small and normally it will be apparent that the
confusion is over a process whose application has changed
to an effective user ID different from the real one.
3.29 Why doesn't lsof find an open socket file whose connection
state is past CLOSE_WAIT?
TCP/IP connections in states past CLOSE_WAIT -- e.g.,
FIN_WAIT_1, CLOSING, LAST_ACK, FIN_WAIT_2, and TIME_WAIT
-- don't always have open files associated with them. When
they don't, lsof can't identify them. When the connection
state advances from CLOSE_WAIT, sometimes the open file
associated with the connection is deleted.
3.30 Why don't machine.h definitions work when the surrounding
comments are removed?
The machine.h header files in dialect subdirectories have
some commented-out definitions like:
/* #define HASSYSDC "/your/choice/of/path */
You can't simply remove the comments and expect the definition
to work. That's intended to make you think about what
value you are assigning to the symbol. The assigned value
might have a system-specific convention. HASSYSDC, for
example, might be /var/db/lsof.dc for FreeBSD, but it might
be /var/adm/lsof.dc for Solaris.
Symbols defined in the lsof documentation are described in
00PORTING, other machine.h comments, and other lsof
documentation files. HASSYSDC, for example, is discussed
in 00DCACHE. When comments and documentation don't suffice,
consult the source code for hints on how the symbol is
used.
3.31 What do "can't read inpcb at 0x...", "no protocol control
block", "no PCB, CANTSENDMORE, CANTRCVMORE", etc. mean?
Sometimes lsof will report "can't read inpcb at 0x00000000",
"no protocol control block", "no PCB, CANTSENDMORE,
CANTRCVMORE" or a similar message in the NAME column for
open TCP socket files. These messages mean the file's socket
structure lacks a pointer to the INternet Protocol Control
Block (inpcb) where lsof expects to find connection addresses
-- local and foreign ports, local and foreign IP addresses.
The socket file has probably been submitted to the shutdown(2)
function for processing.
In some implementations lsof issues the "no PCB, CANTSENDMORE,
CANTRCVMORE" message, which tries to explain the absence
of a protocol control block by showing the socket state
settings that have been made by the shutdown(2) function.
If a non-zero address follows the "0x" in the "can't read
inpcb" message, it means lsof couldn't read inpcb contents
from the indicated address in kernel memory.
3.32 What do the "unknown file system type" warnings mean?
Lsof may report a message similar to"
unknown file system type, v_op: 0x10472f10
in the NAME column for some files.
This means that lsof has encountered a vnode for the file
whose operation switch address (from v_op) references a
file system type for which there is no support in lsof.
After lsof identifies the file system type, it uses
pre-compiled code to locate the file system specific node
for the file where lsof finds information like file size,
device number, node number, etc.
To get some idea of what the file system type might be,
use nm on your kernel symbol file to locate the symbol name
that corresponds to the v_op address -- e.g., on Solaris
do:
$ nm -x /dev/ksyms | grep 0x10472f10
0x10472f10 ... |file_system_name_vnodeops
Where "file_system_name" is the clue to the unsupported
file system.
Lsof doesn't use the v_op address to identify file system
types on all dialects. Sometimes it uses an index number
it finds in the vnode. It will translate that symbol to
a short name in the warning message -- e.g., "nfs3" -- if
possible.
3.33 Installation
3.33.1 How do I install lsof?
There is no "standard" way to install lsof. Too much
depends on local conditions for me to be able to provide
working install rules in the lsof make files. (The skeleton
install rules you will find just give "hints.") See the
"Installing Lsof" section of 00README for a fuller explanation.
To install lsof you will need to consider these questions:
* Who should be able to use lsof? (See HASSECURITY and
HASNOSOCKSECURITY in the "Security" section of 00README.)
* Where should lsof be installed? This is a decision
mostly dictated by local conditions. Somewhere in
/usr/local -- etc/ or sbin/ -- is a common choice.
* What permissions should I give the lsof executable?
The answer to this varies by dialect. The make files
have install rules that give hints. The "Installing
Lsof" section of 00README gives information, too.
* What if I want to install lsof in a shared file system
for machines that require different lsof configurations?
See the next question and answer, "How do I install a
common lsof when I have machines that need differently
constructed lsof binaries?"
3.33.2 How do I install a common lsof when I have machines that
need differently constructed lsof binaries?
A dilemma that faces some system administrators when they
install lsof in a shared file system -- e.g., NFS -- is
that they must have different lsof executables for different
systems.
The answer is to build an lsof wrapper script that is
executed in place of lsof. The script can use system
commands to determine which lsof binary should be executed.
Consider this example. You have HP-UX machines with 32
and 64 bit kernels that share the /usr/local/sbin directory
where you want to install lsof. Consequently, on each
system you must use a different lsof executable, built for
the system's bit size. (That's because lsof reads kernel
structures, sized by the kernel's bit size.)
One answer is to install three things in /usr/local/sbin:
1) a 32 bit lsof as lsof32; 2) a 64 bit lsof as lsof64;
and 3) an lsof script. The script might look like this
one, based on work by Amir J. Katz:
#!/bin/sh
x=`/usr/bin/getconf KERNEL_BITS` # returns 32 or 64
if /usr/bin/test "X$x" = "X32"
then
lsof32 $*
else
if /usr/bin/test "X$x" = "X64"
then
lsof64 $*
else
echo "Can't determine which lsof executable to use;"
echo "getconf KERNEL_BITS says: $x"
exit 1
fi
fi
Solaris users should consult "How do I install lsof for
Solaris 7, 8 or 9?" for information on a similar trick
using the Solaris isaexec command.
Users of other dialects might be able to use a command like
uname(1) that can identify a distinguishing feature of the
system to be incorporated in pre-installed lsof executable
names. For example, use `uname -r` and install binaries
with suffixes that match `uname -r` output.
3.34 Why do lsof 4.53 and above reject device cache files built
by earlier lsof revisions?
When lsof revisions 4.53 run and encounter a device cache
file built by an earlier revision, it will reject the file
and build a new one. The rejection will be advertised with
these messages:
lsof: WARNING: no /dev device in <name>: 2 sections
...
lsof: WARNING: created device cache file: <name>
This happens because the header line of the device cache
file was changed at revision 4.53 to contain the number of
the device on which the device directory resides. The old
device cache file header line -- the "2 sections" line in
the above warning message, node reads "2 sections, dev=600".
This is not a serious problem, since lsof automatically
rebuilds the device cache file with the correct header
line.
3.35 What do "like block special" and "like character special" mean
in the NAME column?
When lsof comes across an open block or character file
whose device, raw device and inode place it somewhere other
than /dev (or /devices), lsof doesn't report the /dev (or
/devices) name in the NAME column. Instead lsof reports
the file system name and device or path name in the NAME
column and parenthetically adds "like block special <path>"
or "like character special <path>".
The value for <path> will point to a block or character
device in /dev (or /devices) whose raw device number matches
that of the open file being reported, but whose device
number or node number (or both) don't match.
Such an open file is connected to a device node that has
been created in a directory other than /dev (or /devices.)
See mknod(8) for information on how such nodes are created.
(Generally one needs root power to create device nodes with
mknod.)
3.36 Why does an lsof make fail because of undefined symbols?
When lsof is compiled via the `make` step and the final
load step fails because of missing symbols, the problem
may not be lsof. The problem may be that ld, called by
the compiler as part of the `make` step, can't find some
library that lsof needs.
First check the last compiler line of the make operation
-- e.g., the last line with cc or gcc in it before the
undefined symbol report -- for loader arguments, i.e.,
ones beginning with "-l". Except for "-llsof" the rest
name system libraries. ("-L./lib" precedes "-llsof" to
tell the loader its location.)
Check that all the named system libraries exist. Look in
/lib and /usr/lib as a start, but that may not be the only
place system libraries live. Consult your dialect's
documentation, e.g., the compiler and loader man pages,
for other possible locations.
If some system library doesn't exist, that may mean it was
never installed or was removed. You'll have to re-install
the missing library.
You may find that all the system libraries lsof uses exist.
Your next step might be to use nm and grep to see if any
of them contain the undefined symbols.
$ nm library | grep symbol
If the undefined symbol exists in some library named by
the lsof make step, then you might have a problem with some
environment variable that controls the load step. The most
common is LD_LIBRARY_PATH. It may have a setting that
causes ld to ignore a directory containing a library lsof
names. If this is the case, try unsetting LD_LIBRARY_PATH
in the environment of the ld process -- e.g., do:
$ unset LD_LIBRARY_PATH
or
% unsetenv LD_LIBRARY_PATH
Consult your ld man page for other environment variables
that might affect library searching -- e.g., LIBPATH, LPATH,
SHLIB_PATH, etc.
If the undefined function doesn't exist in any libraries
lsof names, check other libraries. See if the function
has a man page that names its library. If the latter is
true, please let me know, because that is an lsof problem
I need to fix.
If none of these solutions work for you, send me some
documentation via e-mail at <abe@purdue.edu>. Include `uname
-a` output, the output of the lsof `Configure ...` and `make`
steps, and the contents of the environment in force when the
`make` step was executed -- e.g., `env` or `printenv` output.
If you've located the libraries lsof names, send me that
information, too. Make sure "lsof" appears in the "Subject:"
line so my e-mail filter won't classify your letter as Spam.
3.37 Command Regular Expressions (REs)
3.37.1 What are basic and extended regular expressions?
Lsof's ``-c'' option allows the specification of regular
expressions (REs), enclosed in two slash ('/') characters and
followed by these modifiers:
b the RE is a basic RE.
i ignore case.
x the RE is an extended RE (the default).
Note: the characters of the regular expression may need to
be quoted to prevent their expansion by the shell.
Example: this RE is an extended RE that matches exactly
four characters, whose third may be an upper ('O') or lower
case ('o') oh:
-c /^..o.$/i
For simplicity's sake, an RE that is acceptable to egrep(1)
is usually called an extended RE.
REs suitable for the old line editor, ed(1), are often
called basic REs (and sometimes also called obsolete).
These are some ways basic REs usually differ from extended
REs. (There are other differences.)
* `|', `+', `?', '{', and '}' are ordinary characters.
* `^' is an ordinary character except at the beginning of
the RE.
* `$' is an ordinary character except at the end of the
RE.
* `*' is an ordinary character if it appears at the
beginning of the RE.
For more information on REs and the distinction between
basic and extended REs, consult your dialect's man pages
for ed(1), egrep(1), sed(1), and possibly regex(5) or
regex(7).
3.37.2 Why can't I put a slash in a command regular expression?
Since a UNIX command name is the last part of a path to
the command's executable, the lsof command regular expression
(RE) syntax uses slash ('/') to mark the beginning and end
of an RE. Slash may not appear in the RE and the `\'
back-slash escape is ineffective for "hiding" it.
More likely than not, if you try to put a slash in an lsof
command RE, you'll get this response:
$ lsof -s/.\// ...
lsof: invalid regexp modifier: /
Lsof is complaining the the first character it found after
the second slash isn't an lsof command RE modifier -- 'b',
'i', or 'x'.
3.37.3 Why does lsof say my command regular expression wasn't found?
When you use both forms of lsof's -c option --
``-c <command>'' and ``-c /RE/[m]'' -- and ask that lsof
do a verbose search (``-V''), you may be surprised that
lsof will say that the regular expression wasn't found.
This can happen if the ``-c <command>'' form matches first,
because then the ``-c/RE/[m]'' test will never have been
applied. For example:
$ ./lsof -clsof -c/^..o.$/ -V -adcwd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
lsof 7850 abe cwd VDIR 6,0 2048 96442 / (/dev/sd0a)
lsof: no command found for regex: ^..o.$
The ``-clsof'' option matched first, so the ``-c/^..o.$/
option wasn't tested.
3.38 Why doesn't lsof report on shared memory segments?
Lsof reports on shared memory segments only if they're
associated with an open file. That's consistent with lsof's
mission -- to LiSt Open Files. Shared memory segments with
no file associations aren't open files.
That's not to say that a report on shared memory segments
and their associated processes wouldn't be useful. But it
calls for a new tool, not more baggage for lsof.
3.39 Why does lsof report two instances of itself?
When you ask lsof to report all open files and it has
permission to do so, you may see two lsof processes in the
output. The processes are connected via pipes -- e.g.,
here's an HP-UX 11 example.
COMMAND PID USER FD TYPE DEVICE ...
...
lsof 29450 abe 7w PIPE 0x48732408 ...
lsof 29450 abe 8r PIPE 0x48970808 ...
...
lsof 29451 abe 6r PIPE 0x48732408 ...
lsof 29451 abe 9w PIPE 0x48970808 ...
The first process will usually be the lsof you initiated;
the second, an lsof child process that is used to isolate
its parent process from kernel functions that can block --
e.g., readlink() or stat().
Information to and from the kernel functions is exchanged
via the two pipes. When the parent process detects that
the child process has become blocked, it attempts to kill
the child. Depending on the UNIX dialect that may succeed
or fail, but the parent won't be blocked in any event.
See the "BLOCKS AND TIMEOUTS" and "AVOIDING KERNEL BLOCKS"
sections of the lsof man page for more information on why
the child process is used and how you can specify lsof
options to avoid it. (Caution: that may be risky.)
3.40 Why does lsof report '\n' in device cache file error messages?
Lsof revisions prior to 4.58 may report '\n' in error
messages it delivers about problems in the device cache
file -- e.g.,
lsof: WARNING: no ...: 4 sections\n
That's deliberately done to show the exact contents of the
device cache file line about which lsof is complaining,
including its terminating NL (New Line) '\n' character.
In the above example the line in the device cache file
causing the lsof complaint contains "4 sections" and ends
with a '\n'.
At revision 4.58 and above, device cache error messages
like the one in the above example have been changed to
read:
lsof: WARNING: no ...: line "4 sections"
The terminal '\n' is no longer reported, the line contents
are enclosed in double quote marks ('"'), and the word
"line" has been added as a prefix to denote that what
follows is a line from the device cache file.
3.41 Kernel Symbol and Address Problems
3.41.1 What does "lsof: WARNING: name cache hash size length error: 0"
mean?
When run on some systems, lsof may issue this warning:
lsof: WARNING: name cache hash size length error: 0
That is an example from a FreeBSD system where lsof reads
the kernel's _nchash variable and finds its value is zero.
Similar warnings include:
WARNING: kernel name cache size:
WARNING: can't read kernel's name cache:
WARNING: no name cache address
WARNING: name cache hash size length error:
WARNING: unusable name cache size:
These warnings are issued when lsof is attempting to read
the kernel's name cache information. They are usually the
result of a mis-match between the addresses for kernel
symbols lsof gets via nlist(2) and the addresses in use by
the kernel.
Lsof usually gets kernel symbol addresses from what it
believes to be the kernel boot file. In FreeBSD, for
example, that's the path returned by getbootfile(3), usually
/kernel. The boot file can have other names in other UNIX
dialects -- /unix, /vmunix, /bsd, /netbsd, /mach, /stand/vmunix,
etc.
Lsof will get incorrect (mismatched) addresses from the
boot file if it has been replaced by a newer one which
hasn't yet been booted -- e.g., if this is done in FreeBSD:
# mv /kernel /kernel.OLD
# mv /kernel.NEW /kernel
Until the FreeBSD system is rebooted, the booted kernel is
/kernel.OLD, but getbootfile() says it is /kernel. If
symbol addresses important to lsof in /kernel.OLD and
/kernel don't match, the lsof WARNING messages result.
3.41.2 Why does lsof produce "garbage" output?
Kernel name cache warnings may not be the only sign that
lsof is using incorrect symbol addresses to read kernel
values. If there's no reasonable test lsof can make on
what it reads from the kernel, it may issue other warnings
or even report nonsensical results.
The warnings may appear on STDERR, such as:
lsof: can't read proc table info
Or the warnings may appear in the NAME column as messages
saying lsof can't read or interpret some kernel structure --
e.g.,
... NAME
... can't read file struct from 0x12345
One possible work-around is to point lsof's kernel symbol
address gathering at the proper boot file. That can be
done with lsof's -k option -- e.g.,
$ lsof -k /kernel.OLD
The best work-around is to make sure the standard boot file
is properly sited -- e.g., if you've moved a new /kernel
in place, boot it.
3.42 Why does lsof report open files when run as super user that
it doesn't report when run with lesser privileges?
The most likely cause is that the HASSECURITY option was
selected when the lsof executable was built.
If HASSECURITY is defined when lsof is built, and lsof is
run with the privileges of a non-ROOT user, it will only
list open files belonging to the user. The same lsof
executable, when run with root user privileges, will list
all open files.
However, if HASSECURITY and HASNOSOCKSECURITY are both
defined when lsof is built, lsof will list open files
belonging to the user and will also list anyone else's open
socket files, provided their listing is selected with the
"-i" option.
So first ask yourself if the process whose open files lsof
won't list belong to a user other than the one under which
you're running lsof, and are not open socket files. If
either is true, use lsof's help (-h or -?) option and look
for a line near the bottom of the help panel that says:
"... can list all files..."
If the leading "..." says "Only root" then HASSECURITY was
defined when lsof was built. If the trailing "..." says
", but anyone can list socket files" then HASNOSOCKSECURITY
was also defined.
Should you want an lsof not built with HASSECURITY defined,
rerun the lsof Configure script. If you let Configure do
customization, make sure you answer 'n' when it asks if
you want to enable HASSECURITY and HASNOSOCKSECURITY. If
you don't need to do customization, you can rebuild lsof
with the "-n" option to Configure. Here's an example of
such a rebuild sequence:
$ Configure -clean
$ Configure -n <dialect-abbreviation>
$ make
More information on the HASSECURITY and HASNOSOCKSECURITY
options may be found in the "Security" section of the
00README file of the lsof distribution.
3.43 Test Suite Problems
3.43.1 Errors all tests can report:
3.43.1.1 Why do tests complain "ERROR!!! can't execute ../lsof"?
All tests in the test suite expect an executable lsof file
to exist in the tests parent directory, ../lsof.
If there's none there, the tests/Makefile has a rule to
make it, but there are probably circumstances where that
rule may fail.
The work-around is to re-Configure and re-make lsof, then
run the test suite.
3.43.1.2 Why do tests complain "ERROR!!! can't find ..." a file?
Many tests create (or use from a supplied environment
variable path) a test file and use lsof to find it. When
lsof can't file the file, the tests report the error with
messages of the form:
ERROR!!! can't find ... : <some file path>
or
ERROR!!! lsof couldn't find ...
These type of error messages mean that the lsof field output
delivered to the test didn't contain a file that the test
could identify as the one it intended lsof to find. It
might also mean that the process information -- command
name, PID or parent PID -- didn't match what the test
expected.
This could imply a bug in the test or a bug in lsof. Try
using lsof to find a known file that is open. For example,
while in the tests sub-directory, do this:
$ sleep 30 < Makefile
$ ../lsof Makefile
If lsof doesn't report that Makefile is open, then the
fault may be with lsof. If lsof reports the file is open,
search further in the test code for the failure cause.
3.43.1.3 Why do some tests fail to compile?
If a test suite program fails to compile, it may be because
I've never had an opportunity to compile the test on the
particular UNIX version you are using.
See Appendix B in 00TEST for a list of the UNIX dialects
where the test suite has been validate.
3.43.1.4 Why do some tests always fail?
There are several tests in the optional group that have
conflicting or special requirements:
LTbigf needs a dialect and file system that support
large files.
LTlock won't work if the tests/ sub-directory is
on an NFS file system.
LTnfs won't work if the tests/ sub-directory is
not on an NFS file system.
So for two tests in particular, LTlock and LTnfs, one will
generally fail.
Some failing tests can be run successfully by supplying to
them a path to the appropriate type of file system with
the -p option.
3.43.1.5 Why does the test suite say it hasn't been validated on
my dialect?
When you use the default rule of the test suite's Makefile,
it may issue this complaint:
$ cd tests
$ make
!!!WARNING!!!
This dialect or its particular version may not have
been validated with the lsof test suite. Consequently
some tests may fail or may not even compile.
!!!WARNING!!!
You are then given the opportunity to answer 'y' to have
the test suite operation continue.
This message means that the tests/TestDB file in the tests
sub-directory doesn't show that the test suite has been
run with the combination of compiler flags found in
tests/config.cflags. The tests might nor run; they may
encounter compiler failures.
See 00TEST for more information on the UNIX dialects where
the test suite has been validated and on the workings of
TestDB and its supporting scripts.
When the tests/Makefile "auto" rule is used, the message
is more terse and the condition is fatal.
This suite has not been validated on:
<dialect_description>
No opportunity to continue is offered.
The tests/Makefile "silent" rule will skip checking for
the validation footprint.
3.43.1.6 Why do the tests complain they can't stat() or open()
/dev/mem or /dev/kmem?
When the tests detect that lsof for the dialect reads its
information from kernel memory (i.e., the LT_KMEM definition
is present in tests/config.cflags), and when the lsof
executable path is ../lsof, the tests make sure they can
stat() and open() for read access the relevant kernel memory
devices, /dev/kmem and possibly /dev/mem.
If those stat() or open() operations fail, the tests issue
an error message and quit. The message explains why the
system rejected the operation in terms of system "errno"
symbols and messages. More often than not the explanation
will be that the process lacks permission to access the
indicated device node.
One work-around is to give the lsof executable being tested
the necessary permission -- e.g., via chgrp, chmod, etc.
-- and set its path in the LT_LSOF_PATH environment variable.
(See 00TEST.)
Another work-around is to make sure the process that runs
the tests has the necessary permissions -- e.g., run it as
root, or enable the process login to access the resources.
For example, I can run the tests on my personal work-station
because /dev/kmem and /dev/mem are readable by the "kmem"
group and my login is in that group.
3.43.2 LTbigf test issues
3.43.2.1 Why does the LTbigf test say that the dialect doesn't
support large files?
Large file support is defined dialect by dialect in the
lsof source files and Configure script. If large file
support isn't defined there, it isn't defined in the LTbigf
test.
If you think that's wrong for a particular dialect, contact me
via e-mail at <abe@purdue.edu>. Make sure "lsof" appears in the
"Subject:" line so my e-mail filter won't classify your letter
as Spam.
3.43.2.2 Why does LTbigf complain about operations on its config.LTbigf*
file?
The LTbigf must be able to write a large file test (size
> 32 bits) and seek within it and the process file ulimit
size must permit the operation. If the default location
for the test file, tests/, isn't on a file system enabled
for large file operations or if the process ulimit file
block size is too small, lsof will get file operation
errors, particularly when seeking
There may be a work-around. Specify the path to a file
LTbigf can write in a file system enabled for large file
operations a the -poption. Make sure that the ulimit file
block size permits writing a large file. For example,
presuming /scratch23 is large-file-enabled, and presuming
you have permission to raise the ulimit file block size,
this shell commands will allow the LTbigf test to run on
AIX:
$ ./LTbigf -p /scratch23/abe/bigfile
(Note: syntax for the ulimit command varies by dialect and
by shell. Discovering the proper variant is left to the
reader.)
More information on this subject can be found in the LTbigf
description in the 00TEST file. If course, the LTbigf.c
source file in tests/ is the ultimate source of information,
3.43.2.3 Why does LTbigf warn that lsof doesn't return file offsets?
On some dialects (e.g., Linux) lsof can't report file
offsets, because the data access method underlying lsof
doesn't provide them. If LTbigf knows that lsof can't
report file offsets for the dialect, it issues this warning:
LTbigf ... WARNING!!! lsof can't return file offsets
for this dialect, so offset tests have
been disabled.
LTbigf then performs the size test and skips the offset
tests.
For more information see 00TEST and the "Why doesn't
/proc-based lsof report file offsets (positions)?" Q&A of
this file.
3.43.3 Why does the LTbasic test complain "ERROR!!! lsof this ..."
and "ERROR!!! lsof that ..."?
The LTbasic test program uses lsof to examine a running
lsof process. It looks for the lsof current working
directory, executable (if possible), and kernel memory file
(if applicable).
Failures to find those things result in the LTbasic error
messages. More information on how LTbasic produces the error
messages may be found in the LTbasic.c source file.
On HP-UX 11.11 and higher, for example, if the test's current
working directory is on a loopback (LOFS) file system, LTbasic
won't be able to find the current working directory of the lsof
process because of a bug in the HP-UX kernel.
The solution for that HP-UX problem is to install an HP-UX
patch. See the answer to the "Why doesn't PSTAT-based lsof
report a CWD that is on a loopback (LOFS) file system?"
question for more information on the patch.
3.43.4 NFS test issues
3.43.4.1 Why does the LTnfs test complain "couldn't find NFS file ..."?
The LTnfs test must work with an NFS test file. After it
opens the file it asks lsof to find it on an NFS file system.
If the file isn't on an NFS file system, lsof won't find it,
and the NFS test script complains and fails.
The work-around is to use -p option to supply a path to a
regular NFS file (not a directory) that is on an NFS file
system that LTnfs can read. Presuming /share/bin/file is
such a file and can be opened for reading by the LTnfs
test, this sample shell command could be used to run the
LTnfs test successfully:
$ ./LTnfs -p /share/bin/file
(If the NFS file system is enabled for large files, the
NFS test will produce the error message described in the
following Q&A.)
3.43.5 LTnlink test issues
3.43.5.1 Why does the LTnlink test complain that its test file is on
an NFS file system?
The LTnlink test may complain:
LTnlink ... WARNING!!! test file <path> is NFS mounted.
and then issue an explanation and a hint about using the
-p option.
The LTnlist test does this because of the way NFS file
links are managed when an NFS file is unlinked and the
unlinking process still has the file open. Unlike with
files on a local file system, when an NFS file that is
still open is unlinked, its link count is not reduced.
The file name is changed to a name of the form .nfsxxxx
and the link count is left unchanged until the process
holding the file open closes it. That's done by NFS so it
can keep proper track of the file on NFS clients and servers.
Since the link count isn't reduced when the LTnlink test
program closes the NFS test file it still has open, lsof
won't find it for LTnlink with a link count of zero.
Consequently, LTnlink disables that test section and issues
its warning.
The warning suggests that the unlink test section can be
run by giving LTnlink a path to a test file with the -p
option. That path must name a file LTnlink can write and
unlink. Presuming /scratch23/abe/nlinkfile is on a local
file system and the LTnlink test can write to it and unlink
it, this sample shell command can be used to run the complete
LTnlink test successfully:
$ LTnlink -p /scratch23/abe/nlinkfile
3.43.5.2 Why does LTnlink delay and report "waiting for link count
update: ..."?
On some UNIX dialects and file system combinations the
updating of link count after a file has been unlinked can
be delayed. Consequently, lsof won't be able to report
the updated link count to LTnlink for a while.
When lsof doesn't report the proper link count to LTnlink,
it sleeps and repeats the lsof call, using the "waiting
for link count update: ..." message as a signal that it is
waiting for the expected lsof response. The wait cycle
duration is limited to approximately one minute.
3.43.5.3 Why does LTnlink fail because of an unlink error?
LTnlink may fail with an error similar to:
LTnlink ... ERROR!! unlink(<name>) failed: (Permission denied).
That message will be followed by a short explanation.
The error means that the kernel support for the file system on
which the file <name> resides does not allow a process to
unlink a file while it has the file open. (When LTnlink is run
without the "-p path" option, it creates a <name> that begins
with "./config.LTnlink" and ends with the LTnlink process ID
number.)
An unlink failure of this type runs counter to original UNIX
file system behavior, but it has been observed on some file
system types, especially on the ZFS file system.
The work-around is to run LTnlink on a file system that allows
a process to unlink a file it has open. Usually /tmp has that
support. So, try running LTnlink this way:
$ ./LTnlink -p /tmp/<name>
where <name> is a unique name in /tmp of your choosing. To
be safe, create a subdirectory in /tmp, named by your login:
$ rm -f /tmp/<login>
$ mkdir /tmp/<login>
$ ./LTnlink -p /tmp/<login>/<name>
3.43.6 LTdnlc test issues
3.43.6.1 Why won't the LTdnlc test run?
Lsof is unable to access the DNLC cache on AIX, because the
kernel symbols for the DNLC aren't exported. Contact IBM
to learn why that decision was made.
The LTdnlc test won't work on Apple Darwin because lsof
can't obtain reliable DNLC information.
The LTdnlc test may fail on other dialects. Failure causes
include: a busy system with a DNLC that is changing rapidly;
path name components too large for the DNLC; a file system
-- e.g., NFS, /tmp, loopback -- which doesn't fully
participate in the DNLC; or DNLC limitations (Many DNLC
implementations will only store path name components if
they are 31 characters or less.)
If you suspect the file system doesn't fully participate
in kernel DNLC processing, as a work-around rebuild and
test lsof on one that does.
3.43.6.2 What does the LTdnlc test mean by "... <path> found: 100.00%"?
Even when it succeeds the LTdnlc test will report:
LTdnlc ... /export/home/abe/src/lsof4/tests found: 100.00%
This message means that the LTdnlc test asked lsof to find
the file at the indicated path five times and lsof found
the full path name in the indicated percentage of calls.
The LTdnlc test considers it a failure if the percentage
falls below 50.0%
3.43.6.3 Why does the DNLC test fail?
The DNLC test may fail when some component of the lsof
tests/ sub-directory can't be cached by the kernel DNLC.
Some kernels have a limit on the length of individual
components (typically) 32.
3.43.7 Why hasn't the test suite been qualified for 64 bit HP-UX
11 when lsof is compiled with gcc?
When I attempted to qualify lsof for HP-UX 11, compiled
with gcc 3.0, the LTsock test failed. I traced the failure
to a gcc compilation error. Because LTsock is an important
test, I didn't feel that the test suite was qualified if
it failed.
LTsock compiles and runs correctly on 64 bit HP-UX 11 when
compiled with HP's ANSI-C.
3.43.8 LTszoff test issues
3.43.8.1 Why does LTszoff warn that lsof doesn't return file offsets?
On some dialects (e.g., Linux) lsof can't report file
offsets, because the data access method underlying lsof
doesn't provide them. If LTszoff knows that lsof can't
report file offsets for the dialect, it issues this warning:
LTszoff ... WARNING!!! lsof can't return file offsets
for this dialect, so offset tests have
been disabled.
LTszoff then performs the size test and skips the offset
tests.
For more information see 00TEST and the "Why doesn't
/proc-based lsof report file offsets (positions)?" Q&A of
this file.
3.43.9 LTlock test issues
3.44 File descriptor list (the ``-d'' option) problems
3.44.1 Why does lsof reject a ``-d'' FD list?
Lsof rejects ``-d'' FD lists that contain both exclusions
and inclusions with messages like:
lsof: exclude in an include list: ^1
lsof: include in an exclude list: 2
That's because ``-d'' FD lists are processed as ORed lists,
so it makes no sense for them to contain both exclusions
and inclusions.
I.e.,, if a ``-d'' FD list were to contain ``^cwd,1'', the
``^cwd'' member is useless, because the ``1'' member
dominates by saying "include only FD 1". That effectively
excludes ``cwd'' FD.
Note that lists may have multiple members of the same type,
exclude or include. They are processed as an ORed set.
If an FD isn't excluded by any member of an exclude list,
it is selected. If an FD is included by any member of an
include list, it is selected.
3.44.2 Why are file descriptors other than those in my FD list
reported?
The FD list that follows ``-d'' excludes or includes file
descriptors, but unless the ``-a'' (AND) option is specified,
the FD list selections are ORed to the other selections.
For example, the following lsof command will cause all file
descriptors to be listed for the lsof command, and all but
the cwd descriptor for all other commands, probably not
what was intended.
$ lsof -clsof -d^cwd
Hint: use ``-a'' -- e.g.,
$ lsof -clsof -a -d^cwd
3.45 How can I supply device numbers for inaccessible NFS file
systems?
When lsof can't get device numbers for inaccessible NFS file
systems via stat(2) or lstat(2), it attempts to get them from
the mount table's dev=xxx options. Successes are reported with
a warning message that indicates the source of the device
number and that output might be incomplete as a consequence of
the warnings.
Some system mount tables -- e.g., Linux /proc/mounts -- don't
have a dev=xxx option. In that case, and provided lsof for the
dialect supports them, you can use the +m option to create a
mount table supplement file and the "+m m" option to use it.
First check the lsof -h (help) output to see if the +m and
"+m m" options are supported. If they are, use +m to create a
mount table supplement file when all mounted file systems are
accessible. Use "+m m" later to make the supplement available
when some mounted file systems might not be available.
Here's an example that creates a mount supplement file in
$HOME/mnt-sup and later makes it available to lsof.
$ rm -f $HOME/mnt-sup
$ lsof +m > $HOME/mnt-sup
...
$ lsof +m $HOME/mnt-sup <other lsof options>
If lsof has to get the device number from the supplement, it
will issue an informative warning message. The warning can be
suppressed with lsof's -w option.
Caution! Since the mount table supplement file is static, it
is its supplier's responsibility to update it as file system
mounts change.
For more information, consult the lsof man page. The
"ALTERNATE DEVICE NUMBERS" section has useful information on
how lsof acquires device numbers when stat(2) or lstat(2)
fail.
3.46 Why won't lsof find open files on over-mounted file systems?
When a file system, /xyz for example, is mounted on the same
mount point as another file system, /abc for example, running
lsof with an argument of the path of the first file system's
mount point -- the over-mounted one, /abc -- probably will not
reveal any files open on /abc.
That's because lsof looks for open files on a file system by
looking for files with the file system's device number. The
two file systems usually have different device numbers and lsof
determines the device number search key from the supplied name
of the second file system.
A general work-around exists only for Linux. On that UNIX
dialect, when you know the over-mounted file system's mount
point path, you can ask lsof to report on all open files and
grep that output for the path of the over-mounted file system
mount point.
3.47 What can be done when lsof reports no more space?
Many lsof methods cache information in memory, using the
dialects malloc() library function. When malloc() can't
allocate the requested amount of memory, lsof exits with
warning messages similar to this AIX message:
lsof: no more dev-ch space at pid 2257750: 0x82a8e600
Lsof then exits immediately and produces no more output.
A possible work-around is to increase the memory foot print
of the shell that runs lsof. That is often done with the
ulimit(1) shell command.
3.48 What if the lsof build encounters ar and ld problems?
The lsof main and library Makefiles use the library archiver,
ar, and the system loader, ld, applications. Improperly
located, installed or configured versions of them may cause the
lsof build to encounter errors with them.
The application producing the error should identify itself in
its error messages.
The first thing to check the path of the application that is
being used. Try `which ar` or `which ld` to see if perhaps the
PATH used during the build might be causing the wrong archiver
or loader to be used.
If the problem is with the use of the wrong archiver, and it's
not possible to correct the PATH to it, try using the LSOF_AR
environment variable to specify the path to and arguments for
the correct archiver. See 00XCONFIG for more information and
note that LSOF_AR must specify the path to the archive
application and the arguments for it, less the terminating
library and module name arguments.
If the problem is with the loader, there is no lsof work-
around. That's because lsof calls the loader via the C
compiler, so the problem must be fixed at the compiler (system)
level.
3.49 Why does lsof -i report an open socket file for a process, but
lsof -p on that process' ID report nothing?
The lsof in use was probably built with the HASSECURITY and
HASNOSOCKSECURITY options and the process in question does not
belong to the user of lsof.
The HASSECURITY option limits lsof output to processes owned
by the user invoking lsof and the HASNOSOCKSECURITY option
weakens that slightly to allow output of open socket file
information for all processes.
For example, if process PID 12345 is owned by some user other
than the one invoking lsof, and lsof has been compiled with the
HASSECURITY and HASNOSOCKSECURITY options, the following lsof
command will display the open socket files of process 12345:
$ lsof -p 12345 -a -i
This security restriction is described in the lsof(8) manual
page.
4.0 AIX Problems
4.1 What is the Stale Segment ID bug and why is -X needed?
Kevin Ruderman reports that he has been informed by IBM
that processes using the AIX 3.2.x, 4.1[.12345]], 4.2[.1],
and 4.3.x kernel's readx() function can cause other AIX
processes to hang because of what appears to be file system
corruption.
This failure, known as the Stale Segment ID bug, is caused
by an error in the AIX kernel's journaled segment memory
handler that causes the kernel's dir_search() function
erroneously to believe directory entries contain zeroes.
The process using the readx() call need not be doing anything
wrong. Usually the system must be under such heavy load
that the segment ID being used in the readx() call has been
freed and then reallocated to another process since it was
obtained from kernel memory.
Lsof uses the readx() function to access library entry
structures, based on the segment ID it finds in the proc
structure of a process. Since IBM probably will never fix
the kernel bug, I've added an AIX-specific option to lsof
that controls its use of the readx() function.
By default lsof readx() use is disabled; specifying the
``-X'' option enables readx() use.
If you want to change the default readx() behavior of AIX
lsof, change the HASXOPT, HASXOPT_ROOT, and HASXOPT_VALUE
definitions in dialects/aix/machine.h. You can also use
these definitions to enable or disable readx() -- consult
the comments in machine.h. You may want to disable readx()
use permanently if you plan to make lsof publicly executable.
When HASXOPT_ROOT is defined, lsof will restrict use of
the -X option to processes whose real UID is root; if
HASXOPT_ROOT isn't defined, any user may specify the -X
option. The Customize script offers the option to change
HASXOPT_ROOT when HASXOPT is defined and HASXOPT_ROOT is
named in any dialect's machine.h header file.
I have never seen lsof cause a problem with its use of
readx(), but I believe there is some chance it could, given
the right circumstances.
4.1.1 Stale Segment ID APAR
Here are the details of the Stale Segment ID bug and IBM's
response, provided by Kevin Ruderman.
AIX V3
APAR=ix49183
user process hangs forever in kernel due to file
system corruption
STAT=closed prs TID=tx2527 ISEV=2 SEV=2
(A "closed prs" is one closed with a Permanent
ReStriction.)
RCOMP=575603001 aix v3 for rs/6 RREL=r320
AIX V4 (internal defect, no apar #)
prefix p
name 175671
abstract KERMP: loop for ever in dir_search()
Problem description:
1. Some user application -- e.g., lsof -- gets the segment
ID (SID) for the process private segment of a target
process from the process table.
2. The target process exits, deleting the process private
segment.
3. The SID is reallocated for use as a persistent segment.
4. The user application runs again and tries to read the
user area structure from /dev/mem, using the SID it read
from the process table.
5. The loads done by the driver for /dev/mem cause faults
in the directory; new blocks are allocated; the size
changed; and zero pages created.
6. The next application that looks for a file in the affected
directory hangs in the kernel's dir_search() function
because of the zero pages. This occurs because the
kernel's dir_search() function loops through the variable
length entries one at a time, moving from one to the
next by adding the length of the current entry to its
address to get the address of the next entry. This
process should end when the current pointer passes the
end of the known directory length.
However, while the directory length has increased, the
entry length data has not, so when dir_search() reaches
the zero pages, it loops forever, adding a length of
zero to the current pointer, never passing the end of
the directory length. The application process is hung;
it can't be killed or stopped.
IBM closed the problem with a PRS code (Permanent ReStriction)
under AIX Version 3 and had targeted a fix for AIX 4.2. They
have recently (I became aware of it September 10, 1996)
cancelled the defect report altogether and have indicated they
are not going to fix the defect.
4.2 Gcc Work-around for AIX 4.1x
When gcc is used to compile lsof for AIX 4.1x, it doesn't
align one element of the user structure correctly. Xlc
sees the U_irss element as a type "long long" and aligns
it on an 8 byte boundary. That's because the default mode
of xlc is -qlonglong; when -qlonglong is enabled, the
_LONG_LONG symbol is also defined.
Gcc sees U_irss as a two element array of type long, because
_LONG_LONG isn't defined. Hence gcc aligns the U_irss
element array on a 4 byte boundary, rather than an 8 byte
one, making the gcc incantation of the user structure 4
bytes shorter than xlc's.
When the length of gcc's user structure is supplied as
argument 4 to the undocumented getuser() function of the
AIX kernel, getuser() rejects it as an incorrect size and
returns EINVAL.
Lsof has a work-around for this problem. It involves a
special test in the Configure script when the "aixgcc"
Configure abbreviation is used -- e.g.,
$ Configure -n aixgcc
The test is to compile a small program with gcc and check
the alignment of U_irss. If it's not aligned on an 8 byte
boundary, the Configure script makes a special copy of
<sys/user.h> in ./dialects/aix/aix<AIX_version> whose
U_irss will align properly, and generates compile time
options to use it.
While I have tested this work-around only with 4.1.4, it
should work with earlier versions of AIX 4.1. It does not
work for AIX 4.2; a different work-around is employed there.
(See the next section.)
If you want to use this technique to compile other AIX
4.1x programs with gcc for using getuser(), check the
Configure script.
Stuart D. Gathman identified this gcc AIX alignment problem.
4.3 Gcc and AIX 4.2[.1]
Alignment problems with gcc and AIX 4.2[.1] inside the user
structure are more severe, because there are some new 64
bit types in AIX that gcc doesn't yet (as of 2.7.x) support.
The <sys/user.h> U_irss element problem, discussed in 4.3
above, doesn't exist in 4.2[.1].
The AIX lsof machine.h header file has a work-around,
provided by Henry Grebler, that bypasses gcc alignment
problems. Later versions of gcc (e.g., 2.8.x) will probably
bypass the problems as well.
4.4 Why won't lsof's Configure allow the use of gcc for AIX
below 4.1?
Gcc can't reliably be used to compile lsof for AIX versions
below AIX 4.1 because of possible kernel structure element
alignment differences between it and xlc.
4.5 What is an AIX SMT file type?
When you run AIX X clients with the DISPLAY environment
variable set to ``:0.0'' they communicate with the AIX X
server via files whose kernel file structure has an undefined
type (f_type == 0xf) -- at least there's no definition for
it in <sys/file.h>.
These are Shared Memory Transport (SMT) sockets, an artifact
of AIXWindows, designed for more efficient data transfers
between the X server and its clients.
Henry Grebler and David J. Wilson alerted me to the existence
of these files. Mike Feldman and others helped me identify
them as SMT sockets.
The curious reader can find more about SMT sockets in
/usr/lpp/X11/README.SMT.
4.6 Why does AIX lsof start so slowly?
When AIX lsof starts it compares the running kernel's
identity to the one for which it was built, using
/usr/bin/oslevel. That comparison can sometimes take a
long time to complete, depending on the system's maintenance
level and how recently it was examined with oslevel.
AIX revisions 4.67 and above for AIX 5 and above don't use
oslevel to determine the kernel identity. They use uname(2)
instead, and it is much faster.
You can skip the oslevel test by suppressing warning messages
with lsof's -w option. Doing that carries with it the risk
of missing other warning messages, however.
You can also disable the kernel identity check by disabling
the definition of the HASKERNIDCK symbol by editing AIX
machine.h header file or by using the Customize script to
disable it.
See the "Why does lsof warn "compiled for x ... y; this is
z.?" section for more information.
4.7 Why does exec complain it can't find libc.a[shr.o]?
When you try to execute lsof you may get this complaint:
exec(): 0509-036 Cannot load program ./lsof because of
the following errors:
0509-022 Cannot load library libc.a[shr.o].
0509-026 System error: A file or directory in
the path name does not exist.
This is probably the result of making lsof when the LIBPATH
environment variable contained a directory path that doesn't
contain libc.a. You can see what LIBPATH contained when
lsof was made by using the dump application on lsof. For
example, if LIBPATH contained /foo/bar when lsof was made,
you will see this (partial) dump output:
$ dump -H lsof
...
***Import File Strings***
INDEX PATH BASE ...
0 /foo/bar
To correct the problem, revisit the lsof source directory
and remake lsof this way:
$ unset LIBPATH; make (sh or ksh)
or
% unsetenv LIBPATH; make (csh or tcsh)
4.8 What does lsof mean when it says, "no PCB, CANTSENDMORE,
CANTRCVMORE" in a socket file's NAME column?
When an AIX application calls shutdown(2) on an open socket
file, but hasn't called close(2) on the file, the file will
remain visible to lsof as an open socket file without any
extended protocol information.
Lsof reports that state in the NAME column by saying that
there is "no PCB" (Protocol Control Block) for the protocol
(e.g., TCP in the NODE column). If the open socket file
has the state variables SO_CANTSENDMORE and SO_CANTRCVMORE
set -- i.e., from the shutdown(2) call -- lsof reports them
with the CANTSENDMORE and CANTRCVMORE notes in the NAME
column.
4.9 When the -X option is used on AIX 4.3.3, why does lsof disable
it, saying "WARNING: user struct mismatch; -X option disabled?"
The -X option causes lsof to read the loader information
of the user structure from virtual memory via the readx()
system call. It does that with the user structure definition
from <sys/user.h> that was compiled into the lsof executable.
On AIX 4.3.3 there are two different user structure
definitions in two separate <sys/user.h> header files,
distributed at different times by IBM. If lsof was compiled
with one and the kernel on which lsof is being run was
compiled with the other, lsof normally won't get correct
loader information when it calls readx().
In an attempt to compensate for that difference, lsof makes
an independent check of the loader information by getting
the user structure's open file count via readx() and
comparing it to the open file count obtained independently
via getprocs(). When the two counts don't match, lsof
tries to read the count (and re-read the loader information)
with two offsets, based on observed differences between
the two user structures.
When one of the three attempts produces a correct open file
count, lsof uses its corresponding offset on subsequent
readings of the loader information.
When none of the three attempts produces a correct open
file count, lsof issues the WARNING message and disables
-X processing.
To eliminate this problem, obtain an lsof binary that
matches the kernel of the AIX 4.3.3 system where you want
to run lsof. Compiling lsof on the target system is the
preferred way to get a matching binary.
4.10 Why doesn't the -X option work on my AIX 5L or 5.[123] system?
If your AIX 5L or 5.[123] system uses the ia64 architecture,
lsof needs setuid-root permission to be able to do the
processing that -X requires.
Check the output of `uname -a` to determine the architecture
type.
The work-around is to give lsof setuid-root permission.
4.11 Why doesn't /usr/bin/oslevel report the correct AIX version?
The oslevel man page says, "The oslevel command reports
the level of the operating system using a subset of all
filesets installed on your system."
You can see which fileset is below the expected level with
oslevel's -l option. For example, if you believe your
system is at AIX level 4.3.3, but oslevel reports 4.3.2,
use this oslevel command to find the filesets below 4.3.3:
$ /usr/bin/oslevel -l 4.3.3.0
If you don't know what level argument to supply to oslevel's
-l option, use oslevel's -q option first.
4.11.1 Why doesn't /usr/bin/oslevel report the correct AIX version
on AIX 5.1?
The subset list for oslevel on AIX 5.1 seems to include at
least two filesets, xlsmp.msg.en_US.rte and xlsmp.rte, that
do not install from AIX 5.1 media with a 5.1.0.0 level.
Hence, oslevel reports 5.0.0.0 instead of the expected
5.1.0.0.
If either xlsmp.msg.en_US.rte or xlsmp.rte is installed,
lsof's Configure script and run-time tests will identify
the AIX version incorrectly. The run-time test will
issue a complaint message of this form:
lsof: WARNING: compiled for AIX version xxx; this is yyy.
You can correct the Configure test by pre-defining the
oslevel value, setting the correct value in the LSOF_VSTR
environment variable before running the Configure script
-- e.g., to pre-define AIX 5.1 when using ksh, do this:
$ LSOF_VSTR=5.1.0.0 Configure -n aix
You can't affect oslevel output without uninstalling
xlsmp.msg.en_US.rte and xlsmp.rte. If you can't do that,
you'll have to put up with the run-time complaint.
4.12 Why does lsof for AIX 5.1 or above Power architecture
complain about kernel bit size?
When you run an lsof binary on an AIX 5.1 or above Power
system, it might complain:
lsof: FATAL: compiled for a 32 bit kernel.
The bit size of this kernel is 64.
or
exec: 0509-036 Cannot load program ./lsof because of
the following errors:
0509-032 Cannot run a 64-bit program on a 32-bit
machine.
Starting at lsof revision 4.61, lsof binaries for Power
architecture systems running AIX 5.1 or above are closely
tied to the kernel bit size. Lsof must do that so it can
read and understand kernel structures.
Lsof's Configure script tunes the lsof configuration so
that the binary built in the make(1) step is adjusted to
the kernel bit size.
An lsof binary knows the bit size for which it was constructed,
tests the bit size of the kernel under which it is running,
and objects if the two sizes don't match. To see the bit
size for which lsof was constructed, run it with its -v
option and look for these lines in the output:
configuration info: 32 bit kernel
or
configuration info: 64 bit kernel
(Note: these lines will appear only in -v output for AIX
5.1 and above lsof binaries, built for Power architecture.)
You can see the kernel bit size test method in the aix
stanza of the lsof Configure script and in the get_kernel_access()
function of the lsof .../dialects/aix/dproc.c source file.
There is more information on pre-defining the kernel bit
size when building lsof in Configure, 00PORTING, and
00XCONFIG.
The only work-around is to use an lsof binary built to
match the running kernel bit size.
4.13 What can't gcc be used to compile lsof on the ia64 architecture
for AIX 5 and above?
Gcc can't be used to compile lsof on the ia64 architecture
for AIX 5 and above because I haven't had access to a system
that has a working gcc compiler. The gcc compiler on my
one and only ia64 AIX 5.1 test system, provided by IBM,
didn't work at all.
4.14 Why does lsof get a segmentation fault when compiled with gcc
for a 64 bit Power architecture AIX 5.1 kernel?
When lsof is configured with the lsof "aixgcc" Configure
abbreviation, the resulting lsof executable may cause a
segmentation violation when it is run. I've observed this
with gcc version 2.9-aix43-010414-7.
As far as I have been able to tell, the segmentation fault
is the result of a gcc compilation, loading, or library
error. Watching lsof run with gcc's companion debugger,
gdb, shows no error in the lsof source code that might
explain the fault.
The only work-around I know is to use the IBM C compiler
in place of gcc -- i.e., use the "aix" lsof Configure
abbreviation.
4.15 Why does lsof ignore AFS on my AIX system?
The lsof Configure script quits on AIX when AFS is present,
the AIX version is greater than 4.3.3.0 or the AFS version
is greater than 3.5. That's because I have no test systems
available for those AIX and AFS version combinations.
When the lsof Configure script detects an AIX and AFS
version combination that is unsupported, it will report:
!!!FATAL: Lsof does not support AFS on this combination of
AIX and AFS versions. To disable AFS, set the
value of the AIX_HAS_AFS environment variable to
"no".
The only work-around is to set the AIX_HAS_AFS environment
variable as explained in the error message:
$ AIX_HAS_NSF=no; export AIX_HAS_NFS
$ ./Configure -n aix
4.16 Why does lsof report "system paging space is low" and exit?
When AIX paging space runs low, the AIX kernel sends a SIGDANGER
signal to processes, warning them that they should reduce their
memory usage.
When lsof receives that signal, it issues the following fatal
error message and exits:
lsof: FATAL: system paging space is low.
A possible work-around is to limit the amount of information
lsof must cache in its process memory with the "-c", "-g", "-l"
and "-p" options.
Also see the answer to the "What can be done when lsof reports
no more space?" question.
4.17 Why does lsof have a compilation problem on AIX 5.3 above
maintenance level 1?
On some AIX 5.3 systems with maintenance levels 2 and higher
installed, lsof 4.77 and below may not compile properly. The
compiler complains the snapshotObject structure definition,
needed by <j2/j2_inode.h>, is missing.
That problem is fixed in the 4.78 revision.
5.0 Apple Darwin Problems
5.1 What do /dev/kmem-based and libproc-based mean?
Lsof for Apple Darwin currently uses /dev/kmem to read kernel
data structures from which it gathers and reports open file
information. That version of lsof is called /dev/kmem-based
lsof.
At an upcoming release lsof will use a library called libproc
to obtain information about open files. That version of lsof
wil be called libproc-based lsof.
The /dev/kmem-based lsof sources may be found in the kmem
subdirectory of the dialects/darwin branch of the lsof source
tree. When the supporting version of Apple Darwin is released,
the libproc-based lsof sources will be found in
.../dialects/darwin/libproc.
5.2 /dev/kmem-based Apple Darwin Questions
5.2.1 Why does Configure ask for a path to the Darwin XNU kernel
header files?
When lsof was ported to Apple Darwin by Allan Nathanson at
revision 4.53, some kernel header files needed by lsof
weren't being exported by the developers. (That's still
true at lsof revision 4.76.)
At first a shell script that Allan provided would get the
missing header files by checking them out from the CVS
root. Although the script was updated from time to time,
eventually the re-organization of Darwin sources has made
it impossible to update the script to do an automatic
download of the missing header files.
At lsof revision 4.69 and above it is necessary for the Darwin
lsof builder to download the Darwin XNU kernel headers before
attempting to build lsof. The download my be done via a web
browser, starting at this URL:
http://www.opensource.apple.com/darwinsource/index.html
Once there, select the link to the Mac OS X version that
matches the one on the system where lsof is to be built.
Follow that link's "[ Source ]" link. Once there, select the
tar.gz link of the xnu* entry near the bottom of the page.
That entry should have a name that matches the xnu* name shown
by `uname -a` -- e.g., if uname reports:
$ uname -a
... root:xnu/xnu-517.7.21 ...
Then the appropriate xnu* entry is xnu-517.7.21. Clicking
its link should lead to an "Apple Open Source" page requesting
an Apple ID and password.
Enter them if they're available. If an Apple ID and password
are not available, get them by following the instructions on
the page -- i.e., follow the signin.apple.com link.
Once a valid Apple ID and its password have been entered,
the download will begin. Select the saving of the downloaded
xnu*.tar.gz file in an appropriate place on the Mac OS X
system.
Once the download completes, install it. Use gunzip to
decompress the download and tar to extract the archive -- e.g.,
$ gunzip -c xnu-517.7.21.tar.gz | tar xf -
Remember the absolute path to the extracted archive. That is
its installed place. E.g., if the xnu-517.7.21.tar archive was
extracted to the lsof builder's home directory, its full
installation path will be something like:
~/xnu-517.7.21
Now run the lsof Configure script. When it asks for the path
to the installed Darwin XNU kernel header files, supply the
path to the gunzip'd and extracted xnu* archive -- e.g.,
~/xnu-517.7.21.
The path to the Darwin XNU kernel headers may also be
supplied to the Configure script in the DARWIN_XNUDIR
environment variable, eliminating the need to enter it
interactively -- e.g.,
$ DARWIN_XNUDIR=~/xnu-344.49 ./Configure -n darwin
5.2.1.1 Why does Configure complain that Darwin XNU kernel header
files are missing?
These are some reasons why the lsof Configure script might
claim that Darwin XNU header files are missing:
* The wrong path to them was specified.
* The files and directories in the path are not readable
and searchable -- i.e., check the modes and ownerships.
* The downloaded archive doesn't match the Mac OS X
version of the system.
If in doubt, revisit the Darwin XNU kernel header file
download instructions in the answer to the question "Why
does Configure ask for a path to the Darwin XNU kernel
header files?"
If Configure still can't find Darwin XNU kernel header
files, contact me via e-mail at <abe@purdue.edu> for help.
Make sure "lsof" appears in the "Subject:" line so my e-mail
filter won't classify your letter as Spam.
5.2.2 Why doesn't Apple Darwin lsof report text file information?
At the first port of lsof to Apple Darwin, revision 4.53,
insufficient information was available -- logic and header
files -- to permit the installation of VM space scanning
for text files. As of lsof 4.70 it is sill not available.
Text file support will be added to Apple Darwin lsof after
the necessary information becomes available.
5.2.3 Why doesn't Apple Darwin lsof support IPv6?
At the first port of lsof to Apple Darwin, revision 4.53,
Apple Darwin lacked IPv6 support. IPv6 became available
in Apple Darwin version 1.5 and support for it was added
to lsof then.
5.2.4 Why does lsof complain about a mismatch between the release
for which lsof was compiled and the booted Mac OS X release?
When lsof is started on the "Gold Master" Darwin release
(aka Mac OS X), it complains:
lsof: compiled for 1.0 release; this is 1.3.2.
This happens because the lsof binary released with Mac OS
X was built on a system whose release number (1.0) doesn't
match that of the released system -- usually 1.3.x Lsof
makes this check because UNIX dialect OS changes are often
accompanied by header file changes that affect lsof.
In this specific case, this error can be ignored. If you
don't want to do that, get the lsof distribution and build
lsof so its built-on and running-on Mac OS X release numbers
match.
5.2.5 Why does lsof for Apple Darwin 8 and higher report
"stat(...): ..." in the NAME column?
Lsof for Apple Darwin 8 may report messages like these in the
NAME column:
stat(/private/var/run/asl_prune): No such file or directory
or
stat(/private/var/db/netinfo/local.nidb/Config): Permission denied
Those messages indicate that lsof was unable to collect open
file information for the paths enclosed in "stat(...)" with the
stat(2) function, because the function encountered the reported
error.
A work-around for the "Permission denied" error is to run lsof
with elevated privileges -- e.g., when logged on as the super
user.
If the stat(2) error message is "No such file or directory",
the file probably has been unlinked (removed) and there is no
lsof work-around.
5.2.6 What are the limitations of Apple Darwin lsof link count
reporting?
Lsof for Apple Darwin cannot report link count information
reliably.
For Apple Darwin below 8 link count information is not always
available in the kernel node structures available to lsof.
When link count information is available, however, it includes
link counts of zero. Thus, using lsof's +L1 option may result
in the finding of some files whose link counts are zero.
Lsof can report only some link count information for Apple
Darwin 8 and above. Link count information is only available
for files where lsof can assemble the full file path and has
permission to apply stat(2) to it. (See the answer to the "Why
does lsof for Apple Darwin 8 and higher report "stat(...): ..."
in the NAME column?" question for more information on stat(2)
failures.)
Apple Darwin 8 and above files that have been unlinked and thus
have a link count of zero cannot be found by stat(2) -- i.e.,
stat(2) returns a "No such file or directory" error. As a
result lsof never displays link counts of zero and the use of
lsof's +L1 option to find them always fails.
5.2.7 Why does Apple Darwin report process group IDs incorrectly?"
The kmem version of lsof for Apple Darwin does not report
process group IDs correctly when requested to do so with its
``-g'' option. This is a bug that surfaced after the libproc
version was released and access to kmem test systems has
prevented patching the bug.
If you are using the kmem version and would like a fix for this
problem, please send e-mail to me <abe@purdue.edu>. Make sure
"lsof" appears in the "Subject:" line so my e-mail filter won't
classify your letter as Spam.
5.3 Libproc-based Apple Darwin Questions
6.0 BSD/OS BSDI Problems
6.0.5 Statement of deprecation
As of lsof revision 4.76 support for BSDI BSD/OS has been
dropped. The 4.76 distribution of lsof for BSDI BSD/OS may be
found on lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
7.0 DEC OSF/1, Digital UNIX, and Tru64 UNIX Problems
7.1 Why does lsof complain about non-existent /dev/fd entries?
When you run lsof for Digital UNIX 3.2, lsof may complain:
lsof: can't lstat /dev/fd/xxx: No such file or directory
lsof: can't lstat /dev/fd/yyy: No such file or directory
(Or it may warn about other missing /dev/fd paths.) When
you do an ``ls /dev/fd'' none of the missing paths are listed.
This is caused by a bug in the DEC library function
getdirentries(). For some reason, when /dev/fd is a file
system mount point, getdirentries() returns an incorrect
size for it to readdir(). (Lsof calls readdir() in its
ddev.c readdev() function.) Because of the incorrect size,
readdir() goes past the end of the /dev/fd directory buffer,
encounters random paths and returns them to lsof. Lsof
then attempts to lstat(2) the random paths, gets error
replies from lstat(2), and complains about the paths.
Duncan McEwan discovered this error and has reported it to
DEC. Duncan also supplied an alternate readdir() function
as a work-around. I've incorporated his readdir() in
dialects/osf/ddev.c (as the static ReadDir() function) with
some slight modifications, and enabled its use when the
USELOCALREADDIR symbol is defined.
The Configure script defines USELOCALREADDIR for Digital
UNIX version and 3.2. If you don't want to use Duncan's
local readdir() function, edit the Makefile and remove
-DUSELOCALREADDIR from the CFGF string. When DEC releases
a corrected getdirentries() function, I'll modify the
Configure script to stop defining USELOCALREADDIR.
7.2 Why does the Digital UNIX V3.2 ld complain about Ots* symbols?
When you compile lsof on your Digital UNIX V3.2 system, ld
may complain:
ld:
Unresolved:
knlist
_OtsRemainder32Unsigned
_OtsDivide64Unsigned
_OtsRemainder64Unsigned
_OtsDivide32Unsigned
_OtsMove
_OtsDivide32
_OtsRemainder32
*** Exit 1
Chris Eleveld reports this happens on Digital UNIX V3.2
systems after the Fortran compiler has been installed.
The best work-around seems to be to remove -lmld from the
CFGL string in the Makefile produced by Configure -- i.e.,
change:
CFGL= -lmld
to
CFGL=
According to the V3.2 man page for nlist(3), this shouldn't
work, but my testing shows that it does. Although I haven't
been able to test this second work-around, you might try
adding -lots to CFGL, rather than removing -lmld -- i.e.,
change:
CFGL= -lmld
to
CFGL= -lmld -lots
WARNING: my testing also shows that the V2.0 nlist(3) man
page means what it says when it calls for -lmld -- lsof
loaded without -mld under V2.0 can't locate the proc
(process) table address.
DON'T REMOVE -lmld FROM THE DIGITAL UNIX V2.0 MAKEFILE.
If you run into this problem, please let me know what
problem you encountered and how you solved it.
7.3 Why can't lsof locate named pipes (FIFOs) under V3.2?
While lsof for V3.2 can report on named pipes (FIFOs), it
can't find them by name. That appears to happen because
of the way the V3.2 kernel lstat(2) function reports named
pipe device numbers.
The V3.2 kernel reports the device number as 0xfffffff,
while the kernel structures for named pipes that lsof
examines contain the device number of the file system on
which the named pipe resides.
Consequently, lsof can't match the device and inode number
pair it receives from applying lstat(2) to the named pipe
with any device and inode number pair it finds when scanning
kernel structures.
I don't have a work-around. You can, of course, ask for
full lsof output and use a post-processing filer (e.g.,
grep) to locate the named pipe of interest.
This problem doesn't exist under V2.0.
7.4 Why does lsof use the wrong configuration header files?
For example, why can't the lsof compilation find cpus.h?
DEC OSF/1, Digital UNIX, and Tru64 UNIX configuration header
files describe the hardware and software environment for
which your kernel boot file was constructed. For example,
/sys/<name>/cpus.h defines the number of CPUs in its NCPUS
#define.
Lsof searches for the configuration header file subdirectory
in /sys (/usr/sys for Digital UNIX version 4.0 and Tru64
UNIX) by converting the first host name component to capital
letters -- e.g., TOMIS is derived from tomis.bio.purdue.edu.
If that subdirectory exists, lsof uses header files from
it. (Configure reports what subdirectory is being used.)
If Configure doesn't find a host-name derived subdirectory,
it prompts you for the entry of a subdirectory name. If
you can't find one, quit Configure and run the kernel
generation process to create a proper configuration sub-
directory. If you don't identify a proper configuration
subdirectory and you try to compile lsof, the compiler will
complain about missing header files -- e.g., a missing
cpus.h.
Once you have located or generated a proper configuration
subdirectory, rerun Configure. If you have generated a
configuration subdirectory whose name is derived from the
host name, Configure will find and use it. If not, you
will have to specify its name to Configure.
7.5 Why does lsof indicate incomplete paths with " -- " for Tru64
UNIX 5.1 files?
When lsof can't find a component of a path in the kernel's
name cache (aka DNLC), or can't determine that the left-most
component has as its parent the file system root, it uses
an "incomplete path" notation. That notation begins with
the file system root name, followed by " -- ", followed by
the consecutive path name components lsof was able to find
in the DNLC -- e.g., "/ -- init".
Because the DNLC was significantly redesigned in Tru64 UNIX
5.1, lsof's handling of the cache had to be completely
redone. As part of the DNLC redesign a name cache entry
parameter lsof formerly used to locate the file system root
of a path was removed. With help from Chang Song I've been
able to implement an alternate method for detecting the
root of these file system types: AdvFS (MSFS), CDFS, DVDFS,
FDFS, NFS, NFS3, and UFS.
When lsof doesn't know how to identify the root for a file
system type, it will resort to the " -- " incomplete path
notation.
7.6 Why doesn't lsof report link count, node number, and size
for some Tru64 5.x CFS files?
Lsof reports link count, node number, and size for open
CFS files as recorded in their kernel node structure's
cached attributes. Sometimes not all attributes are cached
on the system where lsof runs, so lsof cannot report them.
7.7 Why does lsof say it can't read the kernel name list or
proc table on Digital UNIX 4.x or Tru64 UNIX?
By default on Digital UNIX 4 and Tru64 UNIX lsof reads the
addresses for kernel symbols with the knlist(3) function.
That function can fail, for example, when the kloadsrv
daemon isn't running or is malfunctioning. When that
happens, lsof may abort with one of these error messages:
lsof: can't read kernel name list from knlist(3): ...
or
lsof: can't read proc table info
The first message suggests a complete knlist(3) or kloadsrv
failure; the second, a partial one.
If you know the name of the file from which the running
system was booted, e.g., /vmunix, you can use lsof's -k
option to direct it to read kernel symbol addresses from
the name list of that file --
$ lsof -k /vmunix ...
If that works, then knlist(3) is malfunctioning and you
need to fix it.
8.0 FreeBSD Problems
8.1 Why doesn't lsof report on open kernfs files?
Lsof doesn't report on open FreeBSD kernfs files because
the structures lsof needs aren't defined in the kernfs.h
header file in /sys/misc/kernfs.
8.2 Why doesn't lsof work on my FreeBSD system?
If lsof doesn't work on your FreeBSD system, first make
sure you have the latest lsof revision. See the answer to
the "Where do I get lsof?" question for information on how
to get the latest lsof revision.
Once you have gotten the latest lsof revision, Configure
and make it. If Configure fails -- e.g., it complains
about an unknown FreeBSD version -- then lsof probably
hasn't been ported to your FreeBSD version yet, and there's
no need to go any further. Follow the answer to the "How
do I report an lsof bug" to report the Configure complaint
to me.
If you are able to Configure and make lsof, run its test
suite. (See the answer to the "Is there a test suite?"
question for more information on how to use lsof's test
suite.)
If lsof still fails, make sure your kernel sources, kernel
header files, kernel boot file, standard header files and
libraries are synchronized. They should all be built from the
same CVS refresh. (Don't forget to do a "make buildworld"
followed by a "make installworld".) If they aren't, then the
KVM library or lsof may be using kernel structure definitions
that don't match the booted kernel; or lsof may fail to compile
properly because of header files in /usr/src/sys/sys and
/usr/include/sys that don't match.
If you have synchronized your kernel, header files and
libraries, and still can't get lsof to work, follow the
steps in the answer to the "How do I report an lsof bug"
question to report the problem to me.
8.3 Why doesn't lsof work on the RELEASE version of CURRENT?
Lsof tracks the CURRENT release of the current leading edge
FreeBSD version, because my access to leading edge FreeBSD is
limited to FreeBDSD.org reference systems, all running the
CURRENT release.
Sometimes that tracking leads to changes in lsof that won't
work on an earlier RELEASE version of the current leading edge
version.
When that happens, please send e-mail to me <abe@purdue.edu>.
Make sure "lsof" appears in the "Subject:" line so my e-mail
filter won't classify your letter as Spam.
8.4 Why does kvm_open() complain it can't find some file?
If lsof issues this complaint:
lsof: kvm_open(execfile=/boot/kernel/kernel,
corefile=/dev/mem: No such file or directory
Your FreeBSD system might not have a /dev/mem device. If
not, create one -- e.g., as root do:
# mknod /dev/mem c <major> 0
# chmod 440 /dev/mem
# chgrp kmem /dev/mem
For <major> use /dev/kmem's major device number.
You may have to run kldload, too -- again as root do:
# kldload mem
8.5 FreeBSD ZFS Problems
8.5.1 Why does FreeBSD lsof report "WARNING: no ZFS support has been
defined."?
Lsof issues that message when it detects a file on a ZFS file
system, but has not been built with support for ZFS. Lsof's
Configure script detects support can be added for ZFS when it
finds this file:
/usr/src/sys/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h
That header file and others in the OpenSolaris files in
/usr/src enable lsof to extract information about ZFS files
from the kernel structures associated with them.
8.6 Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
Lsof may report:
Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
or
Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
Those messages mean that lsof's Configure script failed to
create a local header file, ./lockf_owner.h, needed to use the
new kernel file locking code of some versions of FreeBSD 6 and
above.
The changes that implement that new locking code alter the
lockf structure in <sys/lockf.h> and introduce a new structure,
lockf_entry, to that header file. When Configure detects the
presence of the lockf_entry definition in <sys/lockf.h>, it
tries to construct the local header file, ./lockf_owner.h.
Configure has to do that because an unfortunate side effect of
the new kernel file locking code is that <sys/lockf.h> doesn't
contain the lockf_owner structure definition referenced in its
own lockf structure. 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 missing lockf_owner structure definition is in the kernel
source file, typically /usr/src/sys/kern/kern_lockf.c.
Configure tries to extract the lockf_owner structure definition
from kern_lockf.c into lsof's local header file, ./lockf_owner.h.
If Configure can't do that, it reports:
FATAL ERROR: ./lockf_owner.h creation failed
If Configure can't even read kern_lockf.c, it first reports:
FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
The work-around for this problem is to update the FreeBSD
kernel /usr/src tree (e.g., do a CVSup or csup) on the system
where lsof is to be built and then do a "make buildworld"
followed by a "make installworld".
8.6.1 Why are there lockf structure compiler errors for FreeBSD 6.0
and higher lsof?
If, when compiling lsof, the compiler complains with error
messages like:
dnode.c: In function 'get_lock_state':
dnode.c:113: error: 'struct lockf' has no member named 'lf_flags'
dnode.c:115: error: 'struct lockf' has no member named 'lf_id'
...
Then lsof is being built on a system that has new kernel file
locking code and lsof's Configure script failed to build a
local lockf_owner.h header file with a structure definition
lsof needs.
See the "Why can't Configure create lsof_owner.h for FreeBSD 6
and above?" section for more information and a work-around.
8.6.2 Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h
match?
This mismatch can cause the errors explained in the answer to
the "Why are there lockf structure compiler errors for FreeBSD
6.0 and higher lsof?" question.
If /usr/src/sys/sys/lockf.h has been updated with a CVSup or
csup, the new lockf.h won't be propagated to /usr/include/sys
until the "make buildworld" and "make installworld" steps have
been completed.
8.7 FreeBSD and clang
As of lsof revision 4.87, lsof may be compiled with clang.
8.7.1 Why does clang complain about VOP_FSYNC?
There is an error in the Solaris ZFS compatibility vnode.h
header file with use of VOP_FSYNC before it is defined. No
work-around is possible that will eliminate the clang
compile-time warning message about the invalid declaration of
the VOP_FSYNC function.
9.0 HP-UX Problems
9.1 What do /dev/kmem-based and PSTAT-based mean?
Lsof for HP-UX 11.0 and below uses /dev/kmem to read kernel
data structures from which it gathers and reports open file
information. That version of lsof is called /dev/kmem-based
lsof.
Starting with HP-UX 10.10, finding definitions for the
necessary kernel structures became more difficult as HP no
longer distributed header files in /usr/include that defined
all kernel structures. So I started "inventing" structure
definitions by using Q4 to display them.
By HP-UX 11, the process of invention became extremely
intensive to support. Following a patch to the ipc_s
structure in early 1999, my invented definition of that
structure became incorrect. Although I was able to devise
a work-around test for the patch with Q4, it was clear that
my inventions were bound to cause more problems.
Discussion with HP about the patch led to my proposing that
an lsof API in the HP-UX kernel was the proper solution.
Much to my surprise, HP agreed. I believe Carl Davidson
was the prime mover behind that decision, but I know others
participated, among them Louis Huemiller, Rich Rauenzahn,
and Sailu Yallapragada. I am indebted to these folks and
HP for their willingness to do this work.
The API was added to the PSTAT interface in a project named
PEGL, Pstat Enhancements for Glance and Lsof. Louis and
Sailu did the bulk of the design and implementation work
and testing began in March, 2000
HP-UX 11.11 is the first version that provides PSTAT support
for lsof. HP-UX versions in between 11.0 and 11.11 -- all
Beta versions as far as I can determine -- have no lsof
support.
See the "PSTAT-based HP-UX lsof Questions" section for
questions and answers specific to PSTAT-based HP-UX lsof.
The next section, "Why doesn't a /dev/kmem-based HP-UX lsof
compilation use -O?" covers /dev/kmem-based HP-UX lsof.
The /dev/kmem-based lsof sources may be found in the kmem
subdirectory of the dialects/hpux branch of the lsof source
tree. The PSTAT-based lsof sources may be found in
.../dialects/hpux/pstat.
9.2 /dev/kmem-based HP-UX lsof Questions
The sources for /dev/kmem-based lsof for HP-UX may be found
in lsof_<revision>/dialects/hpux/kmem.
Lsof's Configure shell script decides to use these sources
when it finds that the /usr/include/sys/pstat subdirectory
doesn't exist.
Lsof can be forced to use the /dev/kmem sources by setting
"/dev/kmem" in the HPUX_BASE environment variable. Consult
the Configure shell script and 00XPORTING for more information.
9.2.1 Why doesn't a /dev/kmem-based HP-UX lsof compilation use -O?
If you only have the standard (bundled) HP-UX C compiler
and haven't purchased and installed the optional one, then
you can't use cc's -O option. The HP-UX cc(1) man page
says this:
"Options
Note that in the following list, the cc and c89 options
-A , -G , -g , -O , -p , -v , -y , +z , and +Z are
not supported by the C compiler provided as part of
the standard HP-UX operating system. They are supported
by the C compiler sold as an optional separate product."
Lsof's Configure script tries to detect what C compiler
product you have installed by examining your compiler. If
that examination reveals a standard (bundled) compiler,
lsof avoids using -O.
If the Configure compiler test fails, the C compiler will
complain that it doesn't support -O. You can suppress that
complaint with this make invocation:
$ make DEBUG=""
9.2.2 Why doesn't the /dev/kmem-based CCITT support work under 10.x?
Pasi Kaara, who originally provided the HP-UX CCITT support,
reports that it no longer works under HP-UX 10.x.
Consequently, at lsof revision 4.02 it has been disabled.
9.2.3 Why can't /dev/kmem-based lsof be compiled with `cc -Aa` or
`gcc -ansi` under HP-UX 10.x?
Some HP-UX 10.x header files, needed by lsof, can't be
compiled properly in ANSI_C mode; structure element definition
and alignment problems result. The f_offset member of the
file structure, for example, is incorrect.
This ANSI-C obstacle extends to using the -Aa option of
the HP C compiler and the -ansi option of gcc.
9.2.4 Why does /dev/kmem-based lsof complain about no C compiler?
Lsof's Configure script looks in /bin and /usr/ccs/bin for
an HP C compiler, because it needs to know if the compiler
is the standard (bundled) one or the optional separate
product. If it finds no compiler in either place, Configure
quits after complaining:
No executable cc in /bin or /usr/ccs/bin
If you don't have a C compiler in either of these standard
places, you should consider installing it. If you have
gcc installed, you can use it by declaring the ``hpuxgcc''
abbreviation to lsof's Configure script.
If you have a C compiler in a non-standard location, you
can use the HPUX_CCDIR[12] environment variables to name
the path to it. Consult the 00XCONFIG file of the lsof
distribution for more information.
9.2.5 Why does Configure complain about q4 for /dev/kmem-based lsof
for HP-UX 11?
When you run Configure on an HP-UX 11 system, it may complain:
!!!ERROR!!! !!!ERROR!!! !!!ERROR!!! !!!ERROR!!!
Configure can't use /usr/contrib/bin/q4 to examine the ipis_s
structure. You must do that yourself, report the result in
the HPUX_IPC_S_PATCH environment variable, then repeat the
Configure step. Consult the Configure script's use of
/usr/contrib/bin/q4 and the 00XCONFIG file for information
on ipis_s testing and the setting of HPUX_IPC_S_PATCH.
!!!ERROR!!! !!!ERROR!!! !!!ERROR!!! !!!ERROR!!!
This message states that Configure cannot use q4 from
/usr/contrib/bin to examine the kernel's boot image for
the ipis_s structure. Maybe q4 hasn't been installed, or
perhaps Configure can't execute it.
Lsof needs to gather information about ipis_s to determine
if the ipis_s structure is defined in the kernel boot image,
if the ipis_s structure of the kernel boot image has an
ipis_msgsqueued member, and if the ipc_s structure of the
kernel boot image uses has an ipc_ipis member.
The ipis_s structure isn't described in any header file
HP-UX releases with HP-UX 11. It appears in the private
lsof header file .../dialects/hpux/kmem/hpux11/ipc_s.h.
Lsof gets local and remote connection addresses (IP and
port numbers) from ipc_s, so an incorrect ipc_s definition
may cause incorrect reporting of TCP/IP connection addresses.
It definitely will cause incorrect reporting on 32 bit
kernels. In any case lsof should be compiled with a correct
ipc_s definition no matter the kernel bit size, so the
Configure script always tests for it when the HP-UX version
is 11.
For lsof's Configure script to gather the necessary ipis_s
information q4 needs to be installed in /usr/contrib/bin
and the kernel boot image, /stand/vmunix, needs to have
been processed with pxdb. If either is untrue, lsof issues
the above error message, perhaps preceded by q4 messages.
(Note: lsof's use of q4 may also fail if q4 can't execute
nm -- e.g., it can't find /usr/bin/nm, or there is a
conflicting, private version of nm earlier in the path.)
If /stand/vmunix hasn't been processed by pxdb, the q4
messages will include:
q4: (error) vmunix not pxdb'd
or
q4: (warning) /stand/vmunix has not been processed by pxdb.
It's possible to make a suitable private copy of /stand/vmunix
for configuring lsof. That requires /opt/langtools/bin/pxdb
or the q4 version of pxdb from /usr/contrib/bin/q4pxdb.
The path to the result is supplied to the lsof Configure
script in the HPUX_BOOTFILE environment variable. Configure
still requires /usr/contrib/bin/q4.
The following sample Bourne shell commands make a private
copy of /stand/vmunix in /tmp, process it with pxdb or
q4pxdb, and supply its path to lsof's Configure script in
HPUX_BOOTFILE.
$ cp /stand/vmunix /tmp/vmunix.lsof
$ /opt/langtools/bin/pxdb /tmp/vmunix.lsof
or
$ /usr/contrib/bin/q4pxdb /tmp/vmunix.lsof
... pxdb messages ...
$ HPUX_BOOTFILE=/tmp/vmunix.lsof Configure -n hpux
It may also be necessary to use q4 outside the lsof Configure
script. In that case q4 can be to determine the state of
ipis_s and ipc_s with these q4 commands:
$ /usr/contrib/bin/q4 /stand/vmunix
...
q4> fields -c struct ipc_s
...
q4> fields -c struct ipis_s
Look in the q4 output for the ipc_ipis member of the ipc_s
structure, and look in the q4 output for the ipis_s structure
for the ipis_msgsqueued member. If ipc_s has ipc_ipis but
ipis_s lacks ipis_msgsqueued, set HPUX_IPC_S_PATCH environment
variable to "1". If ipc_s has ipc_ipis and ipis_s has
ipis_msgsqueued, set HPUX_IPC_S_PATCH to "2" -- e.g.,
$ HPUX_IPC_S_PATCH=1 Configure -n hpux
or
$ HPUX_IPC_S_PATCH=2 Configure -n hpux
If ipc_s has no ipc_ipis member, set HPUX_IPC_S_PATCH to
"N" -- e.g., use this Configure step:
$ HPUX_IPC_S_PATCH=N Configure -n hpux
9.2.6 When compiling /dev/kmem-based lsof for HP-UX 11 what do the
"aCC runtime: ERROR..." messages mean?
When the lsof Makefile asks the HP-UX unbundled compiler
to load lsof, it may complain:
/bin/cc -o lsof -DHPUXV=1100 -DHASVXFS -DHPUXKERNBITS=64 \
-I/home/abe/src/lsof4/dialects/hpux/kmem/hpux11 +DD64 \
-DHAS_IPC_S_PATCH=2 -I/home/abe/src/lsof4/dialects/hpux/kmem \
-DLSOF_VSTR=\"B.11.00\" -g dfile.o 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 usage.o -L./lib -llsof -lelf \
-lnsl
aCC runtime: ERROR: Unexpected use of shared libraries
aCC runtime: ERROR: Read aCC manpage, +A option
/usr/lib/nls/loc/locales.1//is_IS.iso88591
This is a bug in the HP-UX national language support.
(Notice the last message with "locales" in it?) Complain
to HP -- then use this work-around before executing make:
$ unset LANG
$ make
9.2.7 Why doesn't /dev/kmem-based lsof for HP-UX 11 report VxFS file
link counts, node numbers, and sizes correctly?
This is usually the result of running an lsof binary whose
revision number is less than 4.57 on a system that has
OnlineJFS support installed. It can also happen with lsof
4.57 binaries when the OnlineJFS support with which they
were built doesn't match the OnlineJFS status of the system
on which they are run.
The OnlineJFS status of lsof 4.57 and higher binaries can
be determined by running:
$ lsof -v 2>&1 | grep HASONLINEJFS
If that shell pipe produces output, lsof was compiled with
OnlineJFS support enabled; no output, disabled.
If OnlineJFS is installed on an HP-UX 11 system the
/sbin/fs/vxfs/subtype executable exists and outputs "vxfs3.3"
when run.
The problem occurs because the optional OnlineJFS support
installation doesn't update <sys/fs/vx_inode.h>. Consequently
lsof can be compiled with an incorrect definition of the
vx_inode structure and look for for link counts, node
numbers, and sizes in the wrong places in the structure.
The current response I have gotten from HP is that no
<sys/fs/vx_inode.h> update will be provided for OnlineJFS.
I've addressed this problem temporarily with a work-around
(hack) in lsof revision 4.57.
9.2.8 Why can't /dev/kmem-based lsof be built with gcc for 64 bit
HP-UX 11?
When Configure is given the "hpuxgcc" abbreviation, the
HP-UX version is 11, and the kernel bit size is 64, the
lsof Configure script may abort with the messages:
!!!!!!!!!!!!!!!!! FATAL ERROR !!!!!!!!!!!!!!!!!!
APPARENTLY GCC CANNOT BUILD 64 BIT EXECUTABLES.
A COMPILER MUST BE USED THAT CAN. SEE 00FAQ
FOR MORE INFORMATION.
(This is the "more information" in 00FAQ.)
This means the Configure script compiled a test program
with gcc the result wasn't an ELF-64 binary. Lsof tries
two gcc modes, one with no options and another with the
-mlp64 option, before it concludes gcc can't be used.
See the "How can I acquire a gcc for building lsof for 64
bit HP-UX 11?" answer for information on where you might
be able to get a gcc for HP-UX 11 that can produce ELF-64
executables.
9.2.8.1 How can I acquire a gcc for building lsof for 64 bit HP-UX 11?
Check this HP URL:
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html
(That's one very long link; be careful you cut 'n paste it
all.)
In November 2001 that URL led to a web page whose title
was "gcc for hp-ux 11." The page offered a link for
downloading a 64 bit gcc 3.0 compiler for HP-UX 11.0 and
11i. Rich Rauenzahn of HP installed that compiler on an
HP test system he allows me to use and I successfully built
a 64 bit lsof with it.
The HP package may install the 64 bit capable gcc in
/usr/local/pa20_64/bin/gcc, so you may have to adjust your
path or set the LSOF_CC environment variable to compensate.
9.2.9 Why does /dev/kmem-based lsof for HP-UX 11 report "unknown file
system type" for some open files?
The lsof binary being used probably doesn't have support for
the VxFS file system.
To confirm that, check `lsof -v` output for "-DHASVXFS". If
it's not present, lsof doesn't have VxFS support.
You also need to establish that lsof really is complaining
about VxFS files by checking the kernel boot file for the
symbol associated with the hexadecimal address reported in the
"unknown file system type" message -- e.g., "v_op: 0x8711c8."
Use nm(1) to do that:
$ nm -x /stand/vmunix | grep 8711c8
If nm reports the symbol associated with the address is
vx_vnodeops, then lsof is complaining about an open VxFS file.
The solution in that case is to build lsof yourself (The
bundled C compiler will do it.), making sure that lsof's
Configure script detects the presence of VxFS. Configure does
that by finding these two header files:
/usr/include/sys/fs/vx_hpux.h
/usr/include/sys/fs/vx_inode.h
If the system where you are building lsof doesn't have those
header files, but does have VxFS, you might be able to install
the header files by installing the HP JournalFS package from
the CoreOS CD -- in particular the file set JournalFS.VXFS-PRG
and its associated patch, PHKL_18543. (My thanks to Steve
Bonds for that information.)
Finally, if you find that lsof isn't complaining about VxFS
when it complains about an unknown file system type, send
e-mail to me <abe@purdue.edu> for further assistance. Make
sure "lsof" appears in the "Subject:" line so my e-mail filter
won't classify your letter as Spam.
9.2.10 Why does the ANSI-C compiler complain about comments in HP-UX
11 header files?
When compiling lsof on HP-UX 11, the HP ANSI-C compiler's
pre-processor, cpp, may complain about comments in HP-UX header
files -- e.g.,
cpp: "/usr/include/sys/cdfs.h", line 232: warning 2028:
Found comment inside comment started on line 232.
cpp: "/usr/include/sys/cdnode.h", line 196: warning 2028:
Found comment inside comment started on line 196.
cpp: "/usr/include/nfs/snode.h", line 30: warning 2028:
Found comment inside comment started on line 30
This is not a problem with lsof. It is a problem with the
HP-UX header files; they have non-compliant ANSI-C comment
sequences in them -- e.g.,
<sys/cdfs.h>: 232
/* struct cdfs *cdfs_link; /* linked list of file systems */
The initial "/*" is not terminated by an ending "*/" before the
appearance of a second "/*".
9.2.11 Why does dnode1.c cause the HP-UX 11 compiler to complain that
<sys/fs/vx_inode.h> is missing or incorrect?
If CFLAGS in the lsof Makefile for an HP-UX 11 compilation
includes HASONLINEJFS, indicating the system has OnlineJFS
support, lsof needs the <sys/fs/vx_inode.h> header file.
Sometimes it is missing from /usr/include/sys/fs.
<sys/fs/vx_inode.h> is a header file that must be obtained from
Veritas. If that proves impossible, please contact me via
e-mail at <abe@purdue.edu>. Make sure "lsof" appears in the
"Subject:" line so my e-mail filter won't classify your letter
as Spam.
9.3 PSTAT-based HP-UX lsof Questions
The sources for PSTAT-based lsof for HP-UX may be found in
lsof_<revision>/dialects/hpux/pstat.
Lsof's Configure shell script decides to use these sources
when it finds that the /usr/include/sys/pstat subdirectory
exists.
Lsof can be forced to use the PSTAT-based sources by setting
"pstat" in the HPUX_BASE environment variable. Consult
the Configure shell script and 00XPORTING for more information.
9.3.1 Why does PSTAT-based lsof complain about pst_static and
other PSTAT structures?
When lsof starts it may issue one of these fatal error
messages:
lsof: FATAL: can't determine PSTAT static size
lsof: FATAL: can't read <n> bytes of pst_static
lsof: FATAL: pst_static doesn't contain <name>_size
lsof: FATAL: <name>_size should be <n>
These messages indicate that lsof's tests for the proper
level of PSTAT support have failed. The structure names,
given in <name>, and sizes, given in <n>, identify the
support deficiency more precisely.
You may need to upgrade the PSTAT support in your kernel
to be able to use PSTAT-based lsof.
9.3.2 Why does PSTAT-based lsof complain it can't read pst_*
structures?
Lsof may put messages like the following in the NAME
column of its output.
can't read cwd pst_filedetails: Permission denied
can't read mem pst_filedetails: Permission denied
can't read rtd pst_filedetails: Permission denied
can't read txt pst_filedetails: Permission denied
can't read pst_filedetails: Permission denied
can't read 3 stream structures: Permission denied
can't read pst_socket: Permission denied
These messages indicate that the lsof binary lacks the
authority to read the name structures for processes other
than ones belonging to the UID under which lsof is running.
Authority to read the structures of other processes is
limited to root processes -- i.e., lsof must have setuid-root
permission if it is to list open files for arbitrary
processes.
If you want to eliminate these errors, you must run lsof
as root or install it with setuid-root permission.
9.3.3 Why does PSTAT-based lsof rebuild the device cache file
after each reboot?
After each HP-UX rebuild, the first time a user runs lsof it
will report:
lsof: WARNING: device cache mismatch: /dev/tun...
lsof: WARNING: created device cache file: /<user_path>
This happens because the device numbers on /dev/tun* device
nodes are recalculated at each reboot. When lsof detects
a change in the device number of a /dev/tun* file, it rebuilds
its local device cache file.
9.3.4 Why doesn't PSTAT-based lsof report TCP addresses for
telnetd's open socket files?
When lsof can't report TCP addresses for telnetd's open
socket files it is because an unpatched PSTAT kernel
interface doesn't report the addresses to lsof.
This has been addressed in PSTAT kernel patch PHKL_24047.
It is available from the HP IT Resource Center at:
http://itrc.hp.com
In the page's "maintenance / support" box select the
"individual patches" link. Once at its page, select the
"hp-ux" link. On that page select the "Series 800" or
"Series 700" radio button and select "11.11" from the
pull-down list to the right of the button. Under "search
or browse the path list" select "Search by Patch IDs" from
the pull down list, enter PHKL_24047 in the following text
box, and select search. That should lead to information
about PHKL_24047 and a link for downloading it. (You may
have to log in first and you may have to create a login
identity by registering before you can log in.)
Some time in March 2006 the PHKL_24047 patch was "lost"
by the HP-UX networking lab. It has been "found" again
in August 2006 and will be re-released as a GRO patch
"some time." I don't yet know when that will be. You
must contact HP to learn about the availability of the
GRO patch.
9.3.5 Why does PSTAT-based lsof cause an HP-UX 11.11 kernel panic?
When PSTAT-based lsof runs on some HP-UX 11.11 kernels,
the kernel may panic. Symptoms include:
Console message:
0xFBE000301100EF00 00000000 0000EF00 -
type 31 = legacy PA HEX chassis-code
/var/adm/syslog:
... vmunix: Trap Type 15 (Data page fault)
... vmunix: Instruction Address (pcsq.pcoq) = 0x...
The panic is caused by a bug in the way PSTAT's pstat_getstream()
function obtains module names from streams managed by the
otsam stream driver (part of OSI Transport Services). Lsof
calls pstat_getstream() when it encounters an open otsam
stream file. An HP-UX 11.11 system uses otsam if otsam
appears in /stand/system.
HP-UX 11.11 patch PHKL_24507 (available some time after
July 15, 2001) fixes the pstat_getstream() bug. See the
information in the answer to the "Why doesn't PSTAT-based
lsof report TCP addresses for telnetd's open socket files?"
question for information on how to obtain the patch.
9.3.6 Why doesn't PSTAT-based lsof report a CWD that is on a loopback
(LOFS) file system?
When PSTAT-based lsof reports on processes whose current
working directory (CWD) is on a loopback file system, lsof
can't report the open CWD file. The reason is that the HP-UX
11.11 and above kernel's loopback file system code is not
passing the CWD file ID to the kernel's pstat(2) code. Hence
lsof is given no information on the lofs CWD.
The problem was first reported to me by Ermin Borovac and an
internal bug report was filed with the HP-UX file system group
on October 26, 2004. That report has now been answered by the
patch PHKL_33200 -- s700_800 11.11 lofs cumulative patch. The
HP IT Resource Center (http://itrc.hp.com) is a source for the
patch.
9.3.7 Why do some swinstall packages for PSTAT-based HP-UX 11.11
packages complain about setgid and setuid bits?
First, let me explain that I do not provide lsof swinstall
packages for lsof. Others provide them and they should be
contacted about problems with their packages.
However, I have become aware of a problem with one package
about which I have some information I can share. The problem
shows up in these swinstall messages:
ERROR: Unknown owner and/or group for file
"/usr/local/bin/lsof". SUID and/or SGID bit was
not set.
ERROR: Failed installing fileset "lsof.lsof-RUN,r=4.73".
Check the above output for details.
The swpackage SUID/SGID functionality was restricted by changes
for POSIX compliance, breaking backward compatibility. The
patch PHCO_27671 allows SUID/SGID for uid/gid of 0 only, as a
compromise between backward compatibility and POSIX conformance.
If the setuid bit is to be set on the executable, the UID and
GID of the executable must be 0 (zero).
9.3.8 Why won't the bundled C compiler build PSTAT-based lsof for
PA-RISC HP-UX 11.23?
A PA-RISC HP-UX 11.23 bundled C compiler dated May 2005 or
later will not build PSTAT-based lsof. It will deliver error
messages related to the system's <gssapi/gssapi.h> header
file.
There is nothing wrong with that header file or lsof. The
problem is that the bundled C compiler can't cope with the
gssapi.h header file.
The work-around is to use the HP ANSI C compiler. Using gcc
is not a satisfactory work-around. See the answer to the "Why
won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?"
question for more information.
9.3.9 Why won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?
Gcc will not even compile PSTAT-based lsof revisions below 4.77
for PA-RISC HP-UX 11.23 dated May 2005 or later. It reports
errors in lsof's print.c fill_portmap() function about missing
members of the rpcent structure. That happens because gcc
defines _XOPEN_SOURCE_EXTENDED which disables the definition of
the rpcent structure in <netdb.h>.
Using the HP bundled C compiler is not a viable work-around.
That is explained in the answer to the "Why won't the bundled C
compiler build PSTAT-based lsof for PA-RISC HP-UX 11.23?"
While an lsof revision 4.77 or higher can be compiled with gcc,
the results are unreliable. Lsof will compile, but it
occasionally produces segment faults when it runs. I have not
been able to reproduce the failure reliably or locate a
debugger that will work with the gcc-compiled lsof.
The only reliable work-around is to use the HP ANSI C
compiler.
9.3.10 Why does PSTAT-based lsof complain, "FATAL: pst_stream_size
should be: 672; is 72" on HP-UX 11.11 and above?
This message indicates a mismatch between the PSTAT header
files used to build lsof (<sys/pstat.h> and those in the
/usr/include/sys/pstat subdirectory), and those that built the
running kernel.
Unfortunately the June 2008 patch set for HP-UX 11.23 creates
this inconsistency, because it does not contain all the patches
needed to match the kernel with the PSTAT header files. Even
more serious is that the missing patches update the kernel's
PSTAT support to provide TCP/UDP endpoint information to lsof
from TCP/TLI streams.
The patch inconsistency comes about because, while the following
patch is installed,
PHKL_36577 1.0 PM-PSTAT section 2 manpage changes
other kernel patches are not.
The PHKL_36577 patch updates the PSTAT header files and manual
pages to match kernel changes that other patches with the
following numbers (or patches that contain or supersede them)
contain:
PHNE_36575 1.0 Cumulative STREAMS Patch
PHNE_37670 1.0 cumulative ARPA Transport patch
PHNE_37851 1.0 NFS cumulative patch
Those patches implement the kernel changes that support the
delivery of information promised in patch PHKL_36577.
The work-around is to install the missing patches.
9.4 Why won't the HP-UX depot install?
I don't distribute lsof depots, so I can't support them.
From time to time depots prepared by various sites -- e.g.,
usually HP-UX software collection sites -- will contain errors
that cause installation of the depot to fail.
Do not contact me when this happens. Instead, contact the
administrator of the site that prepared the depot.
As should be clear from the bulk of the lsof documentation, I
do not recommend you use pre-built lsof binaries in any form.
Instead, I recommend you obtain the lsof source distribution
and build lsof yourself.
10.0 Linux
10.1 What do /dev/kmem-based and /proc-based lsof mean?
At approximately Linux 2.1.72 and exactly at lsof revision
4.23 support for Linux forks. The first fork, containing
the oldest lsof form is based on access to kernel memory
structures, and is called /dev/kmem-based lsof. A
/dev/kmem-based lsof is heavily intertwined with the Linux
kernel version, its header files, and its system map file.
Typically a /dev/kmem-based lsof needs only setgid permission
to local all open file information.
After approximately Linux 2.1.72 and at revision 4.23 lsof
obtains all its information from the /proc file system.
That lsof is called the /proc-based lsof. A /proc-based
lsof does not read kernel memory, needs neither kernel
header files nor the system map file, and is less likely
to be affected by Linux kernel changes. However, it does
require setuid-root permission to list all open files, and
it can't report file offsets (positions).
After revision 4.52 the /dev/kmem-based Linux sources for
lsof are no longer distributed. Information about them
may be found in the 00INDEX and README files at:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/src
10.2 /proc-based Linux lsof Questions
10.2.1 Why doesn't /proc-based lsof report file offsets (positions)?
/proc-based lsof revisions 4.79 and above can only report file
offsets (positions) for the files of Linux kernels 2.6.22 and
above.
During its initialization /proc-based lsof tests to see if
offset information can be obtained. If it cannot, lsof
disables offset reporting. If the -o option was selected, lsof
also issues this warning:
lsof: WARNING: can't report offset; disregarding -o.
10.2.2 Why does /proc-based lsof report "can't identify protocol" for
some socket files?
/proc-based lsof may report:
COMMAND PID ... TYPE ... NODE NAME
pump 226 ... sock ... 309 can't identify protocol
This means that it can't identify the protocol (i.e., the
AF_* designation) being used by the open socket file. Lsof
identifies protocols by matching the node number associated
with the /proc/<PID>/fd entry to the node numbers found in
selected files of the /proc/net sub-directory. Currently
/proc-based lsof examines these protocol files:
/proc/net/ax25 (untested)
/proc/net/icmp
/proc/net/ipx (needs kernel patch)
/proc/net/netlink
/proc/net/packet
/proc/net/raw
/proc/net/raw6
/proc/net/sctp/assocs
/proc/net/sctp/eps
/proc/net/sockstat
/proc/net/sockstat6
/proc/net/tcp
/proc/net/tcp6
/proc/net/udp
/proc/net/udp6
/proc/net/udplite
/proc/net/udplite6
/proc/net/unix
If /proc-based lsof says it can't identify the protocol
for an open socket file, you may be able to identify the
protocol yourself by using grep to look for the specific
node number in the files of /proc/net -- e.g.,
$ grep <node_number> /proc/net/*
You may not be able to find the desired node number, because
not all kernel protocol modules fully support /proc/net
information.
If you find a matching node number in a /proc/net file that is
not currently being processed by lsof, contact me via e-mail at
<abe@purdue.edu>. I'll discuss adding support to /proc-based
lsof for the protocol of the /proc/net file with you. Make
sure "lsof" appears in the "Subject:" line so my e-mail filter
won't classify your letter as Spam.
The code that matches node numbers of open IPX protocol
socket files to those in /proc/net/ipx requires Jonathan
Sergent's Linux 2.1.79 patch to /usr/src/linux/net/ipx/af_ipx.c.
The patch, suitable for input to Larry Wall's patch program,
may be found in the lsof distribution file:
.../dialects/linux/proc/patches/net_ipx_af_ipx.c.patch
10.2.3 Why does /proc-based lsof warn about unsupported formats?
Lsof may issue the following warning:
lsof: WARNING: unsupported format: /proc/net/<file>
if the header line of the indicated <file> in /proc/net --
ax25, ipx, raw, tcp, udp, or unix -- doesn't match what
lsof expects to find.
When the header line of a /proc/net file isn't what lsof
expects, lsof probably can't parse the rest of the file
correctly and doesn't try. As a result, lsof can't report
any NAME column information (e.g., local and remote addresses)
for socket files bound to the indicated network protocol.
If you get this warning, please send me e-mail at <abe@purdue.edu>.
Include the contents of the file lsof claims has an unsupported
format. Make sure "lsof" appears in the "Subject:" line so my
e-mail filter won't classify your letter as Spam.
10.2.4 Why does /proc-based lsof report "(deleted)" after a path name?
The "(deleted)" notation following a path name in /proc-based
lsof's NAME column comes from the /proc/<PID>/fd/<FD> entry
for the open file. It's the Linux kernel's way of indicating
the file is open but has been unlinked (rm'd).
10.2.5 Why doesn't /proc-based lsof report full open file information
for all processes?
/proc-based lsof can only report on processes whose /proc
files it has permission to read. /proc normally grants
permission to read all its files only to root or to the
owning user ID.
Without permission to read most /proc files, lsof can only
report full information for processes belonging to the user
who is running lsof. /proc-based lsof may be able to report
some information for all processes, depending on the
permissions of their associated /proc files, but usually
/proc-based lsof won't be able to access the files in
/proc/<PID>/fd/ that describe regular open files.
If you want /proc-based lsof to report on all processes, you
must install it with setuid-root permission.
10.2.6 Why won't Customize offer to change HASDCACHE or WARNDEVACCESS
for /proc-based lsof?
/proc-based lsof doesn't read device information from /dev
or the device cache file, so it makes no sense to change
the state of device cache processing or /dev node accessibility
warnings.
10.2.7 /proc-based lsof Linux NFS questions
10.2.7.1 Why can't lsof find files on an accessible NFS file system?
On occasion lsof may be unable to identify that an open
file is on an NFS file system. This is most likely the
result of a bug in the way the Linux kernel supplies
information to the reader of /proc/mounts (lsof) -- sometimes
that pseudo-file is truncated by the kernel.
One way to see if this is the case is to search for the
NFS file system in /proc/mounts -- e.g.,
$ grep <NFS_file_system_mount_point> /proc/mounts
If you get no output or the third word of the output isn't
"nfs", then lsof won't consider the file system an NFS file
system.
A second test is to look at the end of /proc/mounts --
e.g.,
$ tail /proc/mounts
If tail reports "# truncated" then /proc/mounts is incomplete
because of a Linux kernel bug. The bug is documented at:
http://www.xss.co.at/sysinfo/mounts.html
The bug is fixed in Linux kernel 2.4.18, and possibly in
some earlier Linux kernel versions.
10.2.7.2 Why can't lsof find files on an inaccessible NFS file system?
If lsof issues this message about a Linux file system,
mounted from an NFS server:
lsof: WARNING: can't stat() nfs file system /xxx/yyy
Then lsof won't be able to find any open files on the file
system.
That's because of an inadequacy in the Linux /proc file
system. Its /proc/mounts file doesn't give the device
doublet (major and minor numbers) of the file system as do
many UNIX systems (e.g., Solaris). The only way lsof can
get the device doublet for a Linux file system is to call
stat(2) on the file system path, which fails if the NFS
server isn't accessible.
When lsof doesn't know the device doublet of a file system,
it can't find open files on the inaccessible file system,
because it can't match the doublets of open files to the
doublet of the inaccessible file system.
This topic is covered extensively in lsof(8) it its ALTERNATE
DEVICE NUMBERS and BLOCKS AND TIMEOUTS sections.
10.2.8 Why doesn't /proc-based Linux lsof report socket options and
values, socket state flags, and TCP options and values?
The Linux /proc file system doesn't report socket options
and values, socket states, and TCP options and values to
lsof.
10.2.9 Does /proc-based Linux lsof use a device cache?
No. The Linux /proc/<PID>/fd/* entries provide device names to
lsof via readlink(2). It is not necessary to enable device
cache processing for /proc-based Linux lsof via the Customize
script or modifications to the Linux machine.h header file.
10.2.10 Why doesn't /proc-based Linux lsof report any or all file structure
values for its +fcfgGn option?
/proc-based lsof revisions 4.79 and above can only report some
file structure values for Linux kernels below 2.6.22.
When running on Linux kernels at 2.6.22 and above lsof 4.79 can
report some file flag values -- i.e., in response to the +fg or
+fG options. The flag values are obtained from the
/proc/<PID>/fdinfo/ files introduced at Linux kernel 2.6.22.
/proc-based Linux lsof tests its availability to obtain file
flag values at initialization. If values are not available,
lsof disables file flag reporting. If the flags were requested
with +fg or +fG, lsof displays this warning:
lsof: WARNING: can't report file flags; disregarding +f.
As a special note, when Linux lsof can report flag bits, it
will not report 'R' for a read-only file. There is no
read-only flag bit O_* symbol in <fcntl.h> (or <bits/fcntl.h>)
and lsof reports only bits that are set. The absence of O_RDWR
and O_WRONLY flag bits implies the file is read-only.
10.3 Special Linux file types
10.3.1 Why is ``DEL'' reported as a Linux file type?
Lsof usually reports entries from the Linux /proc/<PID>/maps
file with ``mem'' in the TYPE column. However, when lsof can't
stat(2) a path in the process' ``maps'' file and the ``maps''
file entry contains ``(deleted)'', indicating the file was
deleted after it had been opened, lsof reports the file type as
``DEL''.
10.3.2 Why is ``unknown'' reported as a Linux file type?
Lsof may report a Linux file's type as ``unknown'' in the TYPE
column when lsof can't obtain complete stat(2) results for the
file.
Usually the NAME column will contain a ``(stat: xxx)'' error
message, but that could have been suppressed with the lsof
``-w'' option.
10.4 Linux ``mem'' Entry Problems
10.4.1 What do ``path dev=xxx'' and ``path inode=yyy'' mean in the
NAME column of Linux ``mem'' file types?
When the device or inode number in the process' ``maps'' file
entry doesn't match the stat(2) results from the file path,
lsof reports the inconsistent information from the stat(2) of
the path parenthetically after the path in the NAME column
in one of these forms:
(path dev=xxx) only the device number,
``xxx'', from a stat(2) of the
``maps'' file entry path
differs from the ``maps'' file
entry value reported in the
DEVICE column.
(path inode=yyy) only the inode number,
``yyy'', from a stat(2) of the
``maps'' file entry path
differs from the ``maps'' file
entry value reported in the
NODE column.
(path dev=xxx inode=yyy) Both device and inode numbers
differ.
Lsof reports the ``maps'' file device number in the DEVICE
column and the inode number in the NODE column.
When device and inode mismatches occur, lsof suppresses the
reporting of link count and size. See the answer to the "Why
is neither link count nor size reported for some Linux ``DEL''
and ``mem'' file types?" question for more information.
Device and inode inconsistencies can occur when a file at a
``maps'' path is replaced after the process has started, or
when a different file system with similar path names is mounted
on top of the original file system.
The device inconsistency parenthetical messages can be
suppressed with lsof's ``-w'' option.
10.4.2 Why is neither link count nor size reported for some Linux
``DEL'' and ``mem'' file types?
Link count and size are not reported for some entries from the
process' ``maps'' file because a stat(2) of the entry file path
failed or stat(2) delivered device or inode numbers that don't
match the ones in the ``maps'' entry.
When the stat(2) device or inode numbers don't match those in
the ``maps'' file entry, it is likely that the stat(2) results
don't apply to the file that was originally mapped by the
process and whose path appears in the ``maps'' file entry, so
lsof tries to avoid reporting possibly incorrect information.
See the answer to the "What do ``path dev=xxx'' and ``path
inode=yyy'' mean in the NAME column of Linux ``mem'' file
types?" for more information on how mismatched stat(2) device
and inode numbers are reported.
10.5 Special Linux NAME column messages
10.5.1 What does ``(stat: xxx)'' mean in the NAME column of Linux
files?
When lsof tried to stat(2) the path in the NAME column, the
stat(2) system call failed and produced an error message of
``xxx''.
This situation usually occurs if the lsof process lacks
permission to stat(2) the path -- e.g., the lsof executable
lacks root permission, or lsof is attempting to stat(2) a path
on an NFS device mounted with the root_squash option.
The message can be suppressed with lsof's ``-w'' option.
10.5.2 What does ``(readlink: xxx)'' mean in the NAME column of
Linux files?
When lsof tried to convert the /proc/<PID>/fd path, reported in
the NAME column, to its full and more meaningful path, the
readlink(2) system call used to do the conversion failed. The
readlink(2) failure message is ``xxx''.
This situation usually occurs if the lsof process lacks
permission to readlink(2) some part of the path -- e.g., the
lsof executable lacks root permission, or lsof is attempting to
stat(2) a path on an NFS device mounted with the root_squash
option.
The message can be suppressed with lsof's ``-w'' option.
10.6 Why is ``NOFD'' reported as a Linux file type?
When lsof lacks permission to use opendir() on the fd/
subdirectory of a process' /proc/<PID> directory, it reports a
single file of the type ``NOFD'' (for no file descriptors).
Lsof reports the the /proc/<PID>/path in the NAME column,
followed by "(opendir: xxx)", where ``xxx'' is the error
message returned by opendir().
The ``NOFD'' entry can be suppressed with lsof's ``-w'' option.
10.7 Why does Linux lsof report a NAME column value that begins with
``/proc''?
When lsof has problems processing a ``/proc/<PID>'' entry --
e.g., it can't convert the entry to a full and more meaningful
path name, or it can't access the /proc/<PID>/fd subdirectory
with opendir() -- it will report the /proc/<PID> path in the
NAME column.
10.8 Linux /proc/net/tcp* and /proc/net/udp* issues
10.8.1 Why use the Linux -X option?
If you're not interested in TCP/IP socket information for a
particular use of lsof, adding the -X option will make lsof run
more quickly, because -X inhibits the reading of the
/proc/net/tcp* and /proc/net/udp* files. For example, you may
only be interested in knowing what process has a particular
file open.
When the Linux system has a large number of open TCP/IP socket
files, the time savings provided by -X can be significant.
10.8.2 Why does lsof say ``-i is useless when -X is specified''?
If -X is specified, lsof can't report much information on open
TCP/IP socket files. However, lsof's -i option requests that
information. Hence, the two options conflict and can't be used
together.
10.8.3 Why does lsof say ``can't identify protocol (-X specified)''?
If the Linux lsof -X option is specified and an open socket
file can't be identified without accessing the /proc/net/tcp*
and /proc/net/udp* files, lsof will report that it can't
identify the socket's protocol and that the failure may be
caused by the -X specification
11.0 NetBSD Problems
11.1 Why doesn't lsof report on open kernfs files?
Lsof doesn't report on open NetBSD kernfs files because the
structures lsof needs aren't defined in the kernfs.h header
file in /sys/misc/kernfs.
11.2 Why doesn't lsof report on open files on: file descriptor
file systems; /proc file systems; 9660 (CD-ROM) file systems;
MS-DOS (floppy disk) file systems; or kernel file systems?
Lsof is not able to report on open files on certain file
system if /usr/src/sys/msdosfs didn't exist when the lsof
Configure script ran and lsof was made. /usr/src/sys/msdosfs
contains header files lsof needs for collecting data on
certain file system files.
You can tell if an lsof executable above) lacks support
for a file system if the following test of `lsof -v` produces
nothing:
$ lsof -v 2>&1 | grep <support_enabled_definition>
The <support-enabled_definition> will be:
File System Type Definition Note
---------------- ---------- ----
File descriptor HASFDESCFS
/proc HASPROCFS
9660 HAS9660FS
MS-DOS HASMSDOSFS (lsof 4.61 and above)
Kernel HASKERNFS
The work-around is to install /usr/src/sys, rerun the lsof
Configure script, and remake lsof.
11.3 Why does lsof produce confusing results for nullfs file
systems?
Consider this report from /sbin/mount:
/usr/home on /home type null (local)
(According to /sbin/mount /usr/home is the mounted-on device
and /home is the mounted-on directory.)
When lsof is asked to report on open files on /home, it
will report them as files on /usr/home instead. That's an
artifact of the NetBSD kernel's dynamic name lookup cache
(DNLC) and the way the kernel handles nullfs mounted-on
directories.
While lsof will report all open files on /home when given
/home as a file system directory argument, even though
reporting them as located on /usr/home, lsof will not find
the same files when asked to report on all open files on
/usr/home when given /usr/home as a file system device
argument. That's because from the mount perspective
/usr/home is equivalent to a device, but from the device
perspective it is still a directory.
So, what this lsof command reports:
$ lsof /home
... NAME
... /usr/home/...
Won't be duplicated by this lsof command:
$ lsof /usr/home
Another way to look at this confusing /home and /usr/home
example is to consider what stat(2) reports. For /home
stat(2) reports a device doublet that matches what lsof
finds in open file node structures, while the device doublet
stat(2) reports for /usr/home won't match what lsof finds.
Nor does the mode reported by stat(2) indicate a block
devices, as is the expected case.
There is no simple answer to this confusion, nor is there
even a simple explanation. Simply be aware that when
supplying file system arguments to lsof on NetBSD, use the
mounted-on directory name for a nullfs as the lsof argument,
and don't be surprised when the NAME column reports the
mounted-on device name.
11.4 NetBSD header file problems
11.4.1 Why can't the compiler find some NetBSD header files?
If the compiler's pre-processor complains it can't find some
header files when it compiles lsof source files, /usr/include
and /usr/src may not have all the header files lsof needs.
As a work-around use the NETBSD_SYS environment variable
to specify to lsof the location of the additional header
files -- e.g.,
% setenv NETBSD_SYS /my_source
% ./Configure -n netbsd
or
$ NETBSD_SYS=/mys_source ./Configure -n netbsd
Caution: using this work-around may cause the lsof Configure
script to activate or omit different features, depending
on where it finds the header files that determine the state
of the features.
11.4.2 Why does NetBSD lsof produce incorrect output?
If the NetBSD system's kernel was built from header files that
don't match those in /usr/include -- e.g., //usr/src has the
ones from which the kernel was built -- lsof may build, but
won't produce correct output.
As a possible work-around, try directing the C compiler to
select header files from /usr/src before it selects them from
/usr/include. That can be done with the DEBUG make string --
e.g.,
$ make DEBUG="-I/usr/src -I/usr/include"
If that work-around fails, try using the LSOF_INCLUDE and
NETBSD_SYS environment variables to swap /usr/include and
/usr/src when running the Configure script, then use the make
DEBUG string when running make -- e.g.,
$ LSOF_INCLUDE=/usr/src; export LSOF_INCLUDE
$ NETBSD_SYS=/usr/include; export NETBSD_SYS
$ ./Configure -n netbsd
$ make DEBUG="-I/usr/src -I/usr/include"
11.5 Why isn't lsof feature xxx enabled for NetBSD?
Lsof's Configure script enables NetBSD features by locating
and examining header files associated with the features,
and based on what it finds, setting compile-time definitions
in Makefiles. (See 00PORTING for a list of the definitions.)
When Configure doesn't find header files or doesn't find
appropriate values in header files, that may mean the header
file tree lsof is searching is incomplete or out of date.
Lsof normally looks for NetBSD header files in /usr/include.
It can also be directed to look in other directories --
e.g., /sys -- if told to do so with the contents of the
LSOF_INCLUDE and NETBSD_SYS environment variables.
To determine what header file enables a missing feature,
check the NetBSD stanza in the Configure script. Then
check the locations it checks for the indicated header
files and contents.
See 00XCONFIG for more information on LSOF_INCLUDE and
and NETBSD_SYS.
12.0 NEXTSTEP and OPENSTEP Problems
12.1 Why can't lsof report on 3.1 lockf() or fcntl(F_SETLK)
locks?
Lsof has code to test for locks defined with lockf() or
fcntl(F_SETLK) under NEXTSTEP 3.1, but that code has never
been tested. I couldn't test it, because my NEXTSTEP 3.1
lockf() and fcntl(F_SETLK) functions return "Invalid
argument" every way I have tried to invoke them.
If your NEXTSTEP 3.1 system does allow you to use lockf()
and fcntl(F_SETLK) and lsof doesn't report locks set with
them, then the code in .../dialects/next/dnode.c probably
isn't correct. Please contact me via e-mail at <abe@purdue.edu>
and tell me how you got your lockf() and fcntl(F_SETLK) system
calls to work. Make sure "lsof" appears in the "Subject:" line
so my e-mail filter won't classify your letter as Spam.
12.2 Why doesn't lsof compile for NEXTSTEP with AFS?
I no longer have a NEXTSTEP test system that has AFS.
Changes to lsof since I once had a test system have caused
me to change the AFS code in NEXTSTEP without being able
to test the changes.
If you need AFS support for NEXTSTEP and can't get it to
compile, please contact me. Perhaps we can jointly fix
the problems.
13.0 OpenBSD Problems
13.1 Why doesn't lsof support kernfs on my OpenBSD system?
Lsof supports the kernel file system on OpenBSD versions
whose /sys/miscfs/kernfs/kernfs.h (or <miscfs/kernfs/kernfs.h>
header file correctly defines the kern_target structure.
The lsof Configure script's openbsd stanza checks for the
presence of the structure's kt_name element and activates
kernfs support for the CFLAGS -DHASKERNFS definition only
when it finds kt_name.
The kernfs.h header file is scheduled to be updated in the
OpenBSD 2.1 release, according to Kenneth Stailey, who
authored its changes.
13.2 Will lsof work on OpenBSD on non-x86-based architectures?
I've not tested lsof on an OpenBSD system that uses a
non-x86-based architecture, but I've had one report that
lsof 4.33 compiles and works on OpenBSD for the pmax
architecture (decstation 3100).
13.3 <sys/pipe.h> problems
13.3.1 Why does the compiler claim nbpg isn't defined?
When compiling lsof on some (older) OpenBSD SPARC versions,
the compiler may complain:
In file included from ../dlsof.h:191,
from ../lsof.h:166,
from fino.c:52:
/usr/include/sys/pipe.h:83: `nbpg' undeclared here
(not in a function)
/usr/include/sys/pipe.h:83: size of array `ms' has
non-integer type
This happens because <sys/pipe.h> uses NBPG from
<machine/param.h> to size the `ms' array, and some OpenBSD
systems define NBPG in terms of a kernel integer variable,
nbpg.
Lsof revisions 4.46 and above have a hack to dlsof.h,
developed by Volker Borchert that avoids the compiler
problem for SPARC OpenBSD 2.3. The hack might work for
other OpenBSD SPARC versions, but hasn't been tested there.
If you want to enable the hack for your OpenBSD SPARC
version, modify this code in .../dialects/n+obsd/dlsof.h:
# if defined(OPENBSDV)
# if OPENBSDV==2030 && defined(__sparc__)
# if defined(nbpg)
#undef nbpg
# endif /* defined(nbpg) */
#define nbpg 4096 /* WARNING!!! ... */
# endif /* OPENBSDV==2030 && defined(__sparc__) */
#include <sys/pipe.h>
#endif /* defined(OPENBSDV) */
You will probably want to change the second #if test to
match your OpenBSD version. You may also want to change
what value is assigned to nbpg. See the next section,
"What value should I assign to nbpg?"
13.3.2 What value should I assign to nbpg?
If you need to enable the nbpg hack, described in "Why does
the compiler claim nbpg isn't defined?", you may also need
to assign a value other than 4096 to nbpg. 4096 works for
the sun4c processor and should work for sun4m, but 8192
may be needed for sun4.
Check <machine/param.h> and other OpenBSD documentation to
determine the correct nbpg assignment.
13.4 Why doesn't lsof report on open MS-DOS file system (floppy
disk) files?
Lsof is not able to report on open MS-DOS file system files
if /usr/src/sys/msdosfs didn't exist when the lsof Configure
script ran and lsof was made. /usr/src/sys/msdosfs contains
header files lsof needs for collecting data on MS-DOS file
system files.
You can tell if an lsof executable (revisions 4.61 and
above) lacks MS-DOS file system support if the following
command reports nothing:
$ lsof -v 2>&1 | grep HASMSDOSFS
The work-around is to install /usr/src/sys, rerun the lsof
Configure script, and remake lsof.
13.5 Why isn't lsof feature xxx enabled for OpenBSD?
Lsof's Configure script enables OpenBSD features by locating
and examining header files associated with the features,
and based on what if finds, setting compile-time definitions
in Makefiles. (See 00PORTING for a list of the definitions.)
When Configure doesn't find header files or doesn't find
appropriate values in header files, that may mean the header
file tree lsof is searching is incomplete or out of date.
Lsof normally looks for OpenBSD header files in /usr/include
and /sys. It can also be directed to look in other
directories if told to do so with the contents of the
LSOF_INCLUDE and NETBSD_SYS environment variables.
To determine what header file enables a missing feature,
check the OpenBSD stanza in the Configure script. Then
check the locations it checks for the indicated header
files and contents.
See 00XCONFIG for more information on LSOF_INCLUDE and
and NETBSD_SYS.
14.0 Output Problems
14.1 Why do the lsof column sizes change?
Lsof dynamically sizes its output columns each time it runs
to make sure that each column takes the minimum space.
Column parsing -- e.g., with awk -- is possible, because
each column is guaranteed to be separated from the preceding
one by at lease one space, and no column except the last
(NAME) contains embedded spaces.
14.2 Why does the offset have ``0t' and ``0x'' prefixes?
The offset value that appears in the SIZE/OFF column has
``0t' and ``0x'' prefixes to distinguish it from size values
that may appear in the same column.
Normally if the offset value is less than 100,000,000 (8
digits), it appears in decimal with a ``0t' prefix; over
99,999,999, in hexadecimal with a ``0x'' prefix.
A decimal offset is handy, for example, when tracking the
progress of an outbound ftp transfer. When lsof reports
on the ftp process, it will report the size of the file
being sent with its open descriptor; it will report the
progress of the transfer via the offset of the outbound
open ftp data socket descriptor.
The ``-o [n]'' option may be used to specify the maximum
number of decimal digits to be printed after ``0t'' before
lsof switches to the hexadecimal digits after `0x''. As
already noted, the default decimal digit count is 8.
14.3 What are the values printed in the FILE_FLAG column
and why is 0x<value> sometimes included?
The two comma separated lists, separated by a semicolon,
printed in the FILE-FLAG column (when the "+fg" option is
specified), are short-hand names or hexadecimal values for
the bits lsof finds in the f_flag or f_flags member of file
structures for files (the first list, the one before the
semicolon), and process open files flags found in various
kernel structures, often named "pofile" (the second list,
the one after the semicolon).
Lsof determines the short-hand names from symbols in the
<fcntl.h>, <linux/fs.h>, <sys/fcntl.h>, <sys/fcntlcom.h>,
o<sys/file.h>, and <sys/user.h> header files.
See the discussion of FILE-FLAG in the OUTPUT section of
the lsof man page, and the FF_* and POF_* symbols in lsof.h
for a list of the names.
Bits with no names defined for them are represented by an
0x<value> member of the comma-separated list -- a hexadecimal
integer. When "+fG" is specified (instead of "+fg"), lsof
will list all flag values as two hexadecimal integers,
separated by a semicolon.
When "-FG" is specified to get the flags in an output field,
the format defaults to hexadecimal. You can get names
instead by following "-FG" with "+fg" -- e.g.,
$ lsof -FG +fg ...
However, when you precede "-FG" with "+fg" -- e.g.,
$ lsof +fg -FG
the format will be hexadecimal; order is important.
14.3.1 Why doesn't lsof display FILE_FLAG values for my dialect?
All versions of lsof except the /proc-based Linux lsof
report FILE-FLAG values. Lsof can't obtain FILE-FLAG
information from the Linux /proc interface.
14.4 Network Addresses
14.4.1 Why does lsof's -n option cause IPv4 addresses, mapped to
IPv6, to be displayed in IPv6 notation?
When you use the -n option to tell lsof to display numeric
network addresses, and an IPv4 address has been mapped to
IPv6, lsof displays the address in IPv6 format and puts
"ipv4" in the TYPE column. That combination indicates the
IPv4 address has been mapped to IPv6.
For example, the IPv4 address 1.2.3.4, when mapped to an
IPv6 address, will be displayed by lsof as:
[::ffff:1.2.3.4]
The enclosing brackets are lsof's signal that this is an
IPv6 address. Inside the brackets is a standard IPv6
address, reported by inet_ntop(). The first two colons,
signifying zeroes in the first 64 bits of the IPv6 address,
and the hexadecimal ffff in the next 32 bits, indicate that
the last 32 bits contains a mapped IPv4 address, which is
then displayed in IPv4 dot notation.
14.5 Why does lsof output \x, ^x, or \xnn for characters
sometimes?
Lsof displays only printable ASCII characters. Lsof
considers a character printable if isprint(3) says it
is. If isprint(3) says a character isn't printable,
the lsof may page explains:
"... Non-printable characters are printed in one of
three forms: the C ``\[bfrnt]'' form; the control
character `^' form (e.g., ``^@''); or hexadecimal
leading ``\x'' form (e.g., ``\xab''). Space is
non-printable in the COMMAND column (``\x20'') and
printable elsewhere."
14.5.1 Why is space considered a non-printable character in command
names?
Space is considered an unprintable character in command
names because it is sometimes possible to hide the full
command name from scripts that parse ps(1) output by
embedding a space in the name.
14.6 Why doesn't lsof print all the characters of a command name?
By default lsof prints the first nine characters of the
names of commands associated with processes. If more
characters are required, the "w" value of the "+c w" option
may be used to specify a larger width.
If "w" is zero ('0') lsof will print all characters of all
command names up to the limit of the number of characters
supplied by the particular UNIX dialect. When reporting
command names, lsof replaces non-printable characters as
discussed in the answer to " Why does lsof output \x, ^x, or
\xnn for characters sometimes?"
See the answer to the "Why is space considered a non-printable
character in command names?" question for an explanation of why
spaces are replaced by the ``\x20'' representation in command
names.
The number of command name characters supplied to lsof by UNIX
dialects in files and structures varies by dialect. For
example, Linux 2.4.27 supplies lsof the first 15 characters of
command names and Solaris 9 supplies 16. Thus, even if "w" is
zero ('0'), lsof can't report more characters for command names
on those two UNIX dialects than they provide lsof.
14.7 Why does lsof reject some -c command names, saying their lengths
are "> what system provides (nn)"?
The command name length that a specific system provides varies
from dialect to dialect. As noted in the answer to the "Why
doesn't lsof print all the characters of a command name?"
question, Linux and Solaris provide a limited number of command
name characters.
When more characters are specified in the parameter to the -c
option, lsof considers it an error and issues a fatal error
message -- e.g.,
lsof: "-c xxxxyyyy" length (8) > what system provides (7)
The only work-around is to specify no more characters to -c
that the system provides to lsof.
14.8 Why does lsof sometimes print TYPE numbers instead of names?
When lsof can't convert a type number to a name for printing in
the TYPE column, it will report the number as four octets.
14.9 Marker line format problems
14.9.1 Why won't lsof accept a marker line format?
Lsof's Configure script must find the localtime(3) and
strftime(3) functions in the dialect's C library in order to
enable support for marker line formats.
Check the output of lsof's -v option for the presence of
-DHAS_STRFTIME in the compiler flags. If it isn't there,
Configure didn't find the necessary two C library functions.
If you think lsof should have found the functions, make a copy
of the C test program in the Configure script that it uses to
find the functions. Then use the copy, or a more informative
modification of it, to learn why Configure can't find the
functions. You can find that program by searching for
strftime.
14.9.2 Why does lsof reject the NL (%n) marker line format?
When repeat mode and field output (with -F) have both been
specified, lsof won't allow new line (NL) formats to be
specified with ``%n''. That's because the marker line is
always guaranteed to be a single line.
There is no work-around to this restriction.
14.10 How are protocol state name exclusion and inclusion used?
Protocol state name inclusion and exclusion with the ``-s p:s''
option and its arguments have some issues to consider. Note:
the ``-s p:s'' option is only available when the help output,
obtained with -h or -?, shows it; it was a recent addition to
lsof and is supported only on dialects where it could be
tested.
First, there is the problem of determining what state names, if
any, the dialect produces. Try running this lsof command to
find them:
$ lsof -i
Knowing the state names of interest, the next problem is to
decide on the lsof options and their parameters that will
produce the desired output. Here some examples are probably
the most useful.
To list only TCP socket files in LISTEN and CLOSE_WAIT states,
use:
$ lsof -itcp -stcp:listen,close_wait
or
$ lsof -iTCP -sTCP:LISTEN,CLOSE_WAIT
Case isn't important to lsof in protocol and state names.
To exclude TCP socket files in CLOSE_WAIT state, use:
$ lsof -itcp -stcp:^close_wait
Note the `^' preceding close_wait; it selects exclusion. You
can mix included and excluded names in a comma separated list,
but you may not include and exclude the same name for the same
protocol.
To list TCP files in LISTEN state and UDP files in Idle state,
use:
$ lsof -i -stcp:listen -sudp:idle
Note: if you don't accompany the ``-s p:s'' list option and
argguments with the -i option, lsof will list all other regular
files, while applying the specified inclusion and exclusion
specifications to network files. Generally, then, you want to
use -i with -s.
14.10.1 Why doesn't my dialect support state name exclusion and inclusion?
When state name inclusion and exclusion was added, I had access
to test systems for AIX, Darwin, FreeBSD, Linux, PSTAT-based
HP-UX and Solaris.
Therefore, I was unable to add and test the support to any other
UNIX dialects.
If a dialect has the support, then the HASTCPUDPSTATE definition
in its machine.h header file will be active; if not, it will be
absent or commented out.
If your dialect doesn't have the support and you want it added,
you will have to provide me Internet access to a test host, where
I can compile lsof and have the credentials to test the changes
the support requires. If that's possible for you, please contact
me via e-mail at <abe@purdue.edu>. Make sure "lsof" appears in
the "Subject:" line so my e-mail filter won't classify your letter
as Spam.
15.0 Pyramid Version Problems
15.0.5 Statement of deprecation
As of lsof revision 4.52 support for all Pyramid versions has
been dropped. Contact me via e-mail at <abe@purdue.edu> if you
are interested in obtaining the last lsof Pyramid distribution.
Make sure "lsof" appears in the "Subject:" line so my e-mail
filter won't classify your letter as Spam.
16.0 SCO Problems
16.1 SCO OpenServer Problems
16.1.1 How can I avoid segmentation faults when compiling lsof?
If you have an older SCO OpenServer compiler, it may get
a segmentation fault when compiling some lsof modules.
That appears to happen because of the -Ox optimization
action requested in the lsof Makefile.
Try changing -Ox to -O with this make invocation:
$ make DEBUG=-O
Bela Lubkin supplied this tip and Steve Williams verified
it.
16.1.2 Where is libsocket.a?
If you compile lsof and the loader says it can't find the
socket library, libsocket.a, called by the -lsocket option
in the lsof compile flags, you probably are running an SCO
OpenServer release earlier than 5.0 and don't have the
TCP/IP Development System package installed.
You may have the necessary header files, because you have
the TCP/IP run-time package installed, but if you don't
have the TCP/IP Development System package installed, you
won't have libsocket.a.
Your choices are to install the TCP/IP Development System
package or upgrade to OpenServer Release 5.0. You will
find libsocket.a in 5.0 -- you'll find all the libraries
and header files there, in fact -- and you can use gcc to
compile lsof if you don't want to install the 5.0 Development
System package.
16.1.3 Why do I get "warning C4200" messages when I compile lsof?
When you compile lsof under OSR 3.2v4.2 (and perhaps under
earlier versions as well), you may get many compiler warning
messages of the form:
node.c(183) : warning C4200: previous declarator is not
compatible with default argument promotion
In my opinion this is a bug in the OSR compiler. Because
the compiler cannot handle full ANSI-C prototypes, it
assumes default types for function parameters as it encounters
untyped in a function prototype -- e.g., in this function
declaration from node.c,
readrnode(ra, r)
KA_T ra;
struct rnode *r;
{
...
the compiler assigns default int types to the ra and r
arguments.
Then, when the compiler encounters the fully typed parameters
after the function skeleton and sees parameters with types
that don't match the assumptions it previously made, it
whines about its own assumptions.
You can ignore these messages.
16.2 SCO|Caldera UnixWare Problems
16.2.1 Why doesn't lsof compile on my UnixWare 7.1.1 or above
system?
When you Configure lsof with the "uw" abbreviation and try
to compile it for UnixWare 7.1.1, you may get compiler
error messages like this:
UX:acomp: ERROR: "dproc.c", line 98:
undefined struct/union member: p_pgidp
This suggest that you probably have a non-stop cluster
UnixWare 7.1.1 system. Its <sys/proc.h> header file differs
from the one on the system where I did the lsof port to
UnixWare 7.1.1. I currently don't have access to a non-stop
cluster system to be able to develop changes to lsof that
would make it compile and work there.
If you have a non-stop cluster UnixWare 7.1.1 system, want lsof
for it, and can offer me a test account on the system, please
contact me via e-mail at <abe@purdue.edu>. Make sure "lsof"
appears in the "Subject:" line so my e-mail filter won't
classify your letter as Spam.
If you have a system with nsc_cfs and can offer me a test
account on it, please contact me via e-mail at <abe@purdue.edu>.
Make sure "lsof" appears in the "Subject:" line so my e-mail
filter won't classify your letter as Spam.
16.2.2 Why does lsof complain about node_self() on my UnixWare
7.1.1 or above system?
If lsof exits immediately after issuing this message:
can't identify process NSC node; node_self(): <message>
It means that lsof has been built to run on a NonStop
Cluster (NSC) UnixWare 7.1.1 or higher system and can't
get the number of the node on which it is running. Lsof
uses the node number to determine the path to the kernel
boot file.
You can tell if lsof has been built for NSC by looking for
"-DHAS_UW_NSC" in lsof's "-v" option output.
If the system on which you're trying to run lsof isn't
running an NSC kernel, you will need to build a non-NSC
lsof.
16.2.3 Why does UnixWare 7.1.1 or above complain about -lcluster,
node_self(), or libcluster.so?
When you build, compile, and load lsof for UnixWare 7.1.1
and above, ld may complain that it can't find the -lcluster
library or that the node_self symbol is undefined. When
you try to run an existing lsof binary it may complain that
libcluster.so can't be found.
These messages mean the tests made by Configure on your
system led it to believe your system is running a NonStop
Cluster (NSC) kernel, or the lsof binary you're trying to
use was built on a NonStop Cluster system. If an lsof
binary was built for NSC, this shell command produces
output:
$ strings <lsof_binary> | grep HAS_UW_NSC
If that's not the case, and you can rebuild lsof, set the
UW_HAS_NSC environment variable to "N" and do this:
$ Configure -n clean
$ UW_HAS_NSC=N
$ export UW_HAS_NSC
$ Configure -n uw
$ make
You can also edit Makefile and lib/Makefile. Remove
-DHAS_UW_NSC from the CFGF strings. Remove -lcluster from
the CFGL strings. Then run make again.
If you have an existing NSC lsof binary and you want one
for a non-NSC system, you will have to build lsof yourself
on the system where you want to use it. (That's always a
good idea anyway.)
16.2.4 Why does UnixWare 7.1.1 or above lsof complain it can't
read the kernel name list?
If lsof complains:
can't read kernel name list from <path>
It means that lsof can't find the booted kernel image file
at <path>. On NonStop Cluster (NSC) UnixWare 7.1.1 or
higher systems lsof determines the booted file path by
examining this file:
/stand/`node_self`/boot
If examining that file doesn't lead to an NSC path, lsof
uses:
/stand/1/unix
On non-NSC systems lsof expects the booted kernel image to
be in /stand/unix.
If your booted kernel image is in a different place, use
lsof's "-k <path>" option to specify its path.
16.2.5 Why doesn't lsof report link count, node number, and size
for some UnixWare 7.1.1 or above CFS files?
Lsof reports link count, node number, and size for open
CFS files as recorded in their kernel node structure's
cached attributes. Sometimes not all attributes are cached
on the node where lsof runs, so lsof cannot report them.
16.2.6 Why doesn't lsof report open files on all UnixWare 7.1.1
NonStop Cluster (NSC) nodes?
Lsof can only report on files open on the node on which it
runs, because the information lsof reports comes from the
private kernel memory of the node. This may mean that
asking lsof to find a specific open file, or use of a
specific Internet address or port, may not report all open
instances on nodes other than the one used to run lsof.
You can use the NSC onnode(1) command to run lsof on specific
nodes, or the onall(1) command to run lsof on all nodes --
e.g.,
$ onall lsof [options] 2>&1 | less
or
$ onnode node-number lsof [options] 2>&1 | less
Note that, when lsof is run all nodes, the path name
component assembly results it reports in its NAME column
may vary, because the dynamic name cache from which lsof
gets the components is private to the kernel of each node.
Also note the use of shell redirection in the examples to
merge the standard error file information from onnode and
onall with lsof's standard output file output. That will
put the onnode and onall node announcements in proper
sequence with lsof's output.
16.2.7 Why doesn't lsof report the UnixWare 7.1.1 NonStop Cluster
(NSC) node a process is using?
To induce lsof to report the node on which a process runs
would be a significant, non-standard modification to lsof.
It has much wider implications than merely the printing of
a number in an output column. I'm not currently (April
2001) prepared to undertake such a modification.
If you want node-specific NSC information about open files,
run lsof under the control of onall(1) or onnode(1).
$ onall lsof [options] 2>&1 | less
or
$ onnode node-number lsof [options] 2>&1 | less
16.2.8 Why does the compiler complain about missing UnixWare 2.1[.x]
header files?
SCO|Caldera didn't ship the following header files with
UnixWare 2.1 through 2.1.3:
<fs/proc/prdata.h>
<fs/procfs/prdata.h>
<sys/fs/fifonode.h>
<sys/fs/namenode.h>
Lsof needs those header files for its compilation. Contact
SCO|Caldera to get copies of those header files.
If you can't get the header files from SCO|Caldera, please
contact me via e-mail at <abe@purdue.edu>. Make sure "lsof"
appears in the "Subject:" line so my e-mail filter won't
classify your letter as Spam.
17.0 Sun Problems
17.0.5 Statement of deprecation
Lsof support for SunOS 4.1.x was last tested at revision 4.51.
Contact me via e-mail at <abe@purdue.edu> if you're interested in
obtaining it. Make sure "lsof" appears in the "Subject:" line so
my e-mail filter won't classify your letter as Spam.
17.1 My Sun gcc-compiled lsof doesn't work -- why?
Gcc can be used to build lsof successfully. However, an
improperly installed Sun gcc compiler will usually not
produce a working lsof.
If your Sun gcc-compiled lsof doesn't report anything, or
reports ``can't read proc table,'' or gcc refuses to compile
lsof without error, check that the gcc step that "fixes"
Sun header files was run on the system where you're using
gcc to compile lsof. As an alternative, if you have the
SunPro C 5.0 compiler or later available, use it to compile
lsof -- e.g., use the solariscc Configure abbreviations.
17.2 How can I make lsof compile with gcc under Solaris 2.[456],
2.5.1, 7, 8 or 9?
Presuming your gcc-specific header files are wrong for
Solaris, edit the lsof Configure-generated Makefile and
lib/Makefile and make this change:
CFGF= -Dsolaris=20400 ...
to
CFGF= -Dsolaris=20400 -D__STDC__=0 -I/usr/include ...
or change:
CFGF= -Dsolaris=20500 ...
to
CFGF= -Dsolaris=20500 -D__STDC__=0 -I/usr/include ...
or change:
CFGF= -Dsolaris=20501 ...
to
CFGF= -Dsolaris=20501 -D__STDC__=0 -I/usr/include ...
This is only a temporary work-around. You really should
instruct gcc to to update your gcc-specific header files
or install a recent gcc (e.g., 3.2), which has no need for
private copies of Solaris include files.
17.3 Why does Solaris Sun C complain about system header files?
You're probably trying to use /usr/ucb/cc if you get compiler
complaints like:
cc -O -Dsun -Dsolaris=20300 ...
"/usr/include/sys/machsig.h", line 81: macro BUS_OBJERR
redefines previous macro at "/usr/ucbinclude/sys/signal.h",
line 444
Note the reference to "/usr/ucbinclude/sys/signal.h". It
reveals that the BSD Compatibility Package C compiler is
in use. Lsof requires the ANSI C version of the Solaris
C compiler, usually found in /usr/opt/bin/cc or
/opt/SUNWspro/bin/cc.
Try adding a CC string to the lsof Makefile that points to
the Sun ANSI C version of the Sun C compiler -- e.g.,
CC= /usr/opt/bin/cc
or
CC= /opt/SUNWspro/bin/cc.
17.4 Why doesn't lsof work under my Solaris 2.4 system?
If lsof doesn't work under your Solaris 2.4 system -- e.g.,
it produces no output, little output, or the output is
missing command names or file descriptors -- you may have
a pair of conflicting Sun patches installed.
Solaris patch 101945-32 installs a kernel that was built
with a <sys/auxv.h> header file whose NUM_*_VECTORS
definitions don't match the ones in the <sys/auxv.h> updated
by Solaris patch 102303-02.
NUM_*_VECTORS in the kernel of patch 101945-32 are smaller
than the ones in the <sys/auxv.h> of patch 102303-02. The
consequence is that when lsof is compiled with the <sys/auxv.h>
whose NUM_*_VECTORS definitions are larger than the ones
used to compile the patched kernel, lsof's user structure
does not align with the one that the kernel employs.
If you have these two patches installed, contact Sun and
complain about the mis-match.
You may be able to work around the problem by editing
/usr/include/sys/auxv.h to have the following NUM_*_VECTORS
definitions:
#define NUM_GEN_VECTORS 4
#define NUM_SUN_VECTORS 8
The Configure script issues a prominent WARNING that you should
try the work-around.
I thank Leif Hedstrom for identifying the offending patches.
17.5 Where are the Solaris header files?
If you try to compile lsof under Solaris and get a compiler
complaint that it can't find system header files, perhaps
you forgot to add the header file package, SUNWhea.
17.6 Where is the Solaris /usr/src/uts/<architecture>/sys/machparam.h?
When you try to Configure lsof for Solaris 2.[23456], 2.5.1,
and 7 -- e.g., on a `uname -m` == sun4m system -- Configure
complains:
grep: /usr/src/uts/sun4m/sys/machparam.h:
No such file or directory
grep: /usr/src/uts/sun4m/sys/machparam.h:
No such file or directory
And when you try to compile the configured lsof, cc or gcc
complains:
dproc.c:530: `KERNELBASE' undeclared (first use this function)
The explanation is that somehow your Solaris system doesn't
have the header files in /usr/src/uts it should have. Perhaps
someone removed the directory to save space. Perhaps you're
using a gcc installation, copied from another system. In any
event, you will have to load the header files from the SUNWhea
package of your Solaris distribution.
KERNELBASE is an important symbol to lsof -- it keeps lsof
from sending an illegal kernel value to kvm_read() where
a segmentation violation might result (a bug in the kvm
library). Lsof can get illegal kernel values because it
reads kernel values slowly with kvm_read() calls that the
kernel is changing rapidly.
Lsof doesn't need KERNELBASE at Solaris 2.5 and above,
because it has a KERNELBASE value whose address lsof can
find with /dev/ksyms and whose value it can read with
kvm_read(). Under Solaris 2.5 /usr/src/uts has moved to
/usr/platform.
17.7 Why does Solaris lsof say ``can't read proc table''?
When lsof collects data on processes, using the kvm_*()
functions to scan the kernel's proc structure table, it
checks to make sure it has identified a reasonable number
of them -- a minimum of three. When lsof can't identify
three processes during a scan, it repeats the scan.
When five scans fail to yield three processes, lsof issues
the fatal message:
lsof: can't read proc table
and exits.
Usually lsof fails to identify three processes during a
scan because its idea of the form of the proc structure
differs from that being used by the kernel. Since the proc
structure is defined in <sys/proc.h> and other /usr/include
header files, the root cause of a proc structure discrepancy
usually can be found in the composition of /usr/include.
One common way that /usr/include header files can be
incorrect is that gcc was used to compile lsof, gcc used
its special (i.e., "fixed") header files instead of the
ones in /usr/include, and the special gcc header files
weren't updated when Solaris was. Answers to these questions:
My Sun gcc-compiled lsof doesn't work -- why?
How can I make lsof compile with gcc under Solaris 2.[456],
2.5.1, 7, 8 or 9?
Why does Solaris Sun C complain about system header files?
discuss the gcc header file problem and offer suggestions
on how to fix it or work around it.
It may also be that you are trying to run a version of lsof
that was compiled on an older version of Solaris. For
example, an lsof executable, compiled for Solaris 2.4, will
produce the ``can't read proc table'' message if you try
to run it under Solaris 2.5. If you have compiled lsof
under Solaris 2.5 and it still won't work, see if the header
files in /usr/include have been updated to 2.5, or still
represent a previous version of Solaris.
Another source of header file discrepancies to consider is
the Solaris patch level and whether a binary kernel patch
was not matched with a corresponding header file update.
See the "Why doesn't lsof work under my Solaris 2.4 system?"
question for an example of one in Solaris 2.4 -- there may
be other such patch conflicts I don't know about.
17.8 Why does Solaris lsof complain about a bad cached clone device?
When lsof revisions below 4.04 have been run on a Solaris
system and have been allowed to create a device cache file,
the running of revisions 4.04 and above on the same systems
may produce this complaint:
lsof: bad cached clone device: ...
lsof: WARNING: created device cache file: ...
This is the result of a change in the device cache file
that took place at lsof revision 4.04. The change introduced
a node number into the clone device lines of the device
cache file and was done in such a way that lsof could detect
device cache files whose clone lines don't have node numbers
(lines created by previous lsof revisions) and recognize
the need to regenerate the device cache file.
17.9 Why doesn't Solaris make generate .o files?
Solaris /usr/ccs/bin/make won't generate .o files from .c
files if /usr/share/lib/make/make.rules is missing. It
may be found in and installed from the SUNWsport package.
17.10 Why does lsof report some Solaris 2.3 and 2.4 lock types as `N'?
For Solaris 2.3 with patch P101318 installed at level 45
or above, and for all versions of Solaris 2.4, NFS locks
are represented by a NFS-specific kernel lock structure
that sometimes lacks a read or write lock type indicator.
When lsof encounters such a lock structure, it reports the
lock type as `N'.
17.11 Why does lsof Configure say "WARNING: no cc in ..."?
When lsof's Configure script is executed with the solariscc
abbreviation it tries to make sure it's using the Sun C
compiler and not the UCB substitute from /usr/ucb/cc.
Thus, it looks for cc in the "standard" Sun compiler
location, /opt/SUNWspro/bin.
If Configure can't find cc there, it issues the warning:
lsof: WARNING: no cc in /opt/SUNWspro/bin;
using cc without path.
and uses cc for the compiler name, letting the shell find
cc with its PATH environment variable.
You can tell Configure where to find your cc with the
SOLARIS_CCDIR cross-configuration environment variable.
(See 00XCONFIG for more information on SOLARIS_CCDIR).
For example, use this Configure shell command:
SOLARIS_CCDIR=/usr/special/bin Configure -n solariscc
(SOLARIS_CCDIR should be the full path to the directory
containing your cc.)
17.12 Solaris 7, 8 and 9 Problems
17.12.1 Why does lsof say the compiler isn't adequate for Solaris
7, 8 or 9?
Solaris 7, 8 and 9 kernels come in two flavors, 32 and 64
bit. 64 bit kernels run on machines that support the SPARC
v9 instruction set architecture. Separate executables for
some programs, -- e.g., ones using libkvm like lsof -- must
be built for 32 and 64 bit kernels.
Previous Sun (e.g., SC4.0) and earlier gcc compilers will
build lsof for 32 bit kernels, but they won't build it for
64 bit kernels. Compilers that will build lsof for 64 bit
Solaris 7, 8 and 9 kernels are the Sun WorkShop Compilers
C 5.0 and above, and recent gcc versions, e.g., 3.2.
When given the ``-xarch=v9'' flag, the C 5.0 compiler and
above, and associated loader and 64 bit libraries will
build a 64 bit lsof executable; when given the "-m64" or
"-mcpu=v9" (deprecated) flags, an appropriate gcc compiler
will build a 64 bit lsof executable.
When the lsof Configure script detects a 64 bit kernel is
in use (e.g., by executing `/bin/isainfo -kv`), and when
it finds that the specified compiler is inappropriate,
it complains with these messages:
For gcc:
"!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!"
"! !"
"! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT !"
"! THIS GCC DOESN'T SUPPORT THE BUILDING OF 64 BIT !"
"! SOLARIS EXECUTABLES. LSOF WILL BE CONFIGURED FOR A !"
"! 32 BIT echo KERNEL. !"
"! !"
"!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!"
For Sun C:
!!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!
! !
! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT |
! THE VERSION OF SUN C AVAILABLE DOESN'T SUPPORT THE !
! -xarch=v9 FLAG. LSOF WILL BE CONFIGURED FOR A 32 BIT !
! KERNEL. !
! !
!!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!
17.12.2 Why does Solaris 7, 8 or 9 lsof say "FATAL: lsof was compiled
for..."?
Solaris 7, 8 or 9 lsof may say:
lsof: FATAL: lsof was compiled for a xx bit kernel,
but this machine has booted a yy bit kernel.
Where: xx = 32 or 64
yy = 64 or 32
(xx and yy won't match.)
This message indicates that lsof was compiled for one size
kernel and is being asked to execute on a different size
one. That's not possible for programs like lsof that use
libkvm.
Depending on the instruction sets for which you need Solaris
7, 8 or 9 lsof, you may need two or more versions of lsof,
compiled for each kernel size, installed for use with
/usr/lib/isaexec. See the "How do I install lsof for
Solaris 7, 8 or 9?" section of this document for more
information on that.
17.12.3 How do I build lsof for a 64 bit Solaris kernel under a 32
bit Solaris kernel?
If your Solaris system has an appropriate compiler (e.g.,
WorkShop Compilers C 5.0 and above, or a recent gcc like
3.2) and the 64 bit libraries have been installed, you can
force lsof's Configure script to build a 64 bit version of
lsof with:
$ SOLARIS_KERNBITS=64 Configure -n solariscc
The SOLARIS_KERNBITS environment variable is part of the
lsof cross-configuration support, described in the 00XCONFIG
file of the lsof distribution.
17.12.4 How do I install lsof for Solaris 7, 8 or 9?
If you are installing lsof where it will be used only under
the bit size kernel for which it was built, no special
installation is required.
If, however, you are installing different versions of lsof
for different bit sizes -- e.g., for use on a 64 bit NFS
server and from its 32 bit clients -- you should read the
man page for isaexec(3C) and install lsof according to its
instructions.
The executable at the directory where lsof is to be found
should be a hard link to /usr/lib/isaexec or a copy of it.
In the directory there must be instruction architecture
subdirectories -- e.g., .../sparc/ and .../sparcv9/. The
lsof for 64 bit size kernels is installed in the .../sparcv9/
subdirectory; the one for 32 bit size kernels, in .../sparc/.
For example, if you're installing 32 and 64 bit lsof
executables in /usr/local/etc, you would:
# cd /usr/local/etc
# ln /usr/lib/isaexec lsof
# mkdir sparc sparcv9
# install the 32 bit lsof as sparc/lsof
# install the 64 bit lsof as sparcv9/lsof
# chmod, chown, and chgrp sparc/lsof and
sparcv9/lsof appropriately
Lsof permissions and ownerships are the same whether one
or more lsof executables are being installed, with or
without the /usr/lib/isaexec hard link.
17.12.5 Why does my Solaris 7, 8 or 9 system say it cannot execute
lsof?
When you attempt to execute lsof, your Solaris 7, 8 or 9
shell may complain:
ksh: ./lsof: cannot execute
If the lsof executable exists and has the proper execution
permissions, this error may be the result of trying to
execute an lsof, built for a 64 bit kernel, on a 32 bit
kernel.
This will tell you about the lsof executable:
$ file lsof
lsof: ELF 64-bit MSB executable SPARCV9 Version 1,
dynamically linked, not stripped
The "64-bit" notation indicates the binary was built for
a 64 bit kernel. To see the running kernel bit size, use
this command:
$ isainfo -kv
32-bit sparc kernel modules
The "32-bit" notation indicates a 32 bit kernel has been
booted.
The only work-around is to obtain, or Configure and make,
an lsof for the appropriate kernel bit size. If you
Configure and make lsof on the kernel where you wish to
run it the proper compiler, the lsof Configure step will
generate Makefiles that can be used with make to build an
appropriate lsof executable.
To compile a 64 bit lsof, you must have an appropriate
compiler -- i.e., Sun WorkShop Compilers C 5.0 or higher
or a recent gcc like 3.2.
17.12.6 What gcc will produce 64 bit Solaris 7, 8 and 9 executables?
8 and 9 executables?
Properly built and installed recent gcc versions -- e.g.,
3.2 -- will build lsof for 64 bit Solaris kernels.
If you update your gcc version to 3.2 or later, make sure
the private gcc header files become current -- i.e., clear
out any private header files from a previous gcc or Solaris
installation before installing the new ones, or build to
a new --prefix root and replace the old root with it after
the build and installation are complete.
17.12.7 Why does lsof on my Solaris 7, 8 or 9 system say, "can't
read namelist from /dev/ksyms?"
You're probably trying to use an lsof executable built for
an earlier Solaris release on a 64 bit Solaris 7, 8 or 9
kernel. The output from `lsof -v` will tell you the build
environment of your lsof executable. You should also have
gotten a warning message that lsof is compiled for a
different Solaris version than the one under which it is
running -- something like this:
lsof: WARNING: compiled for Solaris release X; this is Y
You need to build lsof on the system where you want to use
it. For 64 bit Solaris 7, 8 and 9 you need a compiler that
can generate 64 bit Solaris executables -- e.g., the Sun
Workshop 5 C compiler or later, or a recent gcc version
like 3.2. See the "Why does lsof say the compiler isn't
adequate for Solaris 7, 8 or 9?" section and the ones
following it for a discussion of building lsof for 64 bit
Solaris 7, 8 or 9.
17.13 Solaris and COMMON
17.13.1 What does COMMON mean in the NAME column for a Solaris VCHR
file?
When lsof puts COMMON or (COMMON) in the NAME column of a
Solaris VCHR file, it means that the file is handled by
the special file system functions of the kernel through a
common vnode.
17.13.2 Why does a COMMON Solaris VCHR file sometimes seem to have an
incorrect minor device number?
When lsof reports on an open file in a Solaris special file
system that uses a COMMON vnode, and the file is a VCHR
file, lsof tries to locate the associated device node by
looking for matches on the major and minor device numbers
first.
If no major and minor match results, lsof then looks for
a match on pseudo and clone device files. (See /devices/pseudo.)
Those device nodes are matched specially by either their
major or minor device numbers, but not both. Hence, when
lsof finds a match under those special conditions, it may
report a value in its output DEVICE column that differs
from one of the major and minor numbers of the device node.
Here's an example from a sun4m Solaris 7 system:
$ ls -li /devices/pseudo/pm@0:pm
151261 crw-rw-rw- 1 root sys 117, 0 ...
$ lsof /devices/pseudo/pm@0:pm
COMMAND ... DEVICE ... NODE NAME
powerd 117,1 ... 151261 /devices/pseudo/pm@0:pm (COMMON)
Xsun ... 117,0 ... 151261 /devices/pseudo/pm@0:pm
Note that the DEVICE value for the file with (COMMON) in
its name field has a different minor device number (1) from
what ls reports (0), while the DEVICE value for the file
without (COMMON) matches the ls output exactly. Both match
on the major device number, 117. The minor device number
mis-match is a result of the way the Solaris kernel handles
special file system common vnodes, and it's the reason lsof
puts (COMMON) after the name to signal that a mis-match is
possible.
17.14 Why don't lsof and Solaris pfiles reports always match?
/usr/proc/bin/pfiles for Solaris 2.6, 7, 8, and 9 also
reports information on open files for processes. Sometimes
the information it reports differs from what lsof reports.
There are several reasons why this might be true. First,
because pfiles is a Sun product, based on Sun kernel
features, its developers have a better chance of knowing
exactly how open file information is organized. I sometimes
have to guess at how kernel file structure linkages are
constructed by gleaning hints from header files.
Second, lsof is aimed at providing information, specifically
device and node numbers, that can be used to identify named
file system objects -- i.e., path names. Thus, lsof tries
to make sure its device and node numbers match those reported
by stat(2). Pfiles doesn't always report numbers that
match stat(2) -- e.g., for files using clone and pseudo
devices via common vnodes like the nlist() /dev/ksyms usage.
Here's the Solaris 7 COMMON VCHR example again with additional
pfiles output:
$ ls -li /devices/pseudo/pm@0:pm
151261 crw-rw-rw- 1 root sys 117, 0 ...
$ lsof /devices/pseudo/pm@0:pm
vic1: 10 = lsof /dev/pm
COMMAND ... DEVICE ... NODE NAME
powerd ... 117,1 ... 151261 /devices/pseudo/pm@0:pm (COMMON)
Xsun ... 117,0 ... 151261 /devices/pseudo/pm@0:pm
$ pfiles ...
0: S_IFCHR ... dev:32,24 ino:61945 ... rdev:117,1
...
14: S_IFCHR ... dev:32,24 ino:151261 ... rdev:117,0
Note that the NODE number, reported by lsof, matches what
ls(1) and stat(2) report, while the ino value pfiles reports
doesn't. Lsof also indicates with the (COMMON) notation
that the DEVICE number is a pseudo one, derived from the
character device's value. The lsof DEVICE value matches
the pfiles rdev value, correct behavior for a character
device, but pfiles gives no sign that it's not possible to
find that character device number in /devices with ls(1)
or stat(2).
17.15 Why does lsof say, "kvm_open(namelist=default, core=default):
Permission denied?"
Lsof needs permission to read from the /dev/kmem and /dev/mem
memory devices. Access to them is opened via a call to
the kvm_open() library function and it reports the indicated
message.
You must give lsof permission to read the memory devices.
The super user can almost always do that, but other lsof
users can do it if some group -- e.g., sys -- has permission
to read the memory devices, and the lsof binary is installed
with the group's ownership and with the setgid permission
bit enabled.
17.16 Why is lsof slow on my busy Solaris UFS file system?
Lsof may be slow on a busy Solaris UFS file system when
UFS logging has been enabled with the "logging" mount
option. That option can significantly increase disk
operations under certain conditions -- e.g., when a lot of
files are accessed quickly.
When only the "logging" option is specified to mount, all
file accesses (atime updates) are logged to the UFS logging
queue. Each atime update requires two writes to the disk
to complete it.
If you want to do UFS logging -- and there are reliability
advantages to it -- consider using the "logging,noatime"
mount options instead. That will shift atime updates from
the logging queue to fewer and independent asynchronous
operations, consequently making the UFS logging queue a
smaller bottleneck.
Consult mount_ufs(1M) for more information on the logging
and noatime options.
(My thanks to Casper Dik for this tip on improving the
performance of UFS logging.)
17.17 Why is lsof so slow on my Solaris 8 or 9 system?
Solaris 8 has a post-release feature upgrade modifying
kernel name cache (DNLC) handling that can slow lsof
throughput dramatically. The feature, sometimes called
negative DNLC caching, is standard in Solaris 9.
As best I can tell, when you install the Solaris 8 MU1
package, you get negative DNLC caching. If this pipe
produces any output, your system has negative DNLC caching.
$ nm /dev/ksyms | grep negative_cache_vnode
The reason negative DNLC caching perturbs lsof is that a
single vnode address (found in the negative_cache_vnode
kernel variable) is used to mark entries in the DNLC that
are not (the negative part) found on disk.
Since a single vnode address (the DNLC key lsof uses) can
represent many (I've seen upwards of 30,000.) DNLC entries,
their presence overloads lsof's internal DNLC hashing
function. An overloaded hash function is a slow hash
function, and lsof's slows to a crawl when it encounters
thousands of keys that produce the same value when the lsof
DNLC hash function is applied to them.
The solution is simple -- ignore negative DNLC cache keys.
They don't represent path name components lsof can use.
Lsof revisions 4.50 and above have an addition that ignores
them and the performance of those lsof revisions improves
significantly when presented with negative DNLC cache keys.
If you don't have an lsof revision at 4.51 or later, there's
a work-around. Use lsof's ``-C'' option. It disables
lsof's DNLC caching. Of course, that also inhibits the
reporting of any path name components from the kernel DNLC.
When ``-c'' is used, lsof will continue to report file
system and character device paths.
17.18 Solaris and VxFS
17.18.1 Why doesn't lsof support VxFS 3.4 on Solaris 2.6, and above?
Lsof will not support VxFS version 3.4 on Solaris 2.6 and above
unless some files from VxFS Update 2 have been installed. VxFS
3.4 FCS and VxFS 3.4 update 1 lack the header files lsof
normally uses to obtain information from the VxFS 3.4 kernel
node structure, vx_inode. VxFS 3.4 Update 2 provides a method
whereby lsof can obtain the necessary vx_inode information from
the vxfsu_get_ioffsets() function in Veritas utility
libraries.
The utility libraries (32 bit and 64 bit versions) may be
found in /opt/VRTSvxfs/lib. An ancillary header file may
be found in /opt/VRTSvxfs/include/sys/fs/vx_libutil.h.
Documentation of the vxfsu_get_ioffsets(3) function may be
found in /opt/VRTS/man/man3/vxfsu_get_ioffsets.3.
Those files of VxFS 3.4 Update 2 may be downloaded from:
ftp://ftp.veritas.com/pub/support/vxfs_34.i64243.tar
The vxfs_34.i64243.tar archive will unpack into an i64243
directory containing these files:
$ ls i64243
README
libvxfsutil.sol26.sums
libvxfsutil.sol26.tar.Z
libvxfsutil.sol27.sums
libvxfsutil.sol27.tar.Z
libvxfsutil.sol28.sums
libvxfsutil.sol28.tar.Z
Read README. Select the *.tar.Z file appropriate for your
Solaris version. Its contents will unpack into /opt/VRTS
and /opt/VRTSvxfs, so you will need sufficient permission
-- e.g., do it as root -- to unpack the uncompressed archive.
Once you've done that, it's a good idea to compare the
checksums of the archive you unpacked with the ones recorded
in the appropriate *.sums file. Use `sum -r` to verify
the checksums.
For example, if you want the Solaris 8 version, uncompress
and unpack libvxfsutil.sol28.tar.Z -- e.g.,
$ su
...
# cd i6423
# zcat libvxfsutil.sol28.tar.Z | tar xf -
That should create these new files and subdirectories with
the indicated checksums:
File or subdirectory sum -r
/opt/VRTSvxfs/include/vxfsutil.h 03938
/opt/VRTSvxfs/lib/libvxfsutil.a 51794
/opt/VRTSvxfs/lib/sparcv9/
/opt/VRTSvxfs/lib/sparcv9/libvxfsutil.a 07420
/opt/VRTS/man/man3/
/opt/VRTS/man/man3/vxfsu_get_ioffsets.3 62480
Once these files are in place, run lsof's Configure script
for the solaris or solariscc abbreviation. Configure will
locate the appropriate VxFS 3.4 Update 2 files and set up
for the making of an lsof that will properly display open
VxFS 3.4 file information.
17.18.2 Why does lsof report "vx_inode: vxfsu_get_ioffsets error"
for open Solaris 2.6 and above VxFS 3.4 and above files?
Even when lsof supports VxFS 3.4 and above on Solaris 2.6 and
above, it may report "vx_inode: vxfsu_get_ioffsets error" in
the NAME column for all VxFS files.
The usual cause is that lsof doesn't have permission to
read the file at the end of the /dev/vxportal symbolic
link. If, for example, lsof has been installed setgid(sys),
then the /dev/vxportal symbolic link destination should be
owned by the sys group and readable by it.
Update 2 for VxFS 3.4 sets the modes of the /dev/vxportal
symbolic link destination to 0640 and the group ownership
to sys. But I have had a report that the modes are wrong
in a VxFS 4.0 installation.
Another cause may be that the system has more than one version
of VxFS installed (Only one can be active.), and lsof's
Configure script did not choose the header files and libraries
for the active VxFS version. Configure opts for VxFS 4.0 and
above header files and libraries (in /opt/VRTS) in preference
to those for VxFS below 4.0 (in /opt/VRTSvxfs).
Look for the directories /opt/VRTS and /opt/VRTSvxfs. If you
have /opt/VRTS, make sure its header and library symbolic links
point to those of the active VxFS version.
If you have both directories, look at the CFLAGS that Configure
constructed for making lsof and see which directory path
follows a -I option. If that doesn't match the directory path
of the active VxFS version, try pointing Configure at the
correct directory with the SOLARIS_VXFSINCL environment
variable -- e.g.,
$ SOLARIS_VXFSINCL=/opt/.../include ./Configure -n solaris
17.18.3 Why does Solaris Configure claim there is no VxFS library?
The lsof Configure script, when configuring for Solaris, may
report:
FATAL: no VxFS .../libvxfsutil.a
That fatal error message indicates lsof has found the VxFS
utility library's header files, but can't find the library
itself in the expected location adjacent to the header files.
One possible cause is an incorrect symbolic link from
/opt/VRTS/lib/sparcv9/libvxfsutil.a to the library's real
location. (Some VxFS distributions declared the link
incorrectly.) Use `ls -lL` on that path to see if it exists.
If it doesn't exist, the link may be missing an additional
leading "../" component.
If the problem is a missing "../" from the library's link, you
can correct the link or check with Veritas/Symantec for the
patch that corrects it.
If the problem is not a missing "../", and you know the
libvxfsutil.a location, you can define its path in the
SOLARIS_VXFSLIB environment variable before running the lsof
Configure script. (See 00XCONFIG for information about using
the SOLARIS_VXFSLIB environment variable.)
If you have no libvxfsutil.a, you must obtain it from
Veritas/Symantec or find it in your VxFS installation package.
17.18.4 Why doesn't Solaris lsof report VxFS path name components?
Solaris lsof will report path name components for VxFS versions
that use the common Solaris Dynamic Name Lookup Cache (DNLC) or
on some file systems of VxFS versions that support the VxFS
Reverse Name Lookup (RNL) facility.
VxFS versions 3.3 (approximately) and below use the common
Solaris DNLC. (I haven't been able to determine exactly when
VxFS stopped using the DNLC.) For versions above that boundary,
but below 4.0, lsof can't report path name components.
At VxFS 4.0 and above, lsof can be compiled to use the VxFS RNL
facility for reporting path names. If "-DHASVXFSRNL" appears
in the compiler flags section of lsof "-v" option output, then
the lsof Configure script detected the VxFS RNL facility and
lsof has been compiled to use it.
Lsof's use of the RNL facility can fail when the VxFS file
system disk layout version is below 6. In that case, lsof can
report no path name components. For more information, see the
vxfs_inotopath(3) manual page. any of the following commands
will show the disk layout version for a VxFS file system, when
supplied the block device or mount point on which the file
system is mounted.
fstyp -v <block_device>
or
mkfs -m <block_device>
or
vxupgrade <mount_point>
You must have permission to read the block device -- e.g., be
the root user.
You may also be able to upgrade an older disk layout to one
that will work with the RNL. See the vxupgrade(1M) man page
for more information on that.
When lsof can't report VxFS path name components, it reports
the file system mount point and the path name of device on
which it is mounted. The device path name is enclosed in
parentheses.
17.18.5 Why does Solaris 10 lsof report scrambled VxFS paths?
Solaris 10 lsof may report a bogus, scrambled path for an open
VxFS file, when lsof obtains the path from a vnode's cached
path. Veritas/Symantec reports that their Solaris 10
implementation has bugs in the way it handles the Solaris 10
vnode cached path and those bugs will be fixed in an upcoming
patch some time after August 15, 2005.
When Solaris 10 lsof reports a path for an open VxFs file
obtained via the VxFS Reverse Name Lookup facility, the path
will be correct.
Also see the answers to the questions "Why does Solaris 10 lsof
sometimes report the wrong path name?" and "Why doesn't Solaris
lsof report VxFS path name components?"
17.19 Large file problems
17.19.1 Why does lsof complain it can't stat(2) a Solaris 2.5.1
large file?
When given an argument that is the path to a Solaris 2.5.1
file, enable for large file operations with the O_LARGEFILE
open(2) option, lsof complains that it can't stat(2) the
file. That's because lsof isn't using a stat(2) call and
associated structure enabled for large files.
This error has been fixed, starting at lsof revision 4.58
for Solaris 2.6 and above. That fix won't work on Solaris
2.5.1 and I no longer have access to a Solaris 2.5.1 test
system to develop a separate fix.
The work-around is to avoid specifying a O_LARGEFILE path
as an argument to lsof on Solaris 2.5.1. Instead use a
combination of lsof and grep to achieve the same results,
albeit more clumsily.
17.20 Why does lsof get a segmentation fault on 64 bit Solaris
8 using NIS+?
I have received a report from Gary Craig that lsof produces
a segmentation fault on his 64 bit Solaris 8 system using
NIS+. Via an independent test program we have exonerated
lsof and tracked the fault to the NIS+ __nis_server_name()
function in the C name server library, -lnsl.
Lsof causes the __nis_server_name() NIS+ function to be
called by calling getservent() to read entries of the port
number to service name map.
The only Sun bug ID that appears to describe the problem
is 4304244, although its text is unclear enough to leave
room for doubt.
Until Sun eliminates the __nis_server_name() segmentation
fault cause, a work-around for lsof is to use its "-P"
option, causing lsof to avoid port to service name lookups.
17.21 Will lsof crash the Solaris kernel?
I've received and investigated one report that it has when
the Sun hardware (a QME interface) was faulty. Today (May
23, 2002) I've learned that Sun has reports of kernel
crashes caused by adb, lsof, and mdb.
The Sun investigation pinpointed a problem in the /dev/kmem
kernel driver and there is a Sun bug report, 4344513, about
the problem. There is a fix in Solaris 9, and patches for
Solaris 7 and 8 (SPARC and x86).
To see if your Solaris system is fixed, look for a
/devices/pseudo/*allkmem node.
Extensive address filtering was added to lsof revision 4.50
to forestall what I then (July 2001) believed to be only
the possibility that lsof might crash Solaris. However,
the filtering isn't perfect, since a filtered address might
become invalid after lsof has filtered it but before lsof
has delivered it to /dev/kmem. That filtering work is
described in .../dialects/sun/solaris_kaddr_filters, also
available at:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/solaris_kaddr_filters
The best and safest work-around is to upgrade to Solaris
9 or install an appropriate patch or its equivalent from
this list:
Solaris SPARC x86
Version Patch Patch
======= ===== =====
7 106541-20 106542-20
8 108528-14 108529-14
17.22 Why does lsof on Solaris 7, 8, or 9 report a kvm_open()
failure?
When lsof is started on some Solaris 7, 8, and 9 systems
it may report:
lsof: kvm_open(namelist=default, corefile=default): \
No such file or directory
Lsof revisions 4.65 and later will first report:
lsof: cannot stat /dev/allkmem
The second message, not delivered in lsof revisions below
4.65, explains the cause of the kvm_open() failure; it
can't find /dev/allkmem.
/dev/allkmem is a device added to Solaris 7 and 8 in patches
and in the Solaris 9 FCS. See the preceding "Will lsof
crash the Solaris kernel?" section for more information on
/dev/allkmem and the patches.
The kvm_open(3KVM) function in the KVM library of patched
Solaris 7 and 8 systems and in Solaris 9 expects to find
/dev/allkmem and exits on error when it does not.
If you have installed the patch that updated your KVM
library to a version that expects /dev/allkmem to be present
and it is not, you may need to reconfigure your system's
devices with devfsadm(1M) or enter "boot -r" to the OpenBoot
monitor's prompt (usually "ok").
17.23 Solaris and SAM-FS
17.23.1 Why does Solaris lsof report "(limited SAM-FS info)"?
Lsof 4.68 and above report "(limited SAM-FS info)" on
Solaris in the NAME column after the path or file system
name for all files it finds on SAM-FS file systems.
That's because no more information is known about the
composition of the nodes that follow SAM-FS vnodes. If
you can provide that information, please contact me via
e-mail at <abe@purdue.edu>. Make sure "lsof" appears in the
"Subject:" line so my e-mail filter won't classify your letter
as Spam.
17.23.2 Why can't lsof locate named SAM-GS files?
Solaris lsof 4.68 and above can't locate files on SAM-FS
file systems when the files are named as lsof arguments
because lsof doesn't know how to locate open SAM-FS file
device and node number information. (See also 'Why does
Solaris lsof report "(limited SAM-FS info)?')
17.24 Lsof and Solaris 10 zones
17.24.1 How can I make lsof list the Solaris zone?
Use the lsof "-z [z]" option.
17.24.2 Why doesn't lsof work in a Solaris 10 zone?
When run from within a Solaris 10 zone, lsof will usually
report:
lsof: can't stat(/devices): No such file or directory
That's because a Solaris zone usually has no /devices
subdirectory, a restriction of the zone implementation intended
to limit the ability of zone processes to control global system
resources, including physical devices.
While a zone may have a /dev subdirectory, that subdirectory
usually lacks the /dev/allkmem, /dev/mem and /dev/kmem devices
lsof and the KVM library it uses require.
The work-around is to run lsof in the global zone. When it is
run in a global zone lsof will be able to report on processes
running in any zone, including the global zone.
17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file
systems?
When run from the global zone on Solaris 10 lsof may complain:
lsof: WARNING: can't stat() 15 zone file systems;
using dev= options
The warning message means lsof found the reported number of
file system entries in the mount table for which it didn't have
permission to get stat(2) results, but which had "zone=" and
"dev=" mount table options.
That is a normal restriction of Solaris 10 zones. Since the
lsof warning message indicates it was able to find "dev="
options for the file systems, lsof will probably work
correctly.
One work-around is to relax the restrictions on zone mount
points, so that lsof can stat() them. While that may be
possible by changing directory modes or group ownerships, it is
probably not a good idea, because it weakens the restrictions
zones are intended to provide.
Another work-around is to suppress the warning message with
lsof's "-w" option. The down side of that is that it causes
the suppression of all warning messages, leading to the
possibility that some non-stat() warning messages will be
suppressed.
17.25 Solaris 10 problems
17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name?
When a path name component is renamed -- e.g., with mv(1) --
Solaris 10 lsof may report the old component for an open file
that used the component in its path before the rename. That's
because Solaris 10 lsof reports the path name cached in the
open file's vnode and the Solaris 10 kernel doesn't update the
open vnode's cached path name when a component of it is changed.
When an open file is deleted -- e.g., with rm(1) -- the path
name by which it was opened remains cached in the vnode. Lsof
can be instructed to display that path name with the -X option.
The path name might be incorrect because of the rename problem
described above. See the answer to the 'What does "(deleted)"
mean in the NAME column of a Solaris 10 open file?' question
for more information.
Lsof is sometimes able to detect that cached path name is
incorrect. In that case lsof may report only the mounted-on
directory and device of the file system or it may report that
the path name is of questionable accuracy by appending a
trailing "(?)" to it in the NAME column.
See the answer to the "Why does Solaris 10 lsof sometimes
report only the mounted-on directory and device?" and 'What
does "(?)" mean in the NAME column of a Solaris 10 open file?'
questions for more information.
17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on
directory and device?
For some regular open files lsof may report only the mounted-on
directory and device of the file system on which the file
resides. That's because lsof was able to determine that the
path name cached in the open file's vnode is incorrect.
Lsof detects the cached path name is incorrect by applying
stat(2) to it, provided that no error was detected when stat(2)
was applied to the file system mounted-on directory during lsof
setup. If a mounted-on directory stat(2) error was detected
during setup, lsof does no cached path name analysis and simply
reports it.
When the application of stat(2) to the cached path name returns
a no-entry reply (the ENOENT error number), lsof concludes the
path no longer exists (i.e., has been unlinked) and reports the
mounted-on directory and device of the file system. That
behavior can be modified with the -X option in lsof revisions
4.77 and above. See the answer to the 'What does "(deleted)"
mean in the NAME column of a Solaris 10 open file?' for more
information.
When the application of stat(2) to the cached path name returns
a permission error reply (the EACCES or EPERM error numbers),
lsof reports the cached path name and adds a trailing "(?)" to
indicate the reported path name is of questionable accuracy.
See the answer to the question 'What does "(?)" mean in the
NAME column of a Solaris 10 open file?' for more information.
If the application of stat(2) to the cached path name yields
any other error reply, lsof reports the mounted-on directory
and device of the file system.
When the application of stat(2) to the cached path name
succeeds, lsof compares the reported device and node numbers to
what it has obtained for the open file from kernel structures.
If they match, lsof reports the cached path name. If they
don't match, lsof instead reports the mounted-on directory and
device of the file system.
A work-around that allows lsof to apply stat(2) successfully to
cached path names is to give lsof sufficient permission to do
it -- i.e., run lsof as the root user.
17.25.3 What does "(deleted)" mean in the NAME column of a Solaris 10
open file?
When the -X option is specified to Solaris 10 lsof, it will
report in its NAME column the path name cached for a deleted
file in its vnode. The path name will be followed by
"(deleted)".
Note that the path name cached in a file's vnode is the path
name by which the file was opened. It is not updated by the
Solaris kernel when any path name component is changed. Hence,
it may not represent the final path name the open file had.
See the answer to the "Why does Solaris 10 lsof sometimes
report the wrong path name?" question for more information on
how changing a path name component affects the correctness of a
what lsof reports.
17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open
file?
When lsof encounters a path name cached in the open file's
vnode that stat(2) reports lsof lacks permission to access,
lsof adds "(?)" to the path name reported in the NAME column to
indicate the path name is of questionable accuracy.
See the answers to the "Why does Solaris 10 lsof sometimes
report the wrong path name?" and "Why does Solaris 10 lsof
sometimes report only the mounted-on directory and device?"
questions for more information on why lsof may report a path
name of questionable accuracy.
A work-around that allows lsof to apply stat(2) successfully to
cached path names is to give lsof sufficient permission to do
it -- i.e., run lsof as the root user.
17.26 Solaris contract file problems
17.26.1 Why doesn't lsof report size, link count and node number for
Solaris 10 contract files?
Lsof doesn't report size, link count or node number for Solaris
10 contract files because I don't know how to obtain them from
contract file kernel structures.
17.26.2 Why can't lsof locate a Solaris 10 contract file by path name?
Because lsof can't find the node number of Solaris contract
files, it can't match the device and node numbers it gets from
applying stat(2) to the contract file path name with what it
finds in kernel data.
17.27 Solaris 10 and above ZFS probblems
17.27.1 Why does Configure warn that ZFS support is not enabled?
To provide ZFS support it is necessary that lsof have access to
the definitions of ZFS structures used by the kernel. Those
definitions are made available to lsof when it runs by the
libctl library.
If lsof's Configure script finds that ZFS is indicated by the
presence of the <sys/fs/zfs.h> header file, but the libctl
library is not indicated via the <libctl.h> header file, the
script concludes that ZFS support is not possible and issues
the following warning:
WARNING: ZFS support not enabled; libctf.h missing.
Install libctf support to remedy this problem.
17.28 Problems with Solaris 9 and above
17.28.1 Why does the compiler complain about lgrp_root on Solaris 9
and above?
When compiling lsof 4.84 on later Solaris 9 and 10 systems, the
compiler may report the following error:
/usr/include/sys/lgrp.h", line ...: identifier redeclared: lgrp_root
This error results from a conflict between usage of lgrp_root
in both <sys/lgrp.h> and <sys/lgrp_user.h> when _KMEMUSER or
_KERNEL is #define'd before <sys/lgrp.h> is #include'd. This
problem is noted in Sunsolve bug ID 5064229.
The work-around is to use lsof revision 4.85 sources.
18.0 Lsof Features
18.1 Why doesn't lsof doesn't report on /proc entries on my
system?
/proc file system support is generally available only for
BSD, SYSV R4 dialects, and Tru64 UNIX (Digital UNIX, DEC
OSF/1). It's also available for Linux, and Pyramid DC/OSx
and Reliant UNIX.
Even on some SYSV R4 dialects I encountered many problems
while trying to incorporate /proc file system support.
The chief problem is that some vendors don't distribute
the header file that describes the /proc file system node
-- usually called prdata.h.
18.2 How do I disable the device cache file feature or alter
it's behavior?
To disable the device cache file feature for a dialect,
remove the HASDCACHE definition from the machine.h file of
the dialect's machine.h header file. You can also use
HASDCACHE to change the default prefix (``.lsof'') of the
device cache file.
Be sure you consider disabling the device cache file feature
carefully. Having a device cache file significantly reduces
lsof startup overhead by eliminating a full scan of /dev
(or /devices) once the device cache file has been created.
That full scan also overloads the kernel's name cache with
the names of the /dev (or /devices) nodes, reducing the
opportunity for lsof to find path name components of open
files.
If you're worried about the presence of mode 0600 device
cache files in the home directories of the real user IDs
that execute lsof, consider these checks that lsof makes
on the file before using it:
1. To read the device cache file, lsof must gain
permission from access(2).
2. The device cache file's modes must be 0600 (0644
if lsof is reading a system-wide device cache file)
and its size non-zero.
3. There must be a correctly formatted section count
line at the beginning of the file.
4. Each section must have a header line with a count
that properly numbers the lines in the section.
Legal sections are device, clone, pseudo-device,
and CRC.
5. The lines of a section must have the proper format.
6. All lines are included in a 16 bit CRC, and it is
recorded in a non-checksummed section line at the
end of the file.
7. The checksum computed when the file is read must
match the checksum recorded when the file was
written.
8. The checksum section line must be followed by
end-of-information.
9. Lsof must be able to get matching results from
stat(2) on a randomly chosen entry of the device
section.
For more information on the device cache file, read the
00DCACHE file of the lsof distribution.
18.2.1 What's the risk with a perverted device cache file?
Even with the checks that lsof makes on the device cache
file, it's conceivable that an intruder could modify it so
it would pass lsof's tests.
The only serious consequence I know of this change is the
removal of a file whose major device number identifies a
socket from some user ID's device cache file. When such
a device has been removed from the device cache file, and
when lsof doesn't detect the removal, lsof may not be able
to identify socket files when executed by the affected user
ID. Only certain dialects are at risk to this attack --
e.g., SCO OpenServer and Solaris 2.x, 7, 8, and 9.
If you're tracking a network intruder with lsof, that could
be important to you. If you suspect that someone has
corrupted the device cache file you're using, I recommend
you use lsof's -Di option to tell it to ignore it and use
the contents of /dev (or /devices) instead; or remove the
device cache file (usually .lsof_hostname, where hostname
is the first component of the host's name returned by
gethostname(2)) from the user ID's home directory and let
lsof create a new one for you.
18.2.2 How do I put the full host name in a personal device cache file
path?
Lsof constructs the personal device cache file path name
from a format specified in the HASPERSDC #define in the
dialect's machine.h header file. As distributed HASPERSDC
declares the path to be ``.lsof_'' plus the first component
of the host name with the format ``.lsof_%L''.
If you want to change the way lsof constructs the personal
device cache file path name, you can change the HASPERSDC
#define and recompile lsof. If, for example, you #define
HASPERSDC to be ``.lsof_%l'' (note the lower case `l'),
Configure and remake lsof, then the personal device cache
file path will be ``.lsof_'' plus the host name returned
by gethostname(2).
See the 00DCACHE file of the lsof distribution for more
information on the formation of the personal device cache
file path and the use of the HASPERSDC #define.
18.2.3 How do I put the personal device cache file in /tmp?
Change the HASPERSDC definition in your dialect's machine.h
header file.
When you redefine HASPERSDC, make sure you put at least
one user identification conversion in it to keep separate
the device cache files for each user of lsof. Also give
some thought to including the ``%0'' conversion to define
an alternate path for setuid-root and root processes.
Here's a definition that puts a personal device cache file
in /tmp with the name ``.lsof_login_hostname_pers''.
#define HASPERSDC "/tmp/.lsof_%u_%l_pers"
Thus the /tmp personal device cache file path for login
"abe" on host "lsof.itap.purdue.edu" would be:
/tmp/.lsof_abe_lsof.itap.purdue.edu_pers
You can add the User ID (UID) with the "%U" conversion and
the first host name component with the ``%L'' conversion.
CAUTION: be careful using absolute paths like /tmp lest
lsof processes that are setuid-root or whose real UID is
root be used to exploit some security weakness via /tmp.
Elect instead to add an alternate path for those processes
with the ``%0'' conversion. Here's an extension of the
previous HASPERSDC format for /tmp that declares an alternate
path:
#define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L"
When the lsof process is setuid-root or its real UID is
root, presuming root's home directory is `/' and the host's
name is ``lsof.itap.purdue.edu'', the extended format yields:
/.lsof_vic
18.3 Why doesn't lsof know about AFS files on my favorite dialect?
Lsof currently supports AFS for these dialects:
AIX 4.1.4 (AFS 3.4a)
Linux 1.2.13 (AFS 3.3)
NEXTSTEP 3.2 (AFS 3.3)
Solaris 2.[56] (AFS 3.4a)
It may recognize AFS files on other versions of these
dialects, but I have no way to test that. Lsof may report
correct information for AFS files on other dialects, but
I can't test that either.
AFS support must be custom crafted for each UNIX dialect
and then tested. If lsof supports your favorite dialect,
but doesn't recognize its AFS files, probably I don't have
access to a test system. If you want AFS support badly
for your dialect, consider helping me do the development
and testing.
18.3.1 Why doesn't lsof report node numbers for all AFS volume files,
or how do I reveal dynamic module addresses to lsof?
When AFS is implemented via dynamic kernel modules -- e.g.,
in NEXTSTEP -- lsof can't obtain the addresses of AFS
variables in the kernel that it uses to identify AFS vnodes.
It can guess that a vnode is assigned to an AFS file and
it can obtain other information about AFS files, but it
has trouble computing AFS volume node numbers.
To determine node numbers for AFS volumes other than the
root volume, /afs, lsof needs access to a hashed volume
structure pointer table. When it can't find the address
of that table, because AFS support is implemented via
dynamic kernel modules, lsof will return blanks in the
INODE column for AFS volume files. Lsof can identify the
root volume's node number (0), and can compute the node
numbers for all other AFS files.
If you have a name list file that contains the addresses
of the AFS dynamic modules -- e.g., you saved module symbols
when you created a loadable module kernel with modload(8)
by specifying -sym -- lsof may be able to find the kernel
addresses it needs in that file.
Lsof looks up AFS dynamic kernel addresses for these dialects
at these default paths:
NEXTSTEP 3.2 /usr/vice/etc/afs_loadable
A different path to a name list file with AFS dynamic kernel
addresses may be specified with the -A option, when the -A
option description appears in lsof's -h or -? (help) output.
If any addresses appear in the -A name list file that also
appear in the regular kernel name list file -- e.g., /vmunix
-- they must match, or lsof will silently ignore the -A
addresses on the presumption that they are out of date.
SEA-GHOST - SHELL CODING BY SEA-GHOST