Project import
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..d52011e
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,119 @@
+#
+# Copyright (c) 2010-2011 Nest, Inc.
+# All rights reserved.
+#
+# This document is the property of Nest. It is considered
+# confidential and proprietary information.
+#
+# This document may not be reproduced or transmitted in any form,
+# in whole or in part, without the express written permission of
+# Nest.
+#
+# Description:
+# This file is the makefile for the "list open files" (lsof) utility.
+#
+
+BuildConfigSpecialized := No
+BuildProductSpecialized := No
+
+include pre.mak
+
+PackageName := lsof
+
+PackageExtension := tar.bz2
+PackageSeparator := _
+
+PackagePatchArgs := -g 0 -p2
+
+PackageArchive := $(PackageName).$(PackageExtension)
+PackageWrapperDir := $(PackageName)$(PackageSeparator)$(PackageVersion)
+
+PackageSourceArchive := $(PackageWrapperDir)/$(PackageName)$(PackageSeparator)$(PackageVersion)$(PackageSeparator)src.tar
+PackageSourceDir := $(PackageWrapperDir)/$(PackageName)$(PackageSeparator)$(PackageVersion)$(PackageSeparator)src
+
+PackageBuildMakefile = $(call GenerateBuildPaths,Configure)
+
+CleanPaths += $(PackageLicenseFile)
+
+all: $(PackageDefaultGoal)
+
+# Expand the wrapper directory which contains another archive
+# containing the source.
+
+$(PackageSourceArchive): $(PackageArchive)
+ $(call expand-archive,$(<),.)
+ $(Verbose)touch $(@)
+
+# Generate the package license contents.
+
+$(PackageSourceDir)/00README: source
+
+$(PackageLicenseFile): $(PackageSourceDir)/00README
+ $(Verbose)$(SED) -n -e '/^License$$/,/\*\/$$/{;p;/\*\/$$/q;}' < $< > $@
+
+# Extract the source from the archive and apply patches, if any.
+
+$(PackageSourceDir): $(PackageSourceArchive)
+ $(call expand-archive,$(<),$(PackageWrapperDir))
+ $(Verbose)touch $(@)
+ $(call patch-directory,$(@),$(PackagePatchArgs),$(PackagePatchPaths))
+
+# Prepare the sources.
+
+.PHONY: source
+source: | $(PackageSourceDir)
+
+# Patch the sources, if necessary.
+
+.PHONY: patch
+patch: source
+
+# Generate the package build makefile.
+
+$(PackageBuildMakefile): | $(PackageSourceDir) $(BuildDirectory)
+ $(call create-links,$(CURDIR)/$(PackageSourceDir),$(BuildDirectory))
+
+# Configure the source for building.
+
+.PHONY: configure
+configure: source $(PackageBuildMakefile)
+ $(Verbose)cd $(BuildDirectory) && \
+ LSOF_CC="$(CC)" \
+ LINUX_CLIB="-DGLIBCV=211" \
+ LSOF_INCLUDE="$(ToolIncDir)" \
+ LSOF_LINUX_INCL="$(call GenerateResultPaths,sw/tps/linux,include)" \
+ INSTALL="$(INSTALL) $(INSTALLFLAGS)" \
+ ./Configure \
+ -n \
+ $(TargetOS)
+
+# Build the source.
+#
+# We have to unset MAKEFLAGS since they confuse the package build otherwise.
+
+.PHONY: build
+build: configure
+ $(Verbose)unset MAKEFLAGS && \
+ $(MAKE) $(JOBSFLAG) -C $(BuildDirectory) \
+ CC="$(CC)" \
+ all
+
+# Stage the build to a temporary installation area.
+#
+# We have to unset MAKEFLAGS since they confuse the package build otherwise.
+
+.PHONY: stage
+stage: build | $(ResultDirectory)
+ $(Verbose)unset MAKEFLAGS && \
+ $(MAKE) $(JOBSFLAG) -C $(BuildDirectory) \
+ INSTALL="$(INSTALL) $(INSTALLFLAGS)" \
+ DESTDIR=$(ResultDirectory) \
+ install
+
+clean:
+ $(Verbose)$(RM) $(RMFLAGS) -r $(PackageSourceDir)
+ $(Verbose)$(RM) $(RMFLAGS) -r $(PackageWrapperDir)
+ $(Verbose)$(RM) $(RMFLAGS) -r $(BuildDirectory)
+ $(Verbose)$(RM) $(RMFLAGS) -r $(ResultDirectory)
+
+include post.mak
diff --git a/lsof.patches/lsof-50.description b/lsof.patches/lsof-50.description
new file mode 100644
index 0000000..178860a
--- /dev/null
+++ b/lsof.patches/lsof-50.description
@@ -0,0 +1 @@
+This patch ensures that strftime and localtime are assumed to be present in a cross-compiled environment where LINUX_CLIB has been specified.
diff --git a/lsof.patches/lsof-50.patch b/lsof.patches/lsof-50.patch
new file mode 100644
index 0000000..3b4edc4
--- /dev/null
+++ b/lsof.patches/lsof-50.patch
@@ -0,0 +1,14 @@
+diff -aruN a/lsof_4.85_src/Configure b/lsof_4.85_src/Configure
+--- a/lsof_4.85_src/Configure 2011-09-27 10:27:40.000000000 -0700
++++ b/lsof_4.85_src/Configure 2012-01-02 13:14:04.450661164 -0800
+@@ -5318,8 +5318,8 @@
+ $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1
+ if test -x ${LSOF_TMPC}.x # {
+ then
+- ./${LSOF_TMPC}.x
+- if test $? -eq 0 # }
++ ./${LSOF_TMPC}.x > /dev/null 2>&1
++ if test $? -eq 0 || test "X$LINUX_CLIB" != "X" # }
+ then
+ LSOF_CFGF="$LSOF_CFGF -DHAS_STRFTIME"
+ echo "present"
diff --git a/lsof.patches/lsof-51.description b/lsof.patches/lsof-51.description
new file mode 100644
index 0000000..7a3d3c5
--- /dev/null
+++ b/lsof.patches/lsof-51.description
@@ -0,0 +1 @@
+This patch adds a functional set of install commands.
diff --git a/lsof.patches/lsof-51.patch b/lsof.patches/lsof-51.patch
new file mode 100644
index 0000000..74d36f1
--- /dev/null
+++ b/lsof.patches/lsof-51.patch
@@ -0,0 +1,43 @@
+diff -aruN a/lsof_4.84_src/dialects/linux/Makefile b/lsof_4.84_src/dialects/linux/Makefile
+--- a/lsof_4.84_src/dialects/linux/Makefile 2008-04-15 06:30:04.000000000 -0700
++++ b/lsof_4.84_src/dialects/linux/Makefile 2010-09-08 12:07:58.000000000 -0700
+@@ -5,9 +5,9 @@
+
+ PROG= lsof
+
+-BIN= ${DESTDIR}
++BIN= ${DESTDIR}/usr/bin
+
+-DOC= ${DESTDIR}
++DOC= ${DESTDIR}/usr/share/man/man8
+
+ I=/usr/include
+ S=/usr/include/sys
+@@ -51,23 +51,10 @@
+ (cd lib; ${MAKE} -f Makefile.skel clean)
+
+ install: all FRC
+- @echo ''
+- @echo 'Please write your own install rule. Lsof should be installed'
+- @echo 'setuid to root if you wish any lsof user to be able to examine'
+- @echo 'all open files. Your install rule actions might look something'
+- @echo 'like this:'
+- @echo ''
+- @echo ' install -m 4xxx -o root -g $${GRP} $${PROG} $${BIN}'
+- @echo ' install -m 444 $${MAN} $${DOC}'
+- @echo ''
+- @echo 'You will have to complete the 4xxx modes, the GRP value, and'
+- @echo 'the skeletons for the BIN and DOC strings, given at the'
+- @echo 'beginning of this Makefile, e.g.,'
+- @echo ''
+- @echo ' BIN= $${DESTDIR}/usr/local/etc'
+- @echo ' DOC= $${DESTDIR}/usr/man/man8'
+- @echo ' GRP= sys'
+- @echo ''
++ mkdir -p ${BIN}
++ install ${PROG} ${BIN}
++ mkdir -p ${DOC}
++ install ${MAN} ${DOC}
+
+ ${LIB}: FRC
+ (cd lib; ${MAKE} DEBUG="${DEBUG}" CFGF="${CFGF}")
diff --git a/lsof.tar.bz2 b/lsof.tar.bz2
new file mode 100644
index 0000000..b7f32ad
--- /dev/null
+++ b/lsof.tar.bz2
Binary files differ
diff --git a/lsof.url b/lsof.url
new file mode 100644
index 0000000..ea4a69c
--- /dev/null
+++ b/lsof.url
@@ -0,0 +1 @@
+ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_4.85.tar.bz2
diff --git a/lsof.version b/lsof.version
new file mode 100644
index 0000000..12cf98e
--- /dev/null
+++ b/lsof.version
@@ -0,0 +1 @@
+4.85
diff --git a/lsof_4.85/00.README.FIRST_4.85 b/lsof_4.85/00.README.FIRST_4.85
new file mode 100644
index 0000000..f19e0d7
--- /dev/null
+++ b/lsof_4.85/00.README.FIRST_4.85
@@ -0,0 +1,29 @@
+A tour of the lsof_4.85 distribution:
+
+ 00.README.FIRST_4.85 is this file.
+
+ README.lsof_4.85 contains distribution and security information.
+
+ RELEASE.SUMMARY_4.85 contains a summary of the lsof 4.85
+ distribution.
+
+ lsof_4.85_src.tar is the lsof 4.85 source tar archive.
+
+ lsof_4.85_src.tar.sig is a detached GPG certificate for
+ lsof_4.85_src.tar.
+
+I suggest you follow these steps:
+
+1. Read 00.README.FIRST_4.85.
+
+2. Read README.lsof_4.85 and follow its instructions to verify
+ the authenticity of lsof_4.85_src.tar.
+
+3. Unpack lsof_4.85_src.tar -- use `tar xf lsof_4.85_src.tar`.
+ That will produce an lsof_4.85_src sub-directory.
+
+4. Change to the lsof_4.85_src sub-directory and read its
+ 00.README.FIRST file.
+
+Vic Abell <abe@purdue.edu>
+Tue Sep 27 14:06:28 EDT 2011
diff --git a/lsof_4.85/README.lsof_4.85 b/lsof_4.85/README.lsof_4.85
new file mode 100644
index 0000000..bbad47e
--- /dev/null
+++ b/lsof_4.85/README.lsof_4.85
@@ -0,0 +1,128 @@
+
+ Information About This Lsof Distribution
+
+
+What You Have
+=============
+
+If you got this far without being confused, then you are probably
+familiar with the construction of the lsof distribution or you have
+read RELEASE.SUMMARY_4.85. If either is the case, please skip to
+the Inventory section. If you haven't read RELEASE.SUMMARY_4.85,
+I suggest you do it now, because it explains how the lsof distribution
+is constructed and other useful things about lsof, including a
+summary of changes for the past few lsof revisions.
+
+Even though you may have thought you were getting lsof.tar.bz2,
+lsof.tar.gz or lsof.tar.Z with ftp, you really got lsof_4.85.tar.bz2,
+lsof_4.85.tar.gz or lsof_4.85.tar.Z. That's because the triplet of
+lsof.tar.* files are symbolic links to their longer-named counterparts.
+
+The bzip2'd, gzip'd or compressed tar files with lsof_, followed by a
+number, are wrapper archives, designed to package the lsof source
+archive, this file, other documentation files, and a GPG authentication
+certificate together.
+
+The number, 4.85, is the lsof revision number. When you bunzip2'd,
+gunzip'd or uncompressed lsof_4.85.tar.* and used tar to unpack
+lsof_4.85.tar, you got: 00.README.FIRST_4.85, describing the contents
+of lsof_4.85; README.lsof_4.85; lsof_4.85_src.tar; and
+lsof_4.85_src.tar.sig. All are identified with the revision number.
+You're reading README.lsof_4.85. lsof_4.85_src.tar.sig is a GPG
+certificate that authenticates the lsof source archive,
+lsof_4.85_src.tar.
+
+After you read the Inventory and Security sections, and hopefully
+after you check the GPG certificate, unpack the lsof_4.85_src.tar
+source archive and you will get a sub-directory, named lsof_4.85_src,
+that contains the lsof 4.85 source distribution.
+
+
+Inventory
+=========
+
+Once you have unpacked lsof_4.85_src.tar.tar, you can check
+lsof_4.85_src for completeness by changing to that sub-directory
+and running the Inventory script. The lsof_4.85_src/Configure
+script runs the Inventory script, too. The Configure script also
+calls a customization script, called Customize. You can direct
+Configure to avoid calling Inventory and Customize with the -n
+option.
+
+See the Distribution Contents section of the 00DIST file and The
+Inventory Script section of the 00README file for more information
+on the contents of the lsof distribution, and the Configure,
+Customize and Inventory scripts. The 00DIST and 00README files
+will be found in the lsof_4.85_src sub-directory you just created.
+
+
+Security
+========
+
+The md5 checksum for lsof_4.85_src.tar is:
+
+ MD5 (lsof_4.85_src.tar) = 93d972459bbae304951b438d63e03e64
+
+A good source for an MD5 checksum computation tool is the OpenSSL
+project whose work may be found at:
+
+ www.openssl.org
+
+You can use the openssl "dgst" operator to compute an MD5 checksum --
+e.g.,
+
+ $ openssl dgst -md5 lsof_4.85_src
+
+The old-style sum(1) checksum for lsof_4.85_src.tar (Please read
+the next paragraph if you don't get this value.) is:
+
+ 62553 8391 lsof_4.85/lsof_4.85_src.tar
+
+If your dialect's sum(1) program defaults to the new style algorithm
+(e.g., Solaris), you may have to use its -r option (or use the
+Solaris /usr/ucb/sum). If your Unix dialect doesn't have a sum(1)
+program (e.g., FreeBSD, or NetBSD), use its cksum(1) program with
+the -o1 option to get an old-style checksum. You may also need to
+ignore the block count, depending on the block size used on your
+your system (i.e., 512 or 1,024). The sum(1) that produced the
+above checksum considers block size to be 512; in contrast the BSD
+cksum(1) programs' -o1 option considers block size to be 1,024.
+
+lsof_4.85_src.tar.sig is a GPG certificate file, using my public
+key. My key may be available on some public key servers under the
+names:
+
+ Victor A. Abell <abe@cc.purdue.edu>
+ or
+ Victor A. Abell <abe@purdue.edu>
+
+You will also find it at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/Victor_A_Abell.gpg
+
+Get my key and install it in your public key ring.
+
+Once my key is installed, use this command to check the certificate
+of lsof_4.85_src.tar:
+
+ gpg --verify lsof_4.85_src.tar.sig lsof_4.85_src.tar
+
+If the certificate check isn't good, lsof_4.85_src.tar is suspect.
+Report the problem to me via e-mail at <abe@purdue.edu>.
+
+If you don't have GPG, you can compare the md5 checksum of
+lsof_4.85_src.tar to the value listed in this file. However, that
+is a less reliable authentication method, since it can't detect
+changes to both lsof_4.85_src.tar and the md5 checksum value listed
+in this tile.
+
+Other Security
+==============
+
+Signature information for the distribution file that contains
+this file may be found in the CHECKSUMS file that is located
+where the distribution file was found.
+
+
+Victor A. Abell <abe@purdue.edu>
+Tue Sep 27 14:06:26 EDT 2011
diff --git a/lsof_4.85/RELEASE.SUMMARY_4.85 b/lsof_4.85/RELEASE.SUMMARY_4.85
new file mode 100644
index 0000000..63c72fa
--- /dev/null
+++ b/lsof_4.85/RELEASE.SUMMARY_4.85
@@ -0,0 +1,333 @@
+ lsof (LiSt Open Files) version 4
+ (revision 4.85)
+
+
+ ********************************************************************
+ | The latest release of lsof is always available via anonymous ftp |
+ | from lsof.itap.purdue.edu. Look in pub/tools/unix/lsof. |
+ ********************************************************************
+
+******************************************************************************
+| CHECK THE PATCHES/ SUBDIRECTORY FOR FIXES TO THE LATEST LSOF DISTRIBUTION. |
+******************************************************************************
+
+ **************************************************************************
+ | AVOID USING PRE-BUILT LSOF BINARIES: SEE THE "PRE-BUILT LSOF BINARIES" |
+ | SECTION IN 00README FOR AN EXPLANATION. |
+ **************************************************************************
+
+ **********************************************************************
+ | READ 00LSOF-L FOR INFORMATION ON THE LSOF-L LISTSERV MAILING LIST. |
+ **********************************************************************
+
+ *********************************************************************
+ | CHECK 00FAQ BEFORE REPORTING BUGS TO <abe@purdue.edu>. |
+ | 00FAQ ALSO AT: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ |
+ *********************************************************************
+
+ ********************************************************************
+ | IMPORTANT! This README file explains how the lsof tar archive |
+ | is assembled -- it's a "wrapper" tar archive. Please read the |
+ | explanation of its naming and construction, immediately |
+ | following the initial list of supported dialects. |
+ ********************************************************************
+
+
+Lsof version 4 lists open files for running UNIX processes. It is a
+descendent of ofiles, fstat, and lsof versions 1, 2, and 3. It has
+been tested recently on these UNIX dialects.
+
+ AIX 5.3
+ Apple Darwin 9 and Mac OS X 10.[56]
+ FreeBSD 4.9 and 6.4 for x86-based systems
+ FreeBSD 8.[02] and 9.0 for AMD64-based systems
+ Linux 2.1.72 and above for x86-based systems
+ Solaris 9, 10 and 11
+
+Lsof 4 may work on other versions of these dialects, but hasn't been
+tested there recently. Lsof versions 2 and 3 are still available and
+may provide older dialect version support. See the notes on them in
+this file.
+
+The pub/tools/unix/lsof/contrib directory on lsof.itap.purdue.edu also
+contains information on other ports.
+
+Version 4 of lsof is distributed as bzip2'd, gzip'd and compressed tar
+archives in the files:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof.tar.bz2
+ and
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof.tar.gz
+ and
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof.tar.Z
+
+These files are links to the current distribution, whose name includes
+the revision number:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof_<rev>.tar.bz2
+ and
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof_<rev>.tar.gz
+ and
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof_<rev>.tar.Z
+
+<rev> is the revision number -- e.g., 4.85. These archives are called
+wrappers, because the lsof source tar archive, its GPG certificate
+(lsof_<rev>_src.tar.sig), and some documentation files are wrapped
+together inside them. (The GPG certificate authenticates the source
+tar archive.) A tar archive with: a ``.bz2'' suffix has been
+compressed with bzip2; ``.gz'', with gzip; and ``.Z'', with compress.
+
+When the wrapper tar is gunzip'd or uncompressed, and its tar archive
+contents are extracted, an lsof_4.85 subdirectory is created in the
+directory where the extraction was performed. The lsof_4.85
+subdirectory contains these files:
+
+ 00.README.FIRST contains introductory distribution
+ information.
+
+ README.lsof_4.85 contains instructions for the
+ security-conscious on how to be
+ sure that no one has tampered with
+ the distribution.
+
+ RELEASE_SUMMARY_4.85 is this file.
+
+ lsof_4.85_src.tar is a tar archive, containing the
+ lsof sources. When extracted with
+ tar it creates a subdirectory named
+ lsof_4.85_src in the directory
+ where the extraction was performed.
+ The lsof source files will be found
+ in lsof_4.85_src.
+
+ lsof_4.85_src.tar.sig is a GPG certificate, authenticating
+ the lsof_4.85_src.tar archive. See the
+ README.lsof_4.85 file for more
+ information on GPG authentication of
+ lsof_4.85_src.tar.
+
+If you've obtained this file and an lsof distribution from a mirror
+site, please be aware that THE LATEST VERSION OF LSOF IS AVAILABLE VIA
+ANONYMOUS FTP FROM LSOF.ITAP.PURDUE.EDU IN THE PUB/TOOLS/UNIX/LSOF
+DIRECTORY.
+
+Patches to lsof distributions may be found in the patches/ sub-
+directory where you found lsof.tar.bz2, lsof.tar.gz or lsof.tar.Z.
+If there are any patches to the current distribution, they will be
+found in the patches/4.85/ branch.
+
+(If you need a copy of gunzip, look for it at prep.ai.mit.edu in
+pub/gnu/gzip*.)
+
+* The September 27, 2011 revision (4.85): adds an automatic work-around for
+ an lgrp_root conflict in some Solaris 9 and 10 versions; supports FreeBSD
+ 7.4 and 8.[12] (8.1 not tested); adds fixes for Solaris 11 kernel module
+ path determination; picked lint for Linux; added more Linux cross
+ configuration support; adds support for Mac OS X 10.6; tested on FreeBSD
+ 6.4; adapts to FreeBSD ZFS update; drops support for FreeBSD 7.x; adjusts
+ for Solaris 10 with patch 144488-10; added Linux +|-e option support;
+ adjusts for a FreeBSD 9 change; fixes a Linux AF_UNIX path reporting bug;
+ adjusts for dropping of RPC headers from Linux GlibC 2.14; adds Linux
+ Netlink protocol support; corrects UDP6-lite Linux path.
+
+
+Read the 00.README.FIRST in the lsof distribution first.
+
+Read the 00DIST distribution file for more details on feature additions
+and bug fixes.
+
+The 00README distribution file has build instructions, dialect
+descriptions, special feature discussions, and installation hints.
+
+The 00FAQ file contains a list of frequently asked questions and their
+answers.
+
+The 00DCACHE file explains device cache file path formation.
+
+The 00PORTING file contains information on porting lsof to other UNIX
+dialects.
+
+The 00QUICKSTART file gives a quick introduction to using lsof.
+
+The distribution files lsof.8 (nroff source) and lsof.man (nroff
+formatted output) contain the manual page for lsof; it is the only
+other documentation besides the source code (it's included).
+
+
+Version 4 Binaries
+==================
+
+Version 4 binaries for some revisions, dialects, and platforms may be
+found in pub/tools/unix/lsof/binaries. Check the README files for
+exact descriptions. Check the dialect-specific Makefiles for
+installation instructions. CHECKSUMS and GPG certificates are provided
+for authentication.
+
+Please think very carefully before you decide to use a pre-built binary
+instead of making your own from the sources. Here are some points to
+consider:
+
+1. Lsof must run setgid or setuid. Are you willing to trust that
+ power to a binary you didn't construct yourself?
+
+2. Lsof binaries may be generated on a system whose configuration
+ header files differ from yours. Under Digital UNIX (DEC OSF/1), for
+ example, lsof includes header files from the machine's configuration
+ directory, /sys/<name>. Are you willing to gamble that your
+ configuration directory's header files match the ones used to
+ compile lsof?
+
+3. Lsof is often configured with specific options that are determined
+ from the configuration of the system on which it is configured --
+ e.g., Solaris patch level, dynamic loader libraries, etc. Are you
+ sure that the lsof binary you retrieve will have been configured for
+ your system? If you get a binary that is misconfigured for you, it
+ may not work at all.
+
+If you haven't already guessed, I believe firmly that you should
+retrieve sources and build your own binary. If you still want to use
+the distribution binaries, please authenticate what you retrieved with
+the GPG certificates; please compare checksums, too.
+
+
+Version 4 Checksums
+===================
+
+Security checksums -- both MD5 and sum(1) -- for revisions of lsof
+version 4 are contained in the README.lsof_<rev> files in the wrapper
+tar archives of pub/tools/unix/lsof.
+
+The CHECKSUMS file, found with the distribution archives, contains
+information on validating the archives with external MD5 checksums and
+external GPG certificates.
+
+
+GPG Certificates
+================
+
+The lsof wrapper tar archive includes a GPG certificate file in its
+contained lsof_4.71_src.tar.sig file.
+
+Binary files have detached GPG certificates that may be found in their
+directories with ".sig" extensions.
+
+The certificates are signed with my GPG public key, which may be found
+in the file:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/Victor_A_Abell.gpg
+
+My key may also be available at some public key servers,
+
+There is also authentication information in the CHECKSUMS file (a link
+to CHECKSUMS_<rev>), found with the lsof distribution files. CHECKSUMS
+contains external MD5 checksums for the distribution files and
+information on using the external GPG certificates, found with the lsof
+distribution files.
+
+
+Old Dialect Support
+===================
+
+Remnants of source code and binaries for dialects for which lsof once
+provided support may be obtained by request. Send the request to
+abe@purdue.edu.
+
+Dialects no longer supported include:
+
+ CDC EP/IX
+ MIPS RISC/os
+ Motorola V/88
+ Pyramid DC/OSx
+ Pyramid Reliant UNIX
+ Sequent DYNIX
+ SGI IRIX
+ SunOS 4.1.x
+ Ultrix
+
+Generally I drop support for a dialect when I no longer have access to
+a test system.
+
+
+Lsof Version 2
+==============
+
+The version 3 predecessor, revision 36 of version 2, is also available
+upon request. Send the request to abe@purdue.edu.
+
+I recommend you avoid lsof version 2. It's out of date and I no
+longer provide support for it. (Versions 3 and 4 support more
+dialects, and have many enhancements, bug fixes, and improvements.)
+Version 2 was tested on the following UNIX dialects:
+
+ AIX 3.2.[1234] for the IBM RISC/System 6000
+ DEC OSF/1 1.[23] and 2.0 for the DEC Alpha
+ EP/IX 1.4.3 and 2.1.1 for the CDC 4680
+ ETAV 1.17 for the ETA-10P*
+ FreeBSD 1.0e for x86-based systems
+ HP-UX [789].x for HP systems
+ IRIX 4.0.5 and 5.1.1 for SGI systems
+ NEXTSTEP 2.1, 3.0, 3.1 for NeXT systems
+ Sequent Dynix 3.0.12 for Sequent Symmetry systems
+ SunOS 4.1.[123] for Sun 3 and 4 systems
+ SunOS 5.[13] (Solaris 2.[13]) for Sun 4 systems
+ Ultrix 2.2 and 4.2 for DEC systems
+
+(If you need a copy of gunzip, look for it at prep.ai.mit.edu in
+pub/gnu.)
+
+
+Version 2 Checksums
+===================
+
+MD5:
+ (OLD/lsof236tar.gz) = f8a1ab3971ea2f6a3ea16752f84409e8
+
+sum(1):
+ 39996 106 OLD/lsof236tar.gz
+
+The file OLD/lsof236tar.gz.asc is a detached PGP certificate that may
+be used to authenticate OLD/lsof236tar.gz with my PGP public key. You
+may find my PGP public key at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/Victor_A_Abell.pgp
+
+
+Lsof Version 3
+==============
+
+The last revision of lsof version 3, 3.88, may obtained by request.
+Send the request to abe@purdue.edu.
+
+I recommend version 4 over version 3. It is the version I actively
+support.
+
+Lsof version 3 was tested on these UNIX dialects:
+
+ AIX 3.2.5, 4.1[.[1234]], and 4.2
+ BSDI BSD/OS 2.0, 2.0.1, and 2.1 for x86-based systems
+ DC/OSx 1.1 for Pyramid systems
+ Digital UNIX (DEC OSF/1) 2.0, 3.0, 3.2, and 4.0
+ EP/IX 2.1.1 for the CDC 4680
+ FreeBSD 1.1.5.1, 2.0, 2.0.5, 2.1, 2.1.5 for x86-based
+ systems
+ HP-UX 8.x, 9.x, 10.01, 10.10, and 10.20
+ IRIX 5.2, 5.3, 6.0, 6.0.1, and 6.[124]
+ Linux 2.0.3[01] and 2.1.57 for x86-based systems
+ NetBSD 1.0, 1.1, and 1.2 for x86 and SPARC-based
+ systems
+ NEXTSTEP 2.1 and 3.[0123] for NEXTSTEP architectures
+ OpenBSD 1.2 and 2.0 for x86-based systems
+ Reliant UNIX 5.43 for Pyramid systems
+ RISC/os 4.52 for MIPS R2000-based systems
+ SCO OpenServer 1.1, 3.0, and 5.0.[024] for x86-based
+ systems
+ SCO UnixWare 2.1 and 2.1.1 for x86-based systems
+ Sequent PTX 2.1.[1569], 4.0.[23], 4.1.[024], 4.2[.1],
+ and 4.3
+ Solaris 2.[12345], 2.5.1, and 2.6-Beta
+ SunOS 4.1.x
+ Ultrix 4.2, 4.3, 4.4, and 4.5
+
+
+Vic Abell <abe@purdue.edu>
+September 27, 2011
diff --git a/lsof_4.85/lsof_4.85_src.tar b/lsof_4.85/lsof_4.85_src.tar
new file mode 100644
index 0000000..c4b47fc
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src.tar
Binary files differ
diff --git a/lsof_4.85/lsof_4.85_src.tar.sig b/lsof_4.85/lsof_4.85_src.tar.sig
new file mode 100644
index 0000000..2b6667e
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src.tar.sig
Binary files differ
diff --git a/lsof_4.85/lsof_4.85_src/00.README.FIRST b/lsof_4.85/lsof_4.85_src/00.README.FIRST
new file mode 100644
index 0000000..17c8d70
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00.README.FIRST
@@ -0,0 +1,47 @@
+Now that you have the lsof distribution, I suggest:
+
+* If you're unfamiliar with lsof, read 00README for information on
+ Configuring and building lsof, 00QUICKSTART for tips on using lsof.
+
+ If you're too impatient for that, do this:
+
+ $ ./Configure <put your UNIX dialect's abbreviation here>
+ (Do the inventory step, as you prefer.)
+ (Do the customization step, as you prefer.)
+ $ make
+ $ ./lsof -h
+
+ To get a list of UNIX dialect abbreviations:
+
+ $ Configure -h
+
+ Please don't be impatient -- read the documentation first.
+
+* Read the current distribution's details in 00DIST.
+
+* If you want technical details, read 00DCACHE and 00PORTING.
+
+* If you want to cross-configure, read 00XCONFIG.
+
+* Use the test suite, described in 00TEST, by:
+
+ $ cd tests
+ $ make
+
+ and possibly:
+
+ $ make opt
+
+* If you're having trouble, read 00FAQ. (Please read 00FAQ before
+ you send a bug report.)
+
+* Lsof contributors may find their names in 00CREDITS. (Thanks, again.)
+
+* Read the lsof.man page file. Its nroff source is in lsof.8.
+
+* Consider subscribing to the lsof-l mailing list -- read 00LSOF-L
+ for details.
+
+
+Vic Abell <abe@purdue.edu>
+April 19, 2002
diff --git a/lsof_4.85/lsof_4.85_src/00CREDITS b/lsof_4.85/lsof_4.85_src/00CREDITS
new file mode 100644
index 0000000..bf9dbc7
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00CREDITS
@@ -0,0 +1,529 @@
+
+ Lsof Credits
+
+I owe an enormous debt to the users of lsof who have contributed
+to its steady growth. The size of the list of people who have
+helped me, while it has grown too large to include in the lsof man
+page any more, is a testimonial to their generosity.
+
+First I acknowledge a debt to the work of Dan Bernstein, Michael
+``Ford'' Ditto, Tom Dunigan, Alexander Dupuy, Vik Lall, Ray Moody,
+C. Spencer, Michael Spitzer and those who wrote Berkeley's fstat
+program, all contributors to lsof's predecessors.
+
+I thank Doug McKenzie for his HP-UX proctor program and Rich Kulawiec
+for pointing it out.
+
+Finally I thank all the following people who have used lsof, pointed
+out its flaws, described its shortcomings, offered suggestions for
+improving it, supplied code for it, gave me technical advice, and
+provided test systems where I was able to do development work.
+
+ Szilveszter Adam
+ David Addison
+ Elias Halldor Agustsson
+ Per Allansson
+ Jim Ankenbrandt
+ Richard Allen
+ Thomas Anders
+ Ric Anderson
+ Stuart Anderson
+ Michael Antlitz
+ Marc Auslander
+ Tigran Aivazian
+ Jos Backus
+ David Bacon
+ Alexis Ballier
+ Scott Ballew
+ Ade Barkah
+ Alon Bar-Lev
+ Brett Bartick
+ Anthony Baxter
+ John Beacom
+ Bruce Beare
+ M. Jay Beck
+ Marek Behun
+ Bill Behr
+ Michael Beirne
+ Marc Bejarano
+ Andrew Bell
+ Steve Bellenot
+ Robert Benites
+ Dmitry Berezin
+ Ulrich Bernhard
+ Peter J. Bertoncini
+ Dave Bianchi
+ Mark Bixby
+ Allan Black
+ Jan Blunck
+ Achim Bohnet
+ Steve Bonds
+ Mark Bonsack
+ Volker Borchert
+ Bill Bormann
+ Ermin Borovac
+ Heddy Boubaker
+ Pieter Bowman
+ Michael Bracewell
+ H. Merijn Brand
+ Danny Braniss
+ Thomas Braunbeck
+ Kieran Broadfoot
+ Dean Brock
+ Hal Brooks
+ Andrew Brown
+ Jim Brown
+ Michael Bryan
+ Matthew Burt
+ Robert Byrnes
+ Pierfrancesco Caci
+ Bill Campbell
+ David Capshaw
+ John Caruso
+ Jon Champlin
+ Kris Chandrasekhar
+ Albert Chin-A-Young
+ Bernt Christandl
+ Marc Christensen
+ Hans Petter Christiansen
+ Tom Christiansen
+ Yves Christophe
+ Richard Chycoski
+ A. Channing Clark
+ Axel Clauberg
+ John Clear
+ David Clissold
+ Richard Coley
+ John Colgrave
+ David Comay
+ Lionel Cons
+ Bob Cook
+ Patrick Connor
+ Carl Cook
+ Jim Cooper
+ Roger Cornelius
+ Doug Crabill
+ Eric Cronin
+ Kim Culhan
+ Dave Curry
+ Robert Dahlem
+ Guy Dallaire
+ D. Chris Daniels
+ Renata Maria Dart
+ Ian Darwin
+ Carl E. Davidson
+ David Day
+ Will Day
+ Frederic Delanoy
+ Mike Depot
+ Steve Dibbell
+ Hugh Dickins
+ David DiGiacomo
+ Casper Dik
+ John DiMarco
+ Don Draper
+ Michel Dubois
+ Eric Dumazet
+ Dick Dunbar
+ Marc Duponcheel
+ Jan Dvorak
+ Calle Dybedahl
+ John Dzubera
+ Jeff Earickson
+ Greg Earle
+ Bernd Eckenfels
+ Niklas Edmundsson
+ Philip Edwards
+ Robert Ehrlich
+ Mark W. Eichin
+ Doug Eldred
+ Scott Ellentuch
+ Tom Endo
+ Grant Erickson
+ Craig Everhart
+ Chris Evert
+ Bob Farmer
+ Sami Farin
+ Mike Feldman
+ Quentin Fennessy
+ Ian Fitchet
+ Toralf Foerster
+ Bob Foertsch
+ Pierre-Yves Fontaniere
+ Ralph Forsythe
+ Jason Fortezzo
+ Mike Fraser
+ Curt Freeland
+ Terry Friedrichsen
+ Mike Frysinger
+ Harvey Garner
+ Carson Gaspar
+ Stuart D. Gathman
+ Brian L. Gentry
+ Dave Gilbert
+ Steve Ginsberg
+ Edwin Groothuis
+ Jin Guojun
+ Kurt Gollhardt
+ Roman Gollent
+ Steve Gonczi
+ Bill Goodridge
+ Julian Gordon
+ Marcin Gozdalik
+ Henry Grebler
+ Richard Green
+ Chaskiel Grundman
+ Armin Gruner
+ David Gutierrez
+ Robert Hall
+ Garner Halloran
+ Adam Hammer
+ Charles Hannum
+ Vlad Harchev
+ Craig Harmer
+ Michael Haro
+ Peter Harvey
+ Steinar Haug
+ Sheldon Hearn
+ John Heasley
+ Wolfgang Hecht
+ Janet Hempstead
+ Michael Hennecke
+ Randolph J. Herber
+ Andrew Hill
+ Kurt Hillig
+ Steven Hinkle
+ Paul Hite
+ Billy Ho
+ Michael Hocke
+ Brett Hogden
+ Gaylord Holder
+ Kjetil Torgrim Homme
+ Pekka Honkanen
+ Jeffrey C. Honig
+ Heidi Hornstein
+ Michael A. Hovan III
+ Barbara Howe
+ J. Nelson Howell
+ Jeff Howie
+ Louis Huemiller
+ John Hughes
+ Gerrit Huizenga
+ Peter Ilieve
+ Mayer Ilovitz
+ Gregory A. Ivanov
+ John Jackson
+ Kurt Jaeger
+ Edward Jajko
+ Marian Jancar
+ Paul Jarc
+ Jakub Jelinek
+ Robert Jelinek
+ Bruce Jerrick
+ Carl Johnson
+ Dion Johnson
+ Jeff Johnson
+ Douglas B. Jones
+ LaMont Jones
+ Peter Jordan
+ Arne H. Juul
+ Pasi Kaara
+ Frank Kaefer
+ Keith Kalet
+ Claus Kalle
+ Henri Karrenbeld
+ Amir Katz
+ Henry Katz
+ Kawaljeet Kaur
+ Doug Kehn
+ Kris Kennaway
+ Terry Kennedy
+ Shane Kenney
+ Andrew Kephart
+ Robert Kiessling
+ Joshua Kinard
+ Don Kirouac
+ Steve Kirsch
+ Philip Kizer
+ Thomas Klausner
+ Roger Klorese
+ Peter Klosky
+ Przemek Klosowski
+ Angelos D. Keromytis
+ Radko Keves
+ Valdis Kletnieks
+ Chris Kordish
+ Alek O. Komarnitsky
+ Joseph Kowalski
+ Christian Krackowizer
+ Paul Kranenburg
+ Troyan Krastev
+ Brad Krebs
+ Alex Kreis
+ Johannes Kroeger
+ Vincent Kujala
+ Ken Laing
+ Shirley Lam
+ Erwin Lansing
+ Victoria H. Lau
+ Markus Lautenbacher
+ Steve Lacey
+ Marc Aurele La France
+ Chad R. Larson
+ Steve Laubscher
+ Andrei V. Lavreniyuk
+ Loc Le
+ Tin Le
+ Diane Lebel
+ Francis Le Bourse
+ Kyungjoon Lee
+ Marty Leisner
+ Maciej Lesniewski
+ Stuart Levy
+ Ben Lewis
+ Michael Lewis
+ Angel Li
+ Ambrose Li
+ Wendy Lin
+ Carl E. Lindberg
+ Onno van der Linden
+ Johan Lindquist
+ James Lingard
+ Jason Lingohr
+ Robert Lipe
+ Gabor Liptak
+ Friedel Loinger
+ Michael Long
+ Pete Lord
+ Steve Logue
+ Bela Lubkin
+ Pav Lucistnik
+ Horst Luehrsen
+ Andreas Luik
+ Timothy J. Luoma
+ Michael Mackenzie
+ Lawrence MacIntyre
+ Jerome Marchand
+ Benson Margulies
+ Claude Marinier
+ Chris Markle
+ Roy Marples
+ Eberhard Mater
+ James Mathiesen
+ Tom Matthews
+ Fletcher Mattox
+ David Mazieres
+ Brian McAllister
+ Scott McClung
+ Dale McCluskey
+ Terry McCoy
+ Sean McDermott
+ Duncan McEwan
+ Dwight McKay
+ William McVey
+ Eric McWhorter
+ Marjo F. Mercado
+ Dan Mercer
+ Bill Melvin
+ Andrew Merril
+ Richard van Meurs
+ Jim Mewes
+ Gary Millen
+ Timothy Miller
+ Davin Milun
+ Yuliy Minchev
+ Jim Mintha
+ Mike Miscevic
+ Arkadiusz Miskiewicz
+ Janardhan Molumuri
+ Nasser Momtaheni
+ Laurent Montaron
+ Phillip Moore
+ Dmitry Morozovsky
+ John Paul Morrison
+ John Gardiner Myers
+ Jeffrey Mogul
+ Dave Morrison
+ Pat Myrto
+ Toshiya Nakamura
+ Filippo Natali
+ Allan Nathanson
+ Chance Neale
+ Dan Nelson
+ Vladislav Nespor
+ Bjorn S. Nilsson
+ Anders Nordby
+ Joseph J. Nuspl Jr.
+ David O'Brien
+ Alexandre Oliva
+ Craig B. Olofson
+ Dave Olson
+ Rainer Orth
+ Sergey A. Osokin
+ Keith Parks
+ Will Partain
+ Vasco Pedro
+ Mark Peek
+ Ezra Peisach
+ Bill Pemberton
+ Lee Penn
+ Gildas Perrot
+ Jesse Perry
+ Nathan Peterson
+ Dominique Petitpierre
+ Hung Pham
+ Ray Phillips
+ Francois Pinard
+ Alex Podlecki
+ Lutz Poetschulat,
+ John Polstra
+ Scott Presnell
+ Mark Price
+ Philippe-Andre Prindeville
+ David Putz
+ Tom Qin
+ Kurtis Rader
+ Peter Radig
+ Jean-Pierre Radley
+ Tim Ramsey
+ Dewan Rashid
+ Richard J. Rauenzahn
+ Louis Rayman
+ Brian Redman
+ Eric S. Raymond
+ Erwin Reyns
+ Aaron Rhodes
+ Jim Reid
+ Jean-Luc Richier
+ Ingimar Robertson
+ Sylvain Robitaille
+ Larry Rogers
+ Malgorzata Roos
+ Larry Rosenman
+ Stephan Rossi
+ Kevin Ruderman
+ Wolfgang Rupprecht
+ Pavol Rusnak
+ Conrad J. Sabatier
+ Klaus Saggerer
+ Chris Schanzle
+ Igor Schein
+ Horst Scheuermann
+ Peter Schiffer
+ Michael Schmitz
+ Larry Schwimmer
+ Hendrik G. Seliger
+ Igor V. Semenyuk
+ Jonathan Sergent
+ Frank Sanders
+ Berkley Shands
+ Gregory Neil Shapiro
+ Eyal Shaynis
+ Michael Shields
+ Wesley Shields
+ Philip Shin
+ Anthony Shortland
+ Dave Sill
+ John Silva
+ Chuck Silvers
+ Gerry Singleton
+ Leonard Sitongia
+ Kevin Smallwood
+ Curt Smith
+ Ben Smithurst
+ Douglas R. Smith
+ Kevin Smith
+ Chang Song
+ Josh Soref
+ John Speno
+ Kenneth Stailey
+ Piet Starreveld
+ David Steiner
+ Charles Stephens
+ Marc Stephenson
+ Chip Stettler
+ Dave Stevens
+ Jeff Stewart
+ Diana Stockdale
+ Andreas Stolcke
+ Jeff Stoner
+ Sushila Subramanian
+ Jan Ole Suhr
+ Mike Sullivan
+ Patrick D. Sullivan
+ Peter Svensson
+ Chris Sylvain
+ Miklos Szeredi
+ Paul Szabo
+ Dale Talcott
+ Jon A. Tankersley
+ Jan Tax
+ Samuel Thibault
+ Andy Thomas
+ Matthew Thurmaier
+ Chris Timmons
+ Andrzej Tobola
+ R. Lindsay Todd
+ Zdenko Tomasic
+ Michael Townsend
+ Linus Torvalds
+ Mike Tracy
+ Dan Trinkle
+ Erik Trulsson
+ Lars Tunkrans
+ Lenny Turetsky
+ Kevin Vajk
+ Peter Valchev
+ John R. Vanderpool
+ Peter Van Epp
+ Peter C. Vernam
+ Peter Vines
+ Bob Ward
+ Jules van Weerden
+ Tom Weaver
+ Fernando A.B. Whitaker
+ Tom Whitty
+ Carson Wilson
+ David J. Wilson
+ Frank Winkler
+ Marc Winkler
+ Mark Vasoll
+ Holger VanKoll
+ Robert Vernon
+ Joep Vesseur
+ Larry Virden
+ Jos Vos
+ Jun Biao Wang
+ Christopher J Warweg
+ Bill Watson
+ Florian M. Weps
+ Joel White
+ Paul Wickman
+ Martin Wilke
+ Eric Williams
+ Steve Williams
+ Steve Wilson
+ Erich Wimmer
+ Wally Winzer, Jr.
+ Patrick Wolfe
+ Stephen Woods
+ James Woodward
+ Scott Worley
+ Jan Wortelboer
+ Joshua Wright
+ Sailu Yallapragada
+ Masatake Yamato
+ Donna Yobs
+ Ron Young
+ Blair Zajac
+ Karel Zak
+ Donald Zoch
+ Malcom Zung
+ and Waldemar Zurowski
+
+If I have omitted a contributor's name, the fault is wholly mine,
+and I apologize for the error.
+
+
+Vic Abell <abe@purdue.edu>
+September 27, 2011
diff --git a/lsof_4.85/lsof_4.85_src/00DCACHE b/lsof_4.85/lsof_4.85_src/00DCACHE
new file mode 100644
index 0000000..a6c03ea
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00DCACHE
@@ -0,0 +1,745 @@
+
+ Configuring The Device Cache File Path
+
+ Contents
+
+ A. Introduction and History
+ B. Device Cache File Format
+ 1. Integrity Checks
+ 2. The Setgid and Setuid-root States
+ C. Device Cache File Path Options
+ 1. Path Named by ``-D''
+ 2. Path Named in Environment Variable
+ 3. Default System-wide Path
+ a. Build Procedure
+ 4. Default Personal Path
+ 5. Modified Default Personal Path
+ D. Displaying the Default Path
+ Appendix A, Unix Dialects Without a Device Cache
+ Appendix B, Lsof Dialects and Their Permissions
+ 1. Setuid-root Lsof Dialects
+ 2. Setgid Lsof Dialects That Surrender Setgid
+ Permission
+
+
+A. Introduction and History
+===========================
+
+Lsof writes a file of information about the contents of the nodes
+in /dev (or /devices) to reduce its startup overhead on later calls.
+It does this for all Unix dialects, except those noted in Appendix A.
+
+This file, called the device cache file, enables lsof to avoid
+calling the kernel stat(2) function on every node in /dev (or
+/devices) from which it builds a table of correspondence between
+major/minor device numbers and device names.
+
+A full scan of /dev (or /devices) on some systems may involve
+calling the sometimes-slow stat(2) function 10,000 times or more.
+Furthermore, each stat(2) call consumes space in the kernel's name
+cache, forcing from it path name components that would be more
+useful when lsof tries to associate them with open files.
+
+While it's hard to question the usefulness of the device cache,
+it's also hard to decide where it should be written. When the
+feature was first added, the device cache file was written to /tmp,
+and its ownership was set to that of the real user ID (UID) under
+which the creating lsof process was run. However, to enable any
+process to update it when /dev (or /devices) changed, lsof set its
+modes to 0666, thus allowing anyone to read or write it.
+
+The writing of a world-readable and world-writable device cache
+file to any place has security weaknesses. A clever intruder who
+carefully preserves the integrity of the file might be able to
+remove devices that would prevent lsof from observing the intruder's
+files. A clever intruder might also be able to put a symbolic link
+in place and trick lsof into writing to the link's destination with
+its effective permissions, thus bypassing the real user's (possibly
+weaker) permissions.
+
+Later the location of the device cache file was changed. It was
+converted to a personal file, located in the home directory of each
+real UID that executed lsof, and owned by that UID. Thus it was
+no longer possible for one user to affect lsof's access to the
+device cache file, nor was it possible for a user to mount a symbolic
+link attack on a restricted file, but the result was that each lsof
+user had a private copy of the device cache file.
+
+The device cache file feature has undergone some further refinements
+in path name formation to reach its present state. This documentation
+describes the path name formation options open to the lsof builder
+and user after those refinements, and how lsof attempts to insure
+that none of the options presents a security risk.
+
+
+B. Device Cache File Format
+===========================
+
+The device cache file is a flat file of ASCII text. It has an
+initial statement of how many sections the file might contain --
+the possible sections are character devices, block devices, clone
+devices, pseudo devices, and checksum. The character devices and
+checksum sections are always present.
+
+Each section has a header that numbers the entries in the section.
+
+The last section is a checksum section that contains a 16 bit cyclic
+redundancy (CRC) checksum of everything in the file but the checksum
+section itself.
+
+Lsof always sets the permission modes of the device cache file to
+0600, and the owner to the real UID of the process that executes
+lsof; the group, the real group ID (GID) of the lsof process.
+
+Setting the permission modes to 0600 means that a system-wide device
+cache file won't be usable unless the procedure that builds it
+changes the modes after lsof has written it. A suitable procedure
+for building a system-wide device cache that shows how to adjust
+these inadequate permission modes is given in the Default System-wide
+Path section.
+
+
+B.1. Integrity Checks
+=====================
+
+When lsof opens the device cache file it makes these integrity
+checks:
+
+ 1. Lsof must gain permission from access(2) to be able to
+ open the file for reading. If lsof is writing the file,
+ it usually cedes permission control to the applicable
+ directory and file modes and ownerships. (Some additional
+ checks apply and they're described in the sections on path
+ options.)
+
+ By explicit design lsof never writes to the system-wide
+ device cache file, even when the real UID of its process
+ is root. The system-wide device cache file must be written
+ with a root-owned procedure via the ``-D[b|u<path>'' options
+ -- i.e., under the system administrator's control. (See
+ the Build Procedure sub-section of the Default System-wide
+ Path section.)
+
+ 2. The device cache file's modes must be 0600 (0644 if lsof
+ is reading a system-wide device cache file) and its size
+ must be 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. The first words
+ of legal section titles are "device", "block", "clone",
+ "pseudo", 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.
+
+
+B.2. The Setgid and Setuid-root States
+======================================
+
+There are two fundamental ways in which lsof is granted access to
+restricted system resources. Both access methods are related to the
+effective permissions given the lsof binary or executable.
+
+The first and preferable way to grant lsof access to system resources
+through the permissions endowed on its executable is the giving of
+set group ID (setgid) permission. The group is the one that has
+permission to read the kernel memory and swap devices -- e.g., /dev/kmem,
+/dev/mem, /dev/swap, etc.
+
+This method of granting access is called setgid mode because it
+enables lsof to run with an effective group ID set to the one
+granted by the permissions of its executable file and by the group
+that owns the executable file. See the getegid(2) man page for a
+further discussion of effective group ID.
+
+Usually lsof only needs setgid permission to open access to the
+kernel memory files. After they're open, lsof drops its setgid
+permission.
+
+The second and least preferable way to grant lsof access to system
+resources through the permissions endowed on its executable is the
+giving of set user ID to root (setuid-root) permission. This is
+much too strong a permission, but necessary: to use the -X option
+fully for the version of lsof for AIX 5 and above; to use the
+version of lsof for HP-UX 11.11 and above; and to use the version
+of lsof for Linux 2.1.72 and above. These lsof implementations
+require setuid-root permission to be able to access restricted
+resources -- e.g., the individual files of the /proc file system.
+(But note that the setuid-root Linux lsof doesn't need and has no
+device cache support.)
+
+Lsof never drops setuid-root permission, because it needs that
+power throughout its execution. However, when the lsof process is
+setuid-root, lsof disallows these device cache file path options:
+
+ 1. It ignores the ``-D[b|r|u]<path>'' options. It accepts
+ only the ``-Di'' and ``-Dr'' options.
+
+ 2. It refuses to recognize a path supplied via an environment
+ variable.
+
+ 3. It refuses to accept an additional path component from an
+ environment variable to be inserted in the middle of a
+ personal device cache file path.
+
+Each restriction is imposed because setuid-root power might allow
+a malicious user to form a device cache file path that would give
+read access to a normally inaccessible place (That's bad enough.),
+or write access to a critical system file (That's the worst case.)
+
+There is one further state that lsof can enter that is slightly
+different from the setuid-root and setgid states. That state occurs
+when lsof is being run from a root shell -- i.e., the lsof real
+user ID is root. To avoid accidental complications, when lsof is
+in this state, it ignores all environment variable options.
+
+In the rest of this document you will find more detailed discussion
+of the special restrictions caused by the type of permission that
+has been given the lsof executable.
+
+
+C. Device Cache File Path Options
+=================================
+
+Lsof offers five options for constructing the path to the device
+cache file. Each has special conditions and safeguards that
+surround its use. The options are:
+
+ 1. A device cache file that is named in the <path> component
+ of the parameters of lsof's ``-D'' option.
+
+ =========================================================
+ * This is a default option of the lsof distribution. *
+ * *
+ * Paths specified with this option are read-only unless *
+ * the real UID of the lsof process is root (0), or the *
+ * lsof process is able to surrender setgid permission *
+ * (See Appendix B) and it is not setuid-root. *
+ =========================================================
+
+ 2. A device cache file whose name is specified by an environment
+ variable.
+
+ =========================================================
+ * This is a default option of the lsof distribution. *
+ * *
+ * This option is enabled when the lsof dialect is able *
+ * to surrender setgid permission (See Appendix B.), and *
+ * the lsof process is not setuid-root. *
+ * *
+ * The environment variable path is read-only if the *
+ * lsof process does not surrender setgid permission *
+ * (See Appendix B.) *
+ =========================================================
+
+ 3. A system-wide default device cache file, located at a path
+ determined by the builder of lsof. The lsof builder is also
+ responsible for building the device cache file, using a
+ different lsof path formation option at a suitable time --
+ e.g., when the system is booted.
+
+ =========================================================
+ * This is option is disabled by default in the lsof *
+ * distribution. *
+ * *
+ * The path specified with this option is read-only. *
+ =========================================================
+
+ 4. A default personal device cache file, located in the UID's
+ home directory.
+
+ =========================================================
+ * This is a default option of the lsof distribution. *
+ =========================================================
+
+ 5. A personal device cache file whose name is modified by an
+ environment variable.
+
+ =========================================================
+ * This is a default option of the lsof distribution. *
+ * *
+ * The modified personal path is read-only if the lsof *
+ * process does not surrender setgid permission. *
+ * *
+ * This option is disabled when the lsof process is *
+ * setuid-root or its real UID is root (0). *
+ =========================================================
+
+When there are multiple choices for the device cache file path,
+lsof chooses from the above list in the order the list is given,
+subject to restrictions based on the effective group and user IDs
+that are in effect.
+
+Each possible path name is discussed in a later section that
+describes the restrictions that apply to it and the method for
+building lsof to use it.
+
+In one special case lsof will use two paths in order. When a
+system-wide device cache file is enabled, and lsof finds that it
+doesn't exist, lsof will attempt to use a personal device cache
+file.
+
+
+C.1. Path Named by ``-D''
+=========================
+
+The ``-D[b|r|u]<path>'' option can name a path for the device cache
+file where it is unconditionally built (`b'); read, but never
+rebuilt (`r'); and read and rebuilt, if necessary (`u').
+
+If the lsof process is setuid-root, no path may be specified with
+the ``-D'' option -- i.e., only the `i' function is accepted. The
+`r' option may be used if it doesn't have a path argument.
+
+If the lsof process is not setuid-root, nor is the real UID of the
+lsof process root, a path may accompany the `b', `r', and `u'
+functions if the lsof process surrenders setgid permission. (See
+Appendix B.) If the process doesn't surrender setgid permission,
+then a path may accompany only `r'.
+
+Lsof's permission to access a device cache file at a path specified
+with ``-D[b|r|u]<path>'' depends completely on the permission modes
+and ownerships of the file and its directory components.
+
+When the real UID of the lsof process is root (0), paths may be
+specified with ``-D[b|r|u]''.
+
+====================================================================
+* *
+* The ``-D[b|r|u]<path>'' option is enabled by default in the lsof *
+* distribution by the following definition in the dialect's *
+* machine.h header file: *
+* *
+* #define HASDCACHE 1 *
+* *
+* To disable all device cache file options, including all ``-D'' *
+* forms, change the above line in the dialect's machine.h file to: *
+* *
+* /* #define HASDCACHE 1 */ *
+* *
+* or remove it. *
+* *
+* The ``-D[b|r|u]<path>'' options are disabled when the lsof *
+* process is setuid-root. If the lsof process isn't setuid-root, *
+* nor is its real UID root (0), and if the lsof process surrenders *
+* setgid permission, ``-D[b|r|u]'' may be accompanied by a path. *
+* *
+* A path may accompany ``-D[b|u]'' when the real UID of the lsof *
+* process is root. *
+* *
+* ``-Dr'' without a path name argument is always acceptable. *
+* *
+====================================================================
+
+
+C.2. Path Named in Environment Variable
+=======================================
+
+A device cache file path may be declared in an environment variable.
+This option is defined in the dialect's machine.h header file with
+the HASENVDC definition. The value of the HASENVDC definition is
+the environment variable's name.
+
+Lsof will use the value of the environment variable named by HASENVDC
+for the device cache file path unless either of the following
+conditions apply:
+
+ 1. The lsof process is in the setuid-root state.
+or
+ 2. The effective and real UIDs of the lsof process are root
+ (0).
+
+Lsof uses the value of the HASENVDC environment variable as the
+device cache file path after it senses there is no path declared by
+a ``-D'' option.
+
+A path from an environment variable is read-only unless the lsof
+process surrenders setgid permission. (See Appendix B.)
+
+====================================================================
+* *
+* The path name environment variable option is enabled by default, *
+* and the environment variable is named LSOFDEVCACHE in the lsof *
+* distribution by the following definition in the dialect's *
+* machine.h header file: *
+* *
+* #define HASENVDC "LSOFDEVCACHE" *
+* *
+* To disable the path name environment variable option, change *
+* the above line in the dialect's machine.h header file to: *
+* *
+* /* #define HASENVDC "LSOFDEVCACHE" */ *
+* *
+* or remove it. To change the name of the environment variable, *
+* change the quoted value of the HASENVDC definition -- e.g., this *
+* form changes the environment variable name to "FOOBAR": *
+* *
+* #define HASENVDC "FOOBAR" *
+* *
+* You can disable the path name environment option by disabling *
+* all device cache file processing when you remove or by disabling *
+* the HASDCACHE definition in the dialect's machine.h header file. *
+* *
+* The path name environment option is disabled when the lsof *
+* process is setuid-root or when the real UID of the lsof process *
+* is root (0). *
+* *
+* The path named in an environment variable is read-only unless *
+* the lsof process surrenders setgid permission. (See Appendix *
+* B.) *
+* *
+====================================================================
+
+
+C.3. Default System-wide Path
+=============================
+
+When a default system-wide device cache file path is defined (It's
+not enabled by default in the lsof distribution.), lsof will use
+it after it discovers no path has been specified by a ``-D'' option
+and no path has been specified in the environment variable named
+in the string #define HASENVDC of the dialect's machine.h header
+file.
+
+Lsof must be able to open the system-wide device cache file --
+i.e., it must have read access to the file and search access to
+the directories that lead it. As part of its integrity checks,
+lsof requires that the system-wide device cache file's permission
+modes be 0644.
+
+When lsof discovers that the named system-wide device cache file
+doesn't exist, it will attempt to open a personal device cache file
+should that path formation option be enabled. This is the *only*
+case where lsof will attempt to use two device cache file paths.
+
+The system-wide device cache file is read-only; lsof will never
+attempt to write to it. However, when the real UID of the lsof
+process is root, that process may name the system-wide device
+cache file with ``-D[b|u]<path>''.
+
+====================================================================
+* *
+* The system-wide file path option is disabled by default in the *
+* lsof distribution. This place-marking definition in a dialect's *
+* machine.h header file may be altered to enable a system-wide *
+* device cache file path: *
+* *
+* /* #define HASSYSDC "/your/choice/of/path" */ *
+* *
+* To enable the system-wide name option, declaring that its path *
+* is ``/foo/bar/lsof.dc'', change the above line in the dialect's *
+* machine.h header file to: *
+* *
+* #define HASSYSDC "/foo/bar/lsof.dc" *
+* *
+* or change the quoted string of the definition to the path of *
+* your choice. *
+* *
+* You can disable the path name environment option by disabling *
+* all device cache file processing when you remove or disable the *
+* HASDCACHE definition in the dialect's machine.h header file. *
+* *
+* The system-wide device cache file is read-only. *
+* *
+====================================================================
+
+
+C.3.a. Build Procedure
+======================
+
+The system administrator must build the system-wide device cache
+file at an appropriate time -- e.g., each time the system is booted,
+and each time a node is added, deleted or modified in /dev (or
+/devices). The procedure that builds the system-wide device cache
+file must use lsof's ``-D[b|u]<path>'' options to build the file,
+and must change the file's permission modes to 0644 after it has
+been built.
+
+Here's a simple shell script procedure to build a system-wide device
+cache file. It assumes:
+
+ 1. The Unix dialect's kernel supports the interpreter script
+ execution option -- i.e., a script whose first line has
+ the form ``#!<path_to_interpreter>''.
+
+ 2. The chmod, echo, rm, sh, and test programs are located
+ in ``/bin''.
+
+ 3. The string value of the HASSYSDC definition in the dialect's
+ machine.h header file is the path ``/your/choice/of/path''.
+
+ 4. The lsof executable is located in ``/usr/local/etc''.
+
+ #!/bin/sh
+ #
+ # Simple script to build a system-wide device cache file
+ # for lsof.
+
+ HASSYSDC=/your/choice/of/path
+ /bin/rm -f $HASSYSDC
+ /usr/local/etc/lsof -Du$HASSYSDC > /dev/null 2>&1
+ if /bin/test $? -ne 0
+ then
+ /bin/echo "WARNING: failed to create $HASSYSDC"
+ exit 1
+ fi
+ /bin/chmod 0644 $HASSYSDC
+ exit 0
+
+The invocation of lsof uses the ``-Du$HASSYSDC'' option to read
+the device cache file and recreate it if necessary. The invocation
+can be made more efficient if a known process PID -- e.g., ``-p1''
+-- can be specified. However, if that PID is not always active
+when lsof is called, lsof might set its exit code non-zero, causing
+the subsequent test to believe that the lsof call failed. When in
+doubt, omit the PID specification and accept the extra lsof processing
+time for reporting and discarding all open file information.
+
+
+C.4. Default Personal Path
+==========================
+
+The default personal path option is defined by default in the lsof
+distribution. The path is formed of the home directory of the real
+UID of the lsof process, followed optionally by the contents of
+the HASPERSDCPATH environment variable, followed by ``.lsof_'',
+followed by the first component (characters up to the first period)
+of the name returned by gethostname(2).
+
+If gethostname(2) returns nothing, then nothing will follow the
+``.lsof_'' string. If the first character of what gethostname(2)
+returns is a `.', then all the gethostname(2) value will follow
+the ``/lsof_'' string. (See the ``%l'' conversion for a way to
+make lsof include the entire host name in the path.)
+
+====================================================================
+* *
+* The personal path option is enabled by default in the lsof *
+* distribution. The HASPERSDC #define in a dialect's machine.h *
+* header is a format specification that tells lsof how to form the *
+* personal device cache file path. The conversions in the format *
+* specification begin with `%' , ala the printf(3) function of the *
+* standard I/O library. These conversions are supported: *
+* *
+* ``%%'' causes a single `%' to appear in the path. *
+* *
+* ``%0'' is a separator that marks the beginning of a path *
+* for a setuid-root lsof process or one whose real *
+* UID is 0. When lsof reaches this conversion and *
+* the process is setuid-root or has a real UID of *
+* root, it erases any previously formed path and *
+* restarts with the next HASPERSDC format character. *
+* If lsof reaches this conversion and the process is *
+* not setuid-root and its real UID is not root, path *
+* formation is ended. *
+* *
+* ``%h'' causes the home directory of the real UID of the *
+* lsof process to appear in the path. *
+* *
+* ``%l'' causes the full name returned by gethostname(2) to *
+* appear in the path. *
+* *
+* ``%L'' causes the first component of the name returned by *
+* gethostname(2) to appear in the path. The first *
+* component is defined to be what appears to the *
+* left of the first `.'. If nothing appears to the *
+* left then everything will appear in the path. *
+* *
+* ``%p'' causes the value of (HASPERSDCPATH) from the *
+* process environment to appear in the path. If the *
+* (HASPERSDCPATH) value doesn't end in a '/', one *
+* will be added. *
+* *
+* ``%u'' causes the login name associated with the real UID *
+* of the lsof process to appear in the path. *
+* *
+* ``%U'' causes the real UID of the lsof process, converted *
+* to a decimal string, to appear in the path. *
+* *
+* All other characters are copied from the format to the *
+* path. CAUTION: THINK VERY CAREFULLY ABOUT THE EFFECT OF *
+* USING CHARACTERS THAT FORM AN ABSOLUTE COMPONENT LIKE *
+* ``/tmp'' IN THE FORMAT. Consider what power your dialect *
+* might have (e.g., if it is setuid-root) when lsof must *
+* create a device cache file at the path. Consider using a *
+* ``%0'' conversion to declare an alternate path for lsof *
+* processes that are setuid-root or whose real uid is root. *
+* See the "How do I put the personal device cache file in *
+* /tmp?" question and answer in 00FAQ for an explanation of *
+* this example: *
+* *
+* #define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L" *
+* *
+* This is the format specification that appears in the machine.h *
+* header files of the lsof distribution: *
+* *
+* #define HASPERSDC "%h/%p.lsof_%L" *
+* *
+* It causes the path to be formed from the home directory of the *
+* real UID of the lsof process (``%h''), followed by `/', followed *
+* by the contents of the environment variable named by *
+* HASPERSDCPATH and a trailing `/', as needed (``%p''), followed *
+* by the string ``.lsof_'', and terminated with the first *
+* component of the host's name (``%L''). *
+* *
+* To change the personal path option, change the HASPERSDC string *
+* and recompile lsof. To disable the personal path option, remove *
+* or disable HASPERSDC. The personal path option is disabled when *
+* HASDCACHE is not defined. *
+* *
+====================================================================
+
+
+C.5. Modified Default Personal Path
+===================================
+
+The modified default personal path form is a special case of the
+default personal path. In this form the value of the environment
+variable named by the HASPERSDCPATH #define is inserted in the
+personal path when the ``%p'' conversion appears in the HASPERSDC
+format specification.
+
+This allows, for example, the lsof user to move personal device
+cache files to another branch of the home directory, perhaps to a
+sub-directory where multiple device cache files may appear from
+different machines that use the same NFS- mounted home directory.
+
+The HASPERSDCPATH definition of the dialect's machine.h header file
+names the environment variable. By default in the lsof distribution
+it is LSOFPERSDCPATH.
+
+The modified personal path component is ignored when lsof process
+is setuid-root is root, lest it be maliciously or accidentally used in
+some convoluted form to access paths the real UID cannot. The
+modified personal path component is also ignored when the real UID
+of the lsof process is root (0), so that lsof will not accidentally
+use a personal environment value.
+
+If the lsof process surrenders setgid permission (See Appendix B.),
+lsof can read from and write to the modified personal path. If,
+however, the lsof process doesn't surrender setgid permission, the
+modified personal path is read-only.
+
+If your dialect runs setuid-root or doesn't surrender its setgid
+permission, and you want to use the LSOFPERSDCPATH environment
+variable to address a collection of device cache files in a
+subdirectory, you will have to gather the collection in the
+subdirectory yourself with shell copy or move commands.
+
+====================================================================
+* *
+* The modified personal path option is enabled by default in the *
+* lsof distribution with these definitions in the dialect's *
+* machine.h header file: *
+* *
+* #define HASPERSDCPATH "LSOFPERSDCPATH" *
+* and *
+* #define HASPERSDC "%h/%p.lsof_%L" *
+* *
+* The value of the definition is the name of the environment *
+* variable that contains the modified personal path name *
+* component that is inserted in the personal path when ``%p'' *
+* appears in HASPERSDC. See the Default Personal Path section *
+* for a complete description of the ``%p'' conversion. *
+* *
+* To disable the modified personal path name component, disable *
+* the HASPERSDCPATH definition in the dialect's machine.h header *
+* file -- e.g., change it to: *
+* *
+* /* #define HASPERSDCPATH "LSOFPERSDCPATH" */ *
+* *
+* or remove the definition altogether. If you do this, don't *
+* forget to remove any ``%p'' conversion from HASPERSDC. *
+* *
+* The modified personal path option is disabled when HASDCACHE is *
+* not defined. *
+* *
+* The modified personal path environment variable value is ignored *
+* when the lsof process is setuid-root or when the real UID of *
+* the lsof process is root (0). *
+* *
+* The modified personal path is read-only when the lsof process *
+* doesn't surrender its setgid permission. *
+* *
+====================================================================
+
+
+D. Displaying the Default Path
+==============================
+
+Whatever device cache file path formation options you decide to
+use, remember that the lsof help output, displayed in response to
+its ``-h'' or ``-?'' help options, will display the read-mode
+default (the highest numbered) path that lsof has been enabled to
+form from which it will read.
+
+Since some paths are read-only, the path displayed in help option
+output may not be the one to which lsof will write, should that
+become necessary. To see the read-only and write device cache file
+paths, environment variable names, and the personal device cache
+file format specification (HASPERSDC), use the -D? option.
+
+
+Appendix A, Unix Dialects Without a Device Cache
+================================================
+
+Linux lsof implementations that obtain their information from files
+in the /proc file system do not have device cache support. Generally
+lsof for Linux versions 2.1.72 and greater are /proc based.
+
+
+Appendix B, Lsof Dialects and Their Permissions
+===============================================
+
+These are the permissions recommended in the lsof distribution.
+
+
+Appendix B.1 Setuid-root Lsof Dialects
+======================================
+
+These dialect versions of lsof need root permission. For general
+use they may have to be installed setuid-root.
+
+ Apple Darwin 9 and Mac OS X 10.[56]
+ HP-UX 11.11 and 11.23
+ Linux (no device cache support needed)
+
+
+Appendix B.2 Setgid Lsof Dialects That Surrender Setgid Permission
+==================================================================
+
+Lsof versions for these dialects have WILLDROPGID defined in their
+machine.h header files.
+
+ AIX 5.[12] and 5.3-ML1
+ FreeBSD 4.x, 4.1x, 5.x and [6789].x for x86-based systems
+ FreeBSD 5.x and [6789].x for Alpha, AMD64 and Sparc64-based
+ systems
+ HP-UX 11.00
+ NetBSD 1.[456], 2.x and 3.x for Alpha, x86, and SPARC-based
+ systems
+ NEXTSTEP 3.[13]
+ OpenBSD 2.[89] and 3.[0-9] for x86-based systems
+ OPENSTEP 4.x
+ SCO OpenServer Release 5.0.4 for x86-based systems
+ SCO|Caldera UnixWare 7.1.4 for x86-based systems
+ Solaris 2.6, 8, 9 and 10
+ Tru64 UNIX 5.1
+
+
+Vic Abell <abe@purdue.edu>
+September 27, 2011
diff --git a/lsof_4.85/lsof_4.85_src/00DIALECTS b/lsof_4.85/lsof_4.85_src/00DIALECTS
new file mode 100644
index 0000000..12c5f0b
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00DIALECTS
@@ -0,0 +1,6 @@
+ AIX 5.3
+ Apple Darwin 9 and Mac OS X 10.[56]
+ FreeBSD 4.9 and 6.4 for x86-based systems
+ FreeBSD 8.[02] and 9.0 for AMD64-based systems
+ Linux 2.1.72 and above for x86-based systems
+ Solaris 9, 10 and 11
diff --git a/lsof_4.85/lsof_4.85_src/00DIST b/lsof_4.85/lsof_4.85_src/00DIST
new file mode 100644
index 0000000..b13641b
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00DIST
@@ -0,0 +1,4598 @@
+
+ Notes for the distribution of lsof version 4
+
+********************************************************************
+| The latest release of lsof is always available via anonymous ftp |
+| from lsof.itap.purdue.edu. Look in pub/tools/unix/lsof. |
+********************************************************************
+
+ Contents
+
+ Dialects Supported
+ How Lsof Works
+ Lsof Output
+ Getting Started Quickly
+ Limiting, Filtering, and Selecting Lsof Output
+ Parsing Lsof Output with Another Program
+ Repeat Mode
+ Distribution Restrictions
+ Cautions
+ Distribution Contents
+ Warranty
+ Bug Reports
+ The lsof-l Mailing List
+ Version 3 Release Notes
+ 3.0, May 24, 1994
+ ...
+ 3.88, February 17, 1997
+ What's New in Version 4
+ Version 4 Release Notes
+ 4.0, February 24, 1997
+ 4.01, March 3, 1997
+ 4.02, March 21, 1997
+ 4.03, April 7, 1997
+ 4.04, April 17, 1997
+ 4.04 supplement, April 18, 1997
+ 4.05, April 24, 1997
+ 4.06, April 30, 1997
+ 4.07, May 12, 1997
+ 4.08, May 23, 1997
+ 4.09, June 1, 1997
+ 4.10, June 8, 1997
+ 4.11, June 12, 1997
+ 4.12, June 24, 1997
+ 4.13, July 9, 1997
+ 4.14, July 22, 1997
+ 4.15, August 15, 1997
+ 4.16, September 25, 1997
+ 4.17, October 14, 1997
+ 4.18, October 25, 1997
+ 4.19, October 30, 1997
+ 4.20, November 11, 1997
+ 4.21, December 1, 1997
+ 4.22, December 15, 1997
+ 4.23, January 16, 1998
+ 4.24, January 28, 1998
+ 4.25, February 7, 1998
+ 4.26, February 17, 1998
+ 4.27, March 6, 1998
+ 4.28, March 10, 1998
+ 4.29, March 26, 1998
+ 4.30, April 9, 1998
+ 4.31, April 21, 1998
+ 4.32, May 13, 1998
+ 4.33, May 22, 1998
+ 4.34, June 26, 1998
+ 4.35, July 17, 1998
+ 4.36, August 4, 1998
+ 4.37, September 15, 1998
+ 4.38, November 25, 1998
+ 4.39, December 29, 1998
+ 4.40, January 25, 1999
+ 4.41, February 27, 1999
+ 4.42, March 30, 1999
+ 4.43, May 11, 1999
+ 4.44, June 24, 1999
+ 4.45, July 30, 1999
+ 4.46, October 23, 1999
+ 4.47, November 29, 1999
+ 4.48, January 14, 2000
+ 4.49, April 3, 2000
+ 4.50, June 29, 2000
+ 4.51, August 21, 2000
+ 4.52, November 8, 2000
+ 4.53, December 6, 2000
+ 4.54, January 19, 2001
+ 4.55, February 15, 2001
+ 4.56, May 3, 2001
+ 4.57, July 19, 2001
+ 4.58, September 13, 2001
+ 4.59, October 20, 2001
+ 4.60, November 9, 2001
+ 4.61, January 22, 2002
+ 4.62, March 7, 2002
+ 4.63, April 23, 2002
+ 4.64, June 26, 2002
+ 4.65, October 10, 2002
+ 4.66, December 22, 2002
+ 4.67, March 27, 2003
+ 4.68, June 18, 2003
+ 4.69, October 16, 2003
+ 4.70, January 16, 2004
+ 4.71, March 11, 2004
+ 4.72, July 13, 2004
+ 4.73, October 21, 2004
+ 4.74, January 17, 2005
+ 4.75, May 16, 2005
+ 4.76, August 30, 2005
+ 4.77, April 10, 2006
+ 4.78, April 24, 2007
+ 4.79, April 15, 2008
+ 4.80, May 12, 2008
+ 4.81, October 21, 2008
+ 4.82, March 25, 2009
+ 4.83, January 18, 2010
+ 4.84, July 29, 2010
+ 4.85, September 27, 2011
+
+
+Dialects Supported
+==================
+
+Lsof (for LiSt Open Files) lists files opened by processes on
+selected Unix systems. Version 4 is a source reorganization of
+version 3, itself a major revision of version 2. Version 4 has
+been tested on:
+
+ AIX 5.3
+ Apple Darwin 9 and Mac OS X 10.[56]
+ FreeBSD 4.9 and 6.4 for x86-based systems
+ FreeBSD 8.[02] and 9.0 for AMD64-based systems
+ Linux 2.1.72 and above for x86-based systems
+ Solaris 9, 10 and 11
+
+(The pub/tools/unix/lsof/contrib directory on lsof.itap.purdue.edu
+contains information on other ports.)
+
+If your favorite Unix dialect is not in the list, or if your version
+of it is more recent than the ones listed, please contact me at
+<abe@purdue.edu>.
+
+Version 3 of lsof was tested on:
+
+ AIX 3.2.5, 4.1[.[1234]], and 4.2
+ BSDI BSD/OS 2.0, 2.0.1, and 2.1 for x86-based systems
+ DC/OSx 1.1 for Pyramid systems
+ Digital UNIX (DEC OSF/1) 2.0, 3.0, 3.2, and 4.0
+ EP/IX 2.1.1 for the CDC 4680
+ FreeBSD 1.1.5.1, 2.0, 2.0.5, 2.1, 2.1.5 for x86-based
+ systems
+ HP-UX 8.x, 9.x, 10.01, 10.10, and 10.20
+ IRIX 5.2, 5.3, 6.0, 6.0.1, and 6.[124]
+ Linux through 2.0.27 for x86-based systems
+ NetBSD 1.0, 1.1, and 1.2 for x86 and SPARC-based
+ systems
+ NEXTSTEP 2.1 and 3.[0123]
+ OpenBSD 1.2 and 2.0 for x86-based systems
+ Reliant UNIX 5.43 for Pyramid systems
+ RISC/os 4.52 for MIPS R2000-based systems
+ SCO OpenServer Release 1.1, 3.0, and 5.0.x for x86-based
+ systems
+ SCO UnixWare 2.1 and 2.1.1 for x86-based systems
+ Sequent PTX 2.1.[1569], 4.0.[23], 4.1.[024], 4.2[.1],
+ and 4.3
+ Solaris 2.[12345], 2.5.1, and 2.6-Beta
+ SunOS 4.1.x
+ Ultrix 4.2, 4.3, 4.4, and 4.5
+
+Version 3 and its predecessor, version 2, may be found at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD
+
+
+How Lsof Works
+==============
+
+Using available kernel data access methods -- getproc(), getuser(),
+kvm_*(), nlist(), pstat(), read(), readx(), /proc -- lsof reads
+process table entries, task table entries, user areas and file
+pointers to reach the underlying structures that describe files
+opened by processes.
+
+Lsof interprets most file node structures -- advfsnodes, autonodes,
+cnodes, cdrnodes, devnodes, fifonodes, gnodes, hsnodes, inodes,
+mfsnodes, pcnodes, procnodes, rnodes, snodes, specnodes, s5inodes,
+tmpnodes. It understands NFS connections. It recognizes FIFOs,
+multiplexed files, Unix and Internet sockets. It knows about
+streams. It understands /proc file systems for some dialects. On
+many dialects it recognizes execution text and library references.
+It knows about AFS on some Unix dialects.
+
+
+Lsof Output
+===========
+
+The lsof output describes:
+
+ * the identification number of the process (PID) that has opened
+ the file;
+
+ * the process group identification number (PGID) of the process
+ (optional);
+
+ * the process identification number of the parent process (PPID)
+ (optional);
+
+ * the command the process is executing;
+
+ * the owner of the process;
+
+ * for all files in use by the process, including the executing
+ text file and the shared libraries it is using:
+
+ * the file descriptor number of the file, if applicable;
+
+ * the file's access mode;
+
+ * the file's lock status;
+
+ * the file's device numbers;
+
+ * the file's inode number;
+
+ * the file's size or offset;
+
+ * the name of the file system containing the file;
+
+ * any available components of the file's path name;
+
+ * the names of the file's stream components;
+
+ * the file's local and remote network addresses;
+
+ * the TLI network (typically UDP) state of the file;
+
+ * the TCP state, read queue length, and write queue length
+ of the file;
+
+ * the file's TCP window read and write lengths (Solaris
+ only);
+
+ * other file or dialect-specific values.
+
+
+Getting Started Quickly
+=======================
+
+If you want to get started using lsof quickly, or see some examples
+of how lsof can be used, consult the 00QUICKSTART file of the lsof
+distribution.
+
+The 00QUICKSTART file won't help you build or install lsof, but it
+will cut through the density of the lsof man page, giving you more
+readily an idea of what you can do with lsof.
+
+For information on building and installing lsof, consult the 00README
+file of the lsof distribution.
+
+
+Limiting, Filtering, and Selecting Lsof Output
+==============================================
+
+Lsof accepts options to limit, filter, and select its output.
+These are the possible criteria:
+
+ * Process ID (PID) number -- to list the open files for a given
+ process;
+
+ * Process Group ID (PGID) -- to list the open files for all
+ the processes of a given process group;
+
+ * User ID number or login name -- to list the open files for
+ all the processes of a given user;
+
+ * Internet address -- to list the open files using a given
+ Internet address (host name), protocol, or port (number or
+ name); or to list all open Internet files;
+
+ * command name;
+
+ * file descriptor name or number;
+
+ * list all open NFS files;
+
+ * list all open Unix domain socket files;
+
+ * list all uses of a specific file;
+
+ * list all open files on a file system.
+
+Selection options are normally ORed -- i.e., an open file meeting
+any of the criteria is listed. The selection options may be ANDed
+so that an open file will be listed only if it meets all the
+criteria.
+
+In the absence of any selection criteria, lsof lists files open to
+all processes.
+
+
+Parsing Lsof Output with Another Program
+========================================
+
+The lsof -F option directs it to produce "field" output that can
+easily be parsed by another program. The lsof distribution contains
+sample awk, perl 4, and perl 5 scripts in its scripts subdirectory
+that show how to post-process field output.
+
+
+Repeat Mode
+===========
+
+Lsof can be directed to produce output, delay for a specified time,
+then repeat the output, cycling until stopped by an interrupt or
+quit signal. This mode is useful for monitoring the status of some
+file operation -- e.g., an ftp transfer or a tape backup operation.
+
+Repeat mode is more efficient when combined with lsof's selection
+options, since they limit lsof overhead.
+
+It's possible to use lsof's field output options to supply repeat
+mode output to another process for its manipulation. The scripts
+subdirectory of the lsof distribution has sample Perl scripts
+showing how to consume lsof repeat mode output from a pipe.
+
+
+Distribution Restrictions
+=========================
+
+Lsof may be used and distributed freely, subject to these limitations:
+
+1. Neither the author nor Purdue University is 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 author 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 from or altered in the lsof source
+ files.
+
+
+Cautions
+========
+
+Lsof is a tool that is closely tied to the Unix operating system
+version. It uses header files that describe kernel structures and
+reads kernel structures that typically change from OS version to
+OS version.
+
+DON'T TRY TO USE AN LSOF BINARY, COMPILED FOR ONE UNIX OS VERSION,
+ON ANOTHER.
+
+On some Unix dialects, notably SunOS and Solaris, lsof versions
+may be even more restricted by architecture type. An lsof binary,
+compiled for SunOS 4.1.3 on a sun4c machine, for example, won't
+work on a sun4m machine.
+
+AN LSOF BINARY, COMPILED FOR ONE SOLARIS 1.X ARCHITECTURE, ISN'T
+GUARANTEED TO WORK ON A DIFFERENT SOLARIS 1.X ARCHITECTURE.
+
+
+Distribution Contents
+=====================
+
+The lsof distribution is checked for completeness when it is
+constructed and by the Inventory script when you run the Configure
+script. (See The Inventory Script section of the 00README file of
+this distribution.)
+
+Lsof is organized in these parts:
+
+ * The main lsof directory, containing common sources,
+ configuration and setup scripts and three subdirectories:
+ dialects/, lib/, and scripts/.
+
+ Lsof is compiled in the main lsof directory after configuration.
+ The selected dialect sources are copied or linked from the
+ specified subdirectory. (Symbolic linking is the standard
+ method.)
+
+ Common lsof definitions may be found in lsof.h; common
+ function prototypes, proto.h; and common storage, store.c.
+
+ * The dialects/ subdirectory contains subdirectories with
+ sources specific to UNIX dialect implementations -- e.g.,
+ the dialects/sun/ subdirectory contains sources for the
+ SunOS (Solaris 1.x) and Solaris (2.x) implementations of
+ lsof. The dialects subdirectories also contain Makefiles
+ and scripts for assisting dialect source configuration.
+
+ Dialect configuration definitions may be found in dlsof.h;
+ other dialect definitions, dlsof.h; dialect prototypes,
+ dproto.h; and dialect storage, dstore.c.
+
+ * The lib/ subdirectory contains sources for common lsof
+ functions. Not all dialects use the functions -- some have
+ their own versions of them. The lib/ functions are enabled
+ and customized with #define's in the dialect machine.h header
+ files.
+
+ * The scripts/ subdirectory contains sample scripts for
+ processing lsof field (-F) output. The scripts are written
+ in AWK, Perl 4, and Perl 5.
+
+The 00PORTING file of the lsof distribution has more information
+on lsof components, configuration, and construction.
+
+
+Warranty
+========
+
+Lsof is provided as-is without any warranty of any kind, either
+expressed or implied, including, but not limited to, the implied
+warranties of merchantability and fitness for a particular purpose.
+The entire risk as to the quality and performance of lsof is with
+you. Should lsof prove defective, you assume the cost of all
+necessary servicing, repair, or correction.
+
+
+Bug Reports
+===========
+
+Now that the obligatory disclaimer is out of the way, let me hasten
+to add that I accept lsof bug reports and try hard to respond to
+them. I will also consider and discuss requests for new features,
+ports to new dialects, or ports to new OS versions.
+
+PLEASE DON'T SEND A BUG REPORT ABOUT LSOF TO THE UNIX DIALECT
+VENDOR.
+
+At worst such a bug report will confuse the vendor; at best, the
+vendor will forward the bug report to me.
+
+Please send all bug reports, requests, etc. to me via email at
+<abe@purdue.edu>.
+
+
+The lsof-l Mailing List
+=======================
+
+Information about lsof, including notices about the availability
+of new revisions, may be found in mailings of the lsof-l listserv.
+For more information about it, including instructions on how to
+subscribe, read the 00LSOF-L file of the lsof distribution.
+
+
+Version 3 Release Notes
+=======================
+
+See 00DIST in the last lsof 3 revision 3.88, for its complete
+set of release notes. Lsof revision 3.88 may be found at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD
+
+3.0 May 24, 1994
+ This is the first official release of lsof 3.
+
+...
+
+3.88 February 17, 1997
+
+ +======================================+
+ | This is the last version 3 revision. |
+ +======================================+
+
+ Added documentation files -- 00.README.FIRST[_<version>]
+ and 00RELEASE.SUMMARY_<version> -- to the distribution.
+
+
+What's new in Version 4
+=======================
+
+The main goal of version 4 was to eliminate the confusing common/
+fragment source file technique. Changing the version number also
+provided an opportunity to restart the numbering, which at 3.88
+had risen to a large value.
+
+The sources that appeared in the dialects/common subdirectory of
+version 3 in fragment files have been incorporated into the version
+4 liblsof.a library as *.c files. This results in significant
+changes to many source files, scripts, and Makefiles of all dialect
+versions. It allows elimination of some source files -- ddev.c,
+dfile.c, dmnt.c -- for dialects now obtaining functions from
+liblsof.a that formerly came from making dialect source files by
+combining fragment files.
+
+The version 4 liblsof.a sources are stored in the lib/ subdirectory
+of the main lsof directory. The liblsof.a functions are activated
+and conditioned in their source files by values #define'd in the
+dialect dlsof.h and machine.h header files.
+
+Dialects that provide a private version of a library function refrain
+from #define'ing the symbol that would activate the library function
+code.
+
+
+Version 4 Release Notes
+=======================
+
+4.0 February 24, 1997
+
+ +====================================+
+ | This is the first lsof 4 revision. |
+ +====================================+
+
+ Reorganized sources: eliminated code fragment files
+ and created a library in their place. Modified or
+ deleted many dialect source and header files.
+ Changed documentation accordingly.
+
+ Added a warning to sgi/Makefile and 00FAQ that advises
+ against using the IRIX C compiler -n32 option when
+ compiling lsof. Thanks go to Peter Ilieve
+ <peter@memex.co.uk> for bringing this to my attention.
+
+ Dropped IRIX 5.2 in mid-stream, because my 5.2 test
+ system was upgraded to 5.3.
+
+4.01 March 3, 1997
+ Added TFS support for Pyramid dialects.
+
+ Added test to Configure and to the IRIX dnode.c
+ for the different cnode struct that appears in
+ <cachefs/cachefs_fs.h> on the 6.2 IMPACT distribution.
+ Heddy Boubaker <boubaker@amfou.cenatls.cena.dgac.fr>
+ alerted me to the cnode change and helped test this
+ lsof adjustment.
+
+ Shut down the lsof child process before doing a -r
+ sleep(). A comment from Dan Mercer <dam@mmm.com>
+ prompted this.
+
+4.02 March 21, 1997
+
+ Based on a report from Pasi Kaara <Pasi.Kaara@atk.tpo.fi>,
+ disabled HP-UX CCIT support in lsof for HP-UX
+ versions 10 and above. Pasi's report also led to
+ changes in the HP-UX machine.h to support use of
+ gcc to compile lsof for HP-UX 10.20 and warnings
+ against using `cc -Aa` or `gcc -ansi` to compile
+ lsof under HP-UX 10.x.
+
+ With help from Richard Allen <ra@hp.is> taught
+ HP-UX 10.x lsof to name file systems better by
+ using the virtual file system device number. Elias
+ Halldor Agustsson <elias@rhi.hi.is> provided a test
+ system.
+
+ Changed NEXTSTEP and UNIXWARE Makefiles to use
+ safer quoting when generating version.h. The change
+ was suggested by Bob Farmer <ucs_brf@unx1.shsu.edu>.
+
+ Added SHELL=/bin/sh string to all Makefiles.
+
+ Added support for Linux 2.1.28 on a test system,
+ kindly provided by Jonathan Sergent <sergent@purdue.edu>.
+ Configure tests the Linux 2.1.x's C library lseek()
+ function for proper handling of kernel offsets.
+ If lseek() appears suspect, Configure activates
+ the use of a private lseek() function. Changed
+ the private nlist() function to nlist_private()
+ and taught it to use the query_module() syscall in
+ place of the deprecated get_kernel_syms() one.
+ Added rudimentary AX.25 support for Pierfrancesco
+ Caci <ik5pvx@infogroup.it> who helped test it.
+ Updated the old get_kernel_syms() code to recognize
+ and skip module name entries.
+
+ Prompted by Marty Leisner <leisner@sdsp.mc.xerox.com>,
+ eased the requirement that service name lookup for
+ the -i option be accompanied by a protocol name. The
+ name is not needed if both TCP and UDP names yield the
+ same port number.
+
+ Added xusers.awk script from Dan Mercer <damercer@mmm.com>
+ to the distribution scripts/ subdirectory.
+
+ Changed Configure script to use LSOF_VERS for all
+ UNIX dialect version numbers and to pass LSOF_VERS
+ to the dialect Mksrc functions. Also added the
+ ability for a dialect stanza to declare a different
+ dialect Makefile source. Modified dialect Mksrc
+ files -- e.g., linux and sun -- accordingly.
+
+ Added support for BSD/OS 3.0 with help from Jim
+ Reid <jim@mpn.cp.philips.com>. Terry Kennedy
+ <TERRY@spcvxa.spc.edu> kindly provided a test
+ system. During the port corrected a bug that
+ prevented proper handling of revoked files.
+
+4.03 April 7, 1997
+ At the suggestion of Dan Mercer <damercer@mmm.com>,
+ made HP-UX building of lsof aware of differences
+ between the HP-UX bundled and unbundled C compilers.
+
+ Added the ability for the lsof builder to define the
+ default warning message issuance state. By default the
+ issuance of warning messages is disabled; defining
+ WARNINGSTATE in machine.h disables it. The Customize
+ script was updated to handle WARNINGSTATE. Dan Mercer
+ suggested this.
+
+ Eliminated compiler complaint about improperly cast
+ get_Nl_value() argument in ncache_load() in lib/rnch.c.
+
+ Corrected zeromem() argument error in SCO dproc.c.
+ Sped up parent directory cache lookup slightly.
+
+ Updated for PTX 4.4, including additional VxFS (EFS)
+ file system support.
+
+4.04 April 17, 1997
+ At the suggestion of Bela Lubkin <belal@sco.COM>
+ changed device cache handling to be more tolerant
+ of a device cache file whose [cm]times are older
+ than the ones on /dev or /devices. The change
+ required adding information to Solaris device cache
+ file clone lines, so the first time lsof 4.04 is
+ run under Solaris it will complain about a bad
+ cached clone device in a previous device cache
+ file, then regenerate it.
+
+ Added boot file path detection for SCO OSR 5 and
+ above, based on information supplied by Bela.
+
+ Fixed two bugs in DEC OSF/1 lsof -- an error in
+ reporting locks and a missing continue statement
+ in readdev() after a failure to open a directory.
+ Jan Ole Suhr <josuhr@informatik.tu-clausthal.de>
+ reported the second bug and supplied a fix.
+
+ Fixed XFS problems with IRIX 6.2 by abandoning the
+ idea that SGI will distribute XFS header files and
+ defining an lsof-private xfs_inode structure. John
+ Paul Morrison <John.Paul.Morrison@MultiActive.com>
+ helped develop and test the 5.3 definition. John
+ R. Vanderpool <fish@daacdev1.gsfc.nasa.gov> helped
+ develop and test the 6.2 definition.
+
+ Remove obsolete comments about common/*.frag files.
+
+ Updated Linux lsof for Linux version 2.1.35.
+
+4.04 April 18, 1997
+Supplement Regenerated the 4.04 distribution to correct a non-
+ device-cache #define misplacement in the Solaris and
+ SunOS dlsof.h. Alexandre Oliva <oliva@dcc.unicamp.br>
+ reported the problem.
+
+4.05 April 24, 1997
+ Corrected an error in 00DCACHE.
+
+ Made sure SCO /etc/ps/booted.systems is closed.
+
+ Based on an observation by Bela Lubkin <belal@sco.COM>
+ that the lsof child had needless file descriptors
+ open, closed all but the open pipes between the
+ lsof parent and child.
+
+ Decommissioned CDC EP/IX support; I no longer have a
+ test system.
+
+ Based on a suggestion from Patrick Connor
+ <connor@phreak.csd.sgi.com>, added -xansi to CFLAGS
+ for IRIX 5.3 and 6.[234].
+
+ Also at Patrick's suggestion changed Configure to
+ propagate exact SunOS 4.1.x version to the main
+ and library Makefiles. This allowed the sunos413
+ and sunos413cc Configure abbreviations to be
+ shortened to sunos and sunoscc.
+
+ Updated obsolete argument uses (-H changed to -n)
+ in count_pf.perl* and watch_a_file.perl scripts.
+
+ Adjusted Solaris 2.6 lsof for Beta_Update with tips
+ from Casper Dik <casper@holland.Sun.COM>.
+
+ Fixed a Solaris 2.4 TCP address reporting bug.
+
+4.06 April 30, 1997
+ Added a step to the Makefile clean rules that does
+ a make clean in the lib subdirectory; suggested by
+ Casper Dik <casper@holland.Sun.COM>. (Configure's
+ -clean argument already did this.)
+
+ Fixed an incorrect awk argument in the sunos*)
+ Configure stanza, reported by Alexandre Oliva
+ <oliva@dcc.unicamp.br>.
+
+ Added CD9660 (aka ISO) file system support to
+ FreeBSD, NetBSD, and OpenBSD with mods and help
+ from Kenneth Stailey <kstailey@disclosure.com>.
+ (BSDI already had CD9660 support.) While at it,
+ added file descriptor system support to BSDI and
+ FreeBSD.
+
+ Added /kern file system support to OpenBSD. The
+ support wasn't extended to BSDI, FreeBSD, or NetBSD,
+ because it requires Kenneth Stailey's changes to
+ /sys/miscfs/kernfs/kernfs.h.
+
+ Updated IRIX 6.3 support after getting access to
+ a test system, provided by John Paul Morrison
+ <John.Paul.Morrison@MultiActive.com>. Improved
+ the handling of IRIX 5.1 and greater FIFOs.
+
+4.07 May 12, 1997
+ Based on AIX problem reports from David Capshaw
+ <David.Capshaw@SEMATECH.Org>, changed the aix*
+ Configure script stanza to avoid -bnolibpath for
+ gcc (which the GNU loader doesn't grok) and AIX
+ below 4.1.4 (where -bnolibpath hasn't been tested
+ or is known to be unimplemented), and to refuse to
+ use gcc for compiling lsof in AIX versions below
+ 4.1 (because of possible structure alignment
+ problems). Updated 00FAQ appropriately.
+
+ Added OpenBSD support for EXT2FS. This support
+ has yet to be tested.
+
+ Tested lsof under OpenBSD 2.1.
+
+ Activated /kern file system support for NetBSD when
+ Configure senses that /sys/miscfs/kernfs/kernfs.h
+ defines the kern_target structure. This support
+ has not been tested under NetBSD, although it has
+ been tested under OpenBSD.
+
+ Made some simple changes to the BSDI machine.h,
+ suggested by Jeffrey C. Honig <jch@bsdi.com>.
+
+ Improved handling of alternate dialect Configure
+ abbreviations -- aix and aixgcc, hpux and hpuxgcc,
+ solaris and solariscc, and sunos and sunoscc.
+
+4.08 May 23, 1997
+ Cleaned up dialect Makefile's, staring with a suggestion
+ from Christopher Schanzle <chris@cam.nist.gov>.
+
+ Improved Configure's -clean processing.
+
+ Corrected bugs in Solaris lock reporting.
+
+ Changed NetBSD Configure stanza to put -I/usr/include
+ before -I/sys.
+
+4.09 June 1, 1997
+ Adjusted for latest FreeBSD 3.0 release. This
+ required adding a new kernel name cache module for
+ reading BSD-form hashed kernel name cache entries,
+ rnmh.c, to the lsof library, and adding a #define
+ to each machine.h to select it.
+
+ Activated rnmh.c for BSDI 2.1, BSDI 3.0, NetBSD
+ 1.2, and OpenBSD 2.1.
+
+4.10 June 8, 1997
+ Adjusted for Linux 2.1.x (x > 35) kernels with
+ hashed task structure pointers. Marty Leisner
+ <leisner@sdsp.mc.xerox.com> and Jonathan Sergent
+ <sergent@io.com> tested the adjustment.
+
+ Replaced readdev() stat() calls with lstat() to
+ reduce device table and cache entries with the same
+ device number and inode values. Added code to
+ remove all remaining duplicates. This fixes a
+ Linux problem reported by Jonathan Sergent and
+ makes device node name output predictable.
+
+ Corrected a bug in UnixWare stream file handling
+ that prevented searching for the stream file by
+ its associated character device name.
+
+ Added Pyramid code to determine Reliant UNIX clone
+ major device number differently from that of DC/OSx.
+
+4.11 June 12, 1997
+ Changed Configure to sense that the PTX inp_[fl]addr
+ members of the inpcb structure of <netinet/in_pcb.h>
+ have a struct type and set HASINADDRSTR for use in
+ PTX dnode.c and dsock.c tests.
+
+ Changed PTX version 4.1.4 tests to use 4.1.3 instead.
+ Carson Wilson <carson@mcs.com> reported the need
+ to do this and tested the change.
+
+ Fixed a block device table indexing bug in lib/rdev.c,
+ reported by Carson Wilson. The same bug was squashed
+ in pyramid/ddev.c.
+
+ Added code to the Pyramid Reliant UNIX kread()
+ function to compensate for an address boundary
+ error in the kernel's /dev/kmem driver.
+
+ Verified that lsof compiles and works under AIX
+ 4.2.1. Added an AIX test for the presence of NFS
+ header files, defined HAS_NFS and adjusted AIX
+ dialect sources accordingly.
+
+ Based on a suggestion from Gaylord Holder
+ <holder@phy.ucsf.EDU>, added DEC OSF/1 code to
+ auto-detect the booted file, whence kernel symbol
+ addresses are obtained.
+
+4.12 June 24, 1997
+ Corrected a device number sign extension problem
+ in the reading and writing of device cache file.
+ The problem was reported by Bela Lubkin <belal@sco.com>
+ and he suggested a fix.
+
+ Fixed an SCO stream device lookup problem. The
+ report and solution came from Bela Lubkin
+
+ Enhanced the Configure script to enable cross-
+ configuration of lsof, based on suggestions from
+ Marty Leisner <leisner@sdsp.mc.xerox.com>. A new
+ documentation file, 00XCONFIG, describes the process.
+
+ Made Pyramid OBJFS support conditional on the
+ presence of supporting header files. Corrected
+ the Pyramid MkKernOpts script so it generates the
+ necessary -D's for the Nile/Jolt architecture.
+ Richard Coley <rcoley@pyra.co.uk> helped.
+
+ Added another IRIX xfs_inode variant for 6.2, 32
+ bits, no XFS rollup patch.
+
+ Tested under UnixWare 2.1.2.
+
+4.13 July 9, 1997
+ Taught Pyramid lsof to grok ttyfs vnodes with help
+ from Richard Coley <rcoley@pyra.co.uk>. Fixed some
+ minor bugs in Pyramid FIFO reporting. Eliminated
+ use of the Pyramid UCB compatibility library at
+ Richard's suggestion.
+
+ Eliminated reporting of "strange" inode numbers
+ for SCO OSR 3.2v5.0.x HPPS files with help from
+ Bela Lubkin <belal@sco.com>
+
+ Modified port to service name lookup to use a small
+ number of getservbyport() calls before reading the
+ entire map with getservent(). Changed port reporting
+ to represent a zero as `*' to be consistent with
+ other prt number reporting tools like netstat.
+ Casper Dik <casper@holland.Sun.COM> suggested these
+ changes -- the getserv*() one to improve performance
+ for large NIS service name maps.
+
+ Changed all readdev() functions to make the absence
+ of block devices a warning instead of a fatal error
+ after Brian Redman <ber@ms.com> reported his IRIX
+ 6.4 system had no block devices. (It really did
+ have block devices, but readdev()'s lstat() use
+ caused it to miss them in a directory symbolically
+ linked from /dev/dsk->/hw/disk.) Fixed Brian's
+ real problem by changing the IRIX readdev() to use
+ stat() on /dev nodes if a Configure test shows /hw
+ is readable. Extended the potential to do the same
+ to all readdev() functions.
+
+ For consistency and convenience changed some
+ Configure abbreviations and dialect subdirectory
+ names: "decosf" abbreviation and "osf" dialect
+ subdirectory name to "du"; "netbsd" dialect
+ subdirectory name to "n+obsd"; "next3" abbreviation
+ and "next" dialect subdirectory name to "ns"; "sco"
+ abbreviation and dialect subdirectory name to "osr";
+ "sgi" dialect subdirectory name to "irix"; and
+ "unixware" abbreviation and dialect subdirectory
+ name to "uw".
+
+ Added #if/#endif clauses to the AIX rmdupdev()
+ function to avoid clone processing for AIX versions
+ less than 4.1.4. The problem was reported by Toralf
+ Foerster <toralf.foerster@io-warnemuende.de>, who
+ supplied corrective code.
+
+ Added support for new style NetBSD inode with i_ffs
+ and i_e2fs union members.
+
+ Improved Configure and 00FAQ information on Digital
+ UNIX configuration subdirectory with suggestions
+ from Brad Krebs <brad@EECS.Berkeley.EDU>.
+
+4.14 July 22, 1997
+ Reorganized the Solaris handling of the inode
+ structure header file, ufs_inode.h, to eliminate
+ VxFS structure definition conflicts for Solaris
+ 2.4, based on information from Greg Earle
+ <earle@netbsd4me.jpl.nasa.gov>.
+
+ Cleaned up some typos and confusion in Configure's
+ help output, based on comments from Bela Lubkin
+ <belal@sco.com>
+
+ Added a 00DIALECTS file, containing UNIX dialect
+ version numbers, that can be used by Configure and
+ the man page.
+
+4.15 August 15, 1997
+ Aligned `Configure -help` output better. Removed
+ Configure's 2.6 Beta test adjustments.
+
+ Added improved Solaris VxFS configuration and
+ handling, based on information from Greg Earle
+ <earle@netbsd4me.jpl.nasa.gov>.
+
+ Added socket state -- TCO or TPI -- for socket
+ files at the suggestion of Ian Fitchet
+ <I.D.Fitchet@ftel.co.uk>.
+
+4.16 September 25, 1997
+ Added reporting of TCP/TPI queue lengths and window
+ sizes ala netstat to NAME column. Added -T option
+ to select or de-select TCP/TPI info reporting.
+ (Window sizes are only reported for Solaris.)
+ Fixed anomalies along the way in SIZE/OFF processing
+ for some dialects.
+
+ Fixed service name argument processor to allow
+ minus signs as part of the name. Consequently this
+ disallows names with embedded minus signs from
+ being specified as the start of a range.
+
+ Added 00FAQ entries explaining why lsof won't find
+ a file being edited with vi, why window sizes aren't
+ reported for all dialects, and what the "no more
+ information" message means.
+
+ Forced Pyramid CC to be /usr/ccs/bin/cc to avoid
+ accidental use of the BSD variant in /usr/ucb/cc.
+
+ Added support for Linux glibc2, including a Configure
+ test; cross-Configure support (00XCONFIG); and much
+ unfortunate and risky sleight-of-hand in lsof Linux
+ dialect header and source files, forced upon lsof
+ by incompatibilities between Linux kernel and glibc2
+ header files.
+
+ Included in scripts/identd.perl5 a Perl 5 implementation
+ of an identd server, using lsof, provided by Kapil
+ Chowksey <kchowksey@hss.hns.com>.
+
+ Updated IRIX 6.4 xfs_inode guess.
+
+4.17 October 14, 1997
+ Added -V option for verbose search result reporting.
+ Verbose reports are prepared for failure to locate
+ file names, command names, Internet addresses or
+ files, login names, NFS files, PIDs, PGIDs, and UIDs.
+
+ Augmented Linux NFS file test to cope with kernels
+ whose NFS code is in a loadable module. Need for
+ the test was pointed out by Jonathan Sergent
+ <sergent@csociety.ecn.purdue.edu>. The change
+ required that Linux have private dmnt.c source,
+
+ Completed a Linux 2.1.57 port on a system provided
+ by Jonathan Sergent.
+
+4.18 October 25, 1997
+ Eliminated memory leaks in alloc_lfile(), lkup_port(),
+ and NEXTSTEP's process_text() function.
+
+ Added recognition of OpenBSD 2.2 in Configure,
+ supplied by Kenneth Stailey <kstailey@disclosure.com>.
+
+ Consolidated print_file() functions to use the one
+ in lib/prtf.c. Made it configurable and changed
+ it to size print columns dynamically.
+
+ !!! WARNING !!!
+
+ WITH DYNAMICALLY SIZED PRINT COLUMNS LSOF 4.18
+ PRODUCES OUTPUT SIGNIFICANTLY DIFFERENT FROM THAT
+ OF PREVIOUS REVISIONS. LINES ARE GENERALLY SHORTER
+ AND THERE IS GENERALLY LESS BLANK SPACE BETWEEN
+ COLUMNS AND THE ITEMS IN THEM. THERE ARE NO LONGER
+ ANY SPACES BETWEEN DEVICE NUMBER ELEMENTS, ONLY
+ COMMAS.
+
+ !!! WARNING !!!
+
+ Added special types and print specification modifiers
+ for file size and offset to handle UNIX dialects
+ with 64 bit sizes and offsets. Paul Eggert
+ <eggert@twinsun.com> reported the need for this
+ addition.
+
+ With Paul Eggert's help picked lint from the lsof
+ library, the main level lsof sources, and the Sun
+ dialect sources.
+
+ Added documentation, including the file 00LSOF-L,
+ about the lsof-l LISTSERV.
+
+ Added support for Reliant UNIX on the RM600. Bob
+ Passarella <rmpassar@pyramid.com> supplied the
+ changes. Kevin Smith <kevin@pyramid.com> helped
+ arrange test systems. While incorporating Bob's
+ changes, modified lib/rnch.c to handle kernel ncache
+ structs whose name is accessed via a char *, rather
+ than in a char array.
+
+ Changed #include order of <sys/socketvar.h> for
+ Solaris 2.x. W. Richard Stevens <rstevens@kohala.com>
+ pointed out the need to do this.
+
+4.19 October 30, 1997
+ Changed Pyramid Reliant RM600 proc scan to skip
+ SSYS (p_flag) processes, since they don't seem to
+ have a readable u_cdir vnode.
+
+ Enabled Pyramid Reliant UNIX kread() work-around
+ for DC/OSx, too, since its read(/dev/kmem) kernel
+ driver seems to share the page boundary bug this
+ work-around circumvents.
+
+ Changed SzOffFtm_d and SzOffFtm_dv (new formats at
+ 4.18 to print size and offset) from signed to
+ unsigned. Setting them signed at 4.18 was an
+ oversight.
+
+ Plugged a memory leak that caused the loss of 130
+ bytes per repeat-mode pass. Fixed it with a simple
+ work-around in main(). Lionel Cons <Lionel.Cons@cern.ch>
+ reported the leak.
+
+4.20 November 11, 1997
+ Tested under BSDI 3.1.
+
+ Added support for Reliant UNIX Mesh IPC files with
+ help from Billy Ho <bho@pyramid.com>.
+
+ Added support to Digital UNIX lsof that uses the
+ libmsfs tag_to_path() function (when it exists) to
+ look up AdvFS path names. The idea and sample code
+ came from Dean Brock <brock@cs.unca.edu>. Converted
+ Dean's code into more general purpose support for
+ private name cache lookups via the HASPRIVNMCACHE
+ #define in the dialect machine.h file and code
+ conditional on it in the printname() function.
+
+ Taught Digital UNIX lsof to recognize NFS3 file
+ systems. Corrected Digital UNIX lsof DEVICE column
+ alignment.
+
+4.21 December 1, 1997
+ Squashed bug, introduced at revision 4.18, that
+ resulted in double reporting of each selected PID
+ when terse mode (-t) was specified.
+
+ Corrected minor bug, also introduced at 4.18, that
+ might cause an extra print_proc() pass when one
+ PID has been specified.
+
+ Added -R to lsof options in scripts/idrlogin.perl*.
+ The option should have been there -- it was supposed
+ to be mandatory for PGID reporting -- but a bug,
+ corrected in revision 4.18, previously made -R
+ unnecessary.
+
+ Enabled configuring for BSDI BSD/OS 4.0 per a
+ suggestion from Jeff Honig <jch@bsdi.com>.
+
+ Enabled replacement of scoff_t with off64_t (scoff_t
+ is used to type r_size and r_localsize in the rnode
+ struct) for IRIX 5.3 systems that have the NFS
+ kernel rollup patch (1477). This compensates for
+ SGI's failure to distribute an updated <sys/fs/rnode.h>
+ with their patch.
+
+ Validated under Linux 2.0.3[12], Linux 2.1.64, and
+ NetBSD 1.3.
+
+ Added FreeBSD root directory reporting, courtesy
+ of Dan Nelson <dnelson@emsphone.com>.
+
+4.22 December 15, 1997
+ Made adjustments for Linux 2.1.7[02].
+
+ Improved NAME information for Linux UNIX domain
+ sockets.
+
+ Added option +|-M to control the reporting of
+ portmapper registration information in square
+ brackets after the TCP or UDP port or service name.
+ Kenneth Stailey <kstailey@disclosure.com> suggested
+ the feature and provided sample code from OpenBSD.
+ Reporting is disabled by default in the distribution
+ and may be enabled with +M; if lsof is compiled
+ with HASPMAPENABLED (e.g., from machine.h), reporting
+ will be enabled by default and can be disabled with
+ -M.
+
+ Changed the -w option to +|-w to match the syntax
+ of the +|-M option and to eliminate any options
+ that flip meaning when a symbol is defined at
+ compile time. For both +|-M and +|-w, specifying
+ `-' when the default state is disabled or specifying
+ `+' when the default state is enabled causes no
+ problems.
+
+ !!!WARNING The -w option has changed in lsof 4.22. WARNING!!!
+
+ Made the +|- prefix legal for most options, but
+ didn't document it in the man page or help panel.
+ Most options that disable something -- e.g., -b,
+ -C, -n, -P -- now disable when the prefix is `-'
+ and enable when it is `+'. Since the states these
+ options disable are enabled by default, I chose to
+ avoid documentation complexity and confusion by
+ not mentioning that they can be used with the `+'
+ prefix.
+
+ Condensed the help panel.
+
+ Made sure Digital UNIX Configure stanza puts normal
+ include path (e.g., /usr/include) before system
+ include paths.
+
+ Added IPX socket information reporting to Linux
+ with help from Jonathan Sergent <sergent@purdue.edu>.
+
+4.23 January 16, 1998
+ Fixed conflict arising from the quondam replacement
+ of the Sun Solaris <netdb.h> with a BIND/BSD version.
+
+ With help from Jonathan Sergent <sergent@purdue.edu>
+ developed a /proc file system based Linux lsof.
+ It needs some Linux 2.1.x release to work -- I'm
+ not sure which, but I tested under 2.1.72, 2.1.76,
+ and 2.1.79. The Configure script selects special
+ sources for this lsof, so the full lsof distribution
+ now contains both /dev/kmem and /proc based sources
+ for Linux lsof. An optional kernel mod, written
+ by Jonathan, enhances the /proc-based lsof ability
+ to recognize IPX socket files. Reorganized and
+ augmented the Linux sections in 00FAQ to explain
+ the two types of Linux lsof.
+
+ Defined DOSTAT_FUNCTION for dostat() in misc.c to
+ select the function, stat() or lstat(), it will use.
+ DOSTAT_FUNCTION is normally undefined, defaults to
+ lstat(), and is only defined for the /proc-based
+ Linux lsof in its dlsof.h.
+
+ Made conditional on the presence of IRIX 6.4 XFS
+ rollup patch #6 an XFS node change introduced in
+ revision 4.16. Identified the patch with help
+ from John R. Vanderpool <fish@daacdev1.gsfc.nasa.gov>.
+
+ Added NFS node compensation for NetBSD 1.3. The
+ code and suggestion for it was supplied by Jean-Luc
+ Richier <richier@imag.fr>.
+
+ Added diagnostic messages to the /dev/kmem-based
+ Linux Mksrc script to report errors during the
+ construction of the kernel name cache header file,
+ kncache.h. Added 00FAQ information on kncache.h.
+
+ Added a new Linux test host, running 2.0.33 and
+ GlibC, provided by Steve Logue <stevel@mail.cdsnet.net>.
+
+ Ported to PTX 4.1.3 and 4.4.2. Adjusted lib/rnch.c
+ for 4.4.2 to allow customization f additional ncache
+ struct element names.
+
+4.24 January 28, 1998
+ Changed /proc-based Linux lsof offset test to use "/"
+ instead of "/etc/passwd".
+
+ To assist Jim Mintha <jim@geog.ubc.ca> with the
+ packaging of lsof for Debian Linux, added a
+ DEBIAN_LINUX_LSOF #define to trigger the activation
+ of special system map file location code in the
+ /dev/kmem-based dproc.c.
+
+ Applied modification to dialects/bsdi/dlsof.h from
+ Ingimar Robertson <iar@skyrr.is>, enabling lsof to
+ compile for BSDI BSD/OS 2.0.
+
+ Corrected a documentation error in 00DCACHE, pointed
+ out by Thomas Anders <anders@hmi.de>. The error was
+ created when the -V option was added at lsof 4.17.
+
+ Made IRIX 5.3 through 6.3 lsof aware of IRIX SCSI
+ tape devices (e.g., /dev/tape). Dave Olson of SGI
+ and Randolph J. Herber of FNAL provided valuable
+ advice, and Igor Schein <ischein@air-boston.com>
+ helped test.
+
+ Added a machine.h symbol (NEVER_HASDCACHE) that
+ prevents Customize from offering to change HASDCACHE.
+ The symbol may appear anywhere in machine.h --
+ e.g., in a comment. Included the symbol in a
+ comment of the HASDCACHE section of the /proc-based
+ Linux lsof machine.h, and accompanied it with
+ warnings against #define'ing HASDCACHE. Did the
+ same thing for WARNDEVACCESS (NEVER_WARNDEVACCESS
+ is the suppressant.)
+
+4.25 February 7, 1998
+ Corrected an IRIX mis-cast of file offset (position).
+ Igor Schein <ischein@air-boston.com> reported the
+ problem. This was offered as a patch to 4.24.
+ Picked some lint Igor pointed out.
+
+ At Igor's suggestion added an optional decimal
+ digit size argument to the -o option. This argument
+ specifies how many file offset decimal digits can
+ follow "0t" before lsof switches to a "0x..." form.
+ The argument size specification doesn't count the
+ two characters of the "0t". A size of 0 means
+ unlimited. The default is OFFDECDIG (8), preserving
+ compatibility with existing lsof output; it can be
+ changed by the lsof builder. When size is specified
+ with -o it does not force offset display; -o without
+ a size still must be used to do that.
+
+ Added an IRIX 6.2, 32 bit system, XFS node patch,
+ courtesy of Ulrich Bernhard <rzubu@rzu.unizh.ch>.
+
+ For my own convenience enabled Configure to use
+ /usr/local/bin/gcc for NEXTSTEP. This allows
+ circumvention of a gcc 2.8.0 ranlib problem on
+ my test 3.1 `040 cube.
+
+ Added flags recommended by the RISC/os and Ultrix
+ compilers for the updated (and longer) main.c.
+
+ Updated FreeBSD cd9660_node.h Configure test.
+
+4.26 February 17, 1998
+ Added shared process group processing for IRIX 5.3,
+ and IRIX 6.1 and above, based on investigation of
+ a bug report from Igor Schein <ischein@air-boston.com>.
+ Igor helped test this addition.
+
+ Improved handling of file system name arguments.
+ It's now done in a manner similar to fuser. The
+ -f argument forces path names to be considered as
+ simple files, rather than as file system names.
+ The +f flag forces them to be considered as file
+ system names. Normally path arguments are considered
+ file system names when they match a mounted-on
+ directory in the system's mount table, or when they
+ match a mounted file system's block device. Igor
+ Schein helped test this change.
+
+ Igor also suggests that the proper compilation of
+ the IRIX 6.4 proc structure after patch 2536 has
+ been installed may need -DPIOMEMOPS. So lsof's
+ MkKernOpts script was updated to propagate that
+ option from CCOPTS in /var/sysgen/system/irix.sm,
+ even though patch 2536 doesn't add -DPIOMEMOPS to
+ it. Added a 00FAQ item on this patch.
+
+ Added a fatal warning message about names forced
+ to be file system names (with +f) that have no
+ match in the mount table.
+
+ Improved the -V message for files and file systems
+ for which no open files were found. Added reporting
+ of /proc file and file system search failures.
+
+ Did some code reorganization to combine the multiple
+ ck_file_arg() functions into one. Moved the new
+ function from the library to the top level and put
+ it in arg.c; moved the usage function from arg.c
+ to a new top-level source file, usage.c, to balance
+ top-level source file size. The new usage.c depends
+ on version.h; arg.c no longer does.
+
+ Added flag recommended by the DU compiler for the
+ updated (and longer) main.c.
+
+4.27 March 6, 1998
+ At the request of Igor Schein <ischein@air-boston.com>
+ added a conditional repeat mode option, using the
+ `+' prefix to the `r' option. +r operates as does
+ -r with the exception that it exits the first time
+ no open files have been listed during a cycle.
+ The exit code will be zero when any open files have
+ been listed; one, if none were ever listed.
+
+ Ported lsof to HP-UX 11.0 with the help of Richard
+ Allen. This port hasn't been tested on a 64 bit
+ kernel; I'm sure it won't work there without more
+ mods. It may not work on PA 2 architectures; I've
+ only tested it under PA 1 and a separate, busy
+ tester reported PA 2 problems that I've been unable
+ to investigate.
+
+ In anticipation of getting access to a 64 bit HP-UX
+ kernel and the pending start of the Solaris 2.7
+ Beta test (It will have 64 bit kernel addressing.),
+ started adding support for 64 bit kernel pointers.
+ This includes: ubiquitous use of the KA_T cast
+ for kernel pointers; a format to print them,
+ KA_T_FMT_X; a function to print them, print_kptr();
+ and modifications to most kernel-related functions
+ -- e.g., process_file(), process_node(),
+ process_socket(), readvfs() -- to process kernel
+ addresses as KA_T types.
+
+ Fixed minor bug in handling path name arguments
+ that end with a `/'.
+
+ Removed support for RISC/os; its test system is no
+ longer available.
+
+ Made modifications to insure that lsof output
+ doesn't contain non-printable characters. All such
+ characters are now printed in the printf form
+ "\x%02x". Several new common functions were
+ installed in misc.c to support "safe" printing.
+ This second major modification in 4.27 to common
+ and dialect code could have introduced bugs not
+ yet detected.
+
+4.28 March 10, 1998
+ Refined unprintable format to use \b, \f, \r, \n,
+ \t, and ^* (for CTRL) forms. Corrected omission
+ of safestrprt() use for field output command name.
+ These changes were offered as patches to 4.27.
+
+ Made space an unprintable character (\x20) in the
+ COMMAND column; printable elsewhere, including the
+ NAME column, field output, and error messages.
+
+ Made sure FD column is parseable as a single entity
+ -- i.e., has no embedded space. Thus, if the access
+ mode is unknown but there is a known lock mode, (a
+ very rare case) the access mode will be printed as
+ `-'.
+
+ Picked lint with gcc 2.8.0 under Solaris 2.6.
+
+ With the help of Dave Olson of SGI identified a
+ proc struct element that should have been added to
+ <sys/proc.h> by IRIX 6.4 patch 2536. Added a
+ work-around for it to the lsof Configure script.
+ Igor Schein <ischein@air-boston.com> identified
+ that the patch caused a proc structure length
+ complaint from lsof. Removed an obsolete 00FAQ
+ item on the patch, installed at lsof 4.26, explaining
+ that no solution was yet available.
+
+ Added a 00FAQ item on how BIND installs its own
+ header files, including <netdb.h>, which may cause
+ the rpcent struct definition to vanish. Solaris
+ has an automatic lsof work-around, but that hasn't
+ been (and probably can't be) propagated to all
+ dialects supported by lsof. The 00FAQ item recommends
+ re-installation of the vendor header files that
+ BIND has replaced. (Others include <rpcent.h>,
+ <sys/bitypes.h>, and <sys/ctypes.h>.)
+
+ Made AIX AFS fixes.
+
+4.29 March 26, 1998
+ Corrected bug in Internet address matching. The
+ matching formerly stopped if the foreign address
+ matched, thus failing to check the local address
+ for a match. That led to a possible false "Internet
+ address not located" warning (i.e., in response to
+ -V) about the local address, when both foreign and
+ local addresses were specified with -i. This
+ correction was offered as a patch to 4.28.
+
+ Changed readmnt() usage in an attempt to defer
+ mount readlink() and stat() delays until they are
+ necessary.
+
+ Corrected two bugs in the Digital UNIX readdev()
+ function. Made the correction available as a patch
+ to 4.28 and regenerated the 4.28 DU binaries.
+
+ Added a missing argument to a print-kptr() call in
+ the HP-UX dsock.c. The missing argument causes a
+ fatal gcc error. The problem was reported by Eyal
+ Shaynis <eyal.shaynis@telrad.co.il>. The fix was
+ offered as a 4.28 patch.
+
+ Adjusted for Digital UNIX 4.0D; the spec_node
+ structure is now defined in <sys/specdev.h>. Kris
+ Chandrasekhar <Kris.Chandrasekhar@digital.com>
+ identified the need for the adjustment.
+
+ Incorporated a bug fix from Brian McAllister
+ <mcallister@mit.edu> to the DU readmnt() function.
+ This fix was offered as a patch to 4.28.
+
+ Added "safe" printing to a SunOS clone device error
+ message.
+
+ Corrected bug in tabling of Linux /proc-based lock
+ info.
+
+ Corrected bug in handling of SunOS TLI streams.
+ Dan Farmer <zen@trouble.org> reported the problem.
+
+ Added a Solaris 2.6 work-around to keep the BIND
+ <sys/bitypes.h> from colliding with the Solaris
+ <sys/int_types.h>.
+
+ Strengthened the Configure test for /proc-based
+ Linux lsof, based on a report from Marty Leisner
+ <leisner@sdsp.mc.xerox.com>.
+
+ Tested on OpenBSD 2.3.
+
+ Made AIX changes that allow use with 3.2.5. The
+ changes were suggested and tested by Brett Hogden
+ <hogden@rge.com>.
+
+ Added Solaris 2.6 AFS support. Disabled reporting
+ of some node numbers for Solaris 2.5 and above open
+ AFS files. The node number computation algorithms
+ used for SunOS 4.1.x and Solaris less than 2.5 no
+ longer always work under Solaris 2.5 and above.
+
+4.30 April 9, 1998
+ Corrected a pid structure member naming error for
+ UnixWare < 2.1.2. The problem was reported by
+ Richard van Meurs <vanmeurs.anva@atriserv.nl>. He
+ supplied the correction. This was offered as a
+ patch to 4.29.
+
+ Had a report from Igor Schein <ischein@air-boston.com>
+ that IRIX 6.4 patch 2839 is another SGI kernel
+ patch, along with 2536, that changes the size of
+ the proc structure in the kernel without changing
+ the proc structure in <sys/proc.h>. Upon further
+ investigation found that the effect of these patches
+ on the proc structure is not consistent. Therefore,
+ dropped the Configure patch test for IRIX 6.4 and
+ made the code in irix/dproc.c slightly more tolerant
+ of proc structure size differences for IRIX 6.4.
+ Igor help test the change.
+
+ Corrected Solaris >= 2.5 AFS inode number generation.
+ Craig Everhart <Craig_Everhart@transarc.com> helped
+ find the cause of the problem. This was offered as
+ a patch to 4.29.
+
+ Refined the Linux /dev/kmem-based glibc evasion
+ for the timeval structure to make it work with
+ glibc version 2.0.7. This required defining a new
+ global symbol, TIMEVAL_LSOF, default timeval, that
+ the /dev/kmem-based Linux lsof can set to its
+ private glibc timeval name, distinct from the kernel
+ timeval name.
+
+ Added support for Alpha to the /dev/kmem-based
+ Linux lsof. Alexandre Oliva <oliva@dcc.unicamp.br>
+ provided a test system. Added an item to 00FAQ
+ about lsof, the Alpha processor, and Linux.
+
+ Added a 00FAQ item about lsof year 2000 compliance.
+ Basically it says lsof is probably compliant,
+ because its only date or time computations are done
+ with time_t values, but I haven't done any specific
+ Y2K validation. I don't have plans to do any.
+
+ Added support for UnixWare 7. Chris Daniels
+ <chrisd@dlpco.com> provided a test system and Don
+ Draper <dond@sco.COM> provided technical information.
+ Added BFS and SFS file system support to lsof for
+ UW 2.1.[12] and 7.
+
+ Updated Solaris VxFS support for VxFS 3.2.1. Greg
+ Earle <earle@netbsd4me.jpl.nasa.gov> reported the
+ need for the update. Greg and Roger Klorese
+ <rogerk@veritas.com> provided technical information.
+ Scott McClung <mcclung@primenet.com> tested.
+
+ Changed IRIX XFS patch detection in anticipation of
+ learning there are multiple XFS patches for IRIX 6.4
+ that require different versions of the lsof-invented
+ xfs_inode structure.
+
+4.31 April 21, 1998
+ Added a VxFS #if/#endif wrap to a section of the
+ HP-UX dnode.c that wasn't properly protected. The
+ problem was reported by Peter Klosky <PKlosky@bdm.com>.
+ This was offered as a patch to 4.30.
+
+ Added support for Solaris 2.7 (first Beta release).
+ Mike Sullivan <Mike.Sullivan@Eng.Sun.COM> provided
+ technical advice and helped test. Charles Stephens
+ <cfs@jurassic.eng.Sun.COM> also helped test.
+
+ Fixed bug in /proc-based Linux that caused it to
+ access /proc/mounts excessively. Marty Leisner
+ <leisner@sdsp.mc.xerox.com> provided a syscall
+ trace that identified the bug. The fix was offered
+ as a patch to 4.30.
+
+ Adjusted the IRIX 6.4 private structure definition
+ for the XFS node to accommodate patch 2970. Igor
+ Schein <ischein@air-boston.com> identified the
+ patch and the required adjustment.
+
+4.32 May 11, 1998
+ Corrected Solaris 2.7 code for reporting PCFS
+ (floppy disk) node numbers. Casper Dik
+ <casper@holland.sun.com> supplied the fix. The
+ fix was offered as a patch to 4.31.
+
+ Corrected a bug in conditional repeat mode handling
+ pointed out by Igor Schein <ischein@air-boston.com>.
+ This was offered as a patch to 4.31.
+
+ Improved reporting of AIX open(/dev/memory device)
+ errors.
+
+ Corrected a Solaris < 2.5 KA_T declaration error,
+ pointed out by Robert Kiessling <robert@easynet.de>.
+ Changed KA_T from a #define to a typedef for all
+ dialects to prevent future problems of this kind.
+
+ Changed the sample Perl 5 script big_brother.perl5
+ to report a four digit year from localtime().
+
+ Added support for AIX 4.3[.1]. Bill Pemberton
+ <wfp5p@tigger.itc.virginia.edu> provided a test
+ system. Andrew Kephart <akephart@austin.ibm.com>
+ and Tom Weaver <tvweaver@austin.ibm.com> provided
+ technical assistance. Niklas Edmundsson
+ <nikke@ing.umu.se> did 4.3.1 testing.
+
+ Added -qmaxmem option to CFLAGs for an AIX compilation
+ with an xlc version 4.x compiler.
+
+ Adjusted Linux socket handling for changes in the
+ AX25 members of the sock struct. Richard Green
+ <rtg@tir.com> pointed out the problem. Tested
+ /dev/kmem-based lsof under Linux 2.0.34.
+
+4.33 May 22, 1998
+ Added generic IPv6 support to common lsof sources
+ and specific IPv6 support to AIX sources. Andrew
+ Kephart <akephart@austin.ibm.com> supplied the
+ additions and helped with testing. Bill Pemberton
+ <wfp5p@tigger.itc.virginia.edu> provided a test
+ system. The modification affected sources for
+ every dialect, whether it supports IPv6 or not, by
+ changing the interfaces to the common Internet
+ address function ent_inaddr().
+
+ Added support for the NetBSD UVM virtual memory
+ system. Paul Kranenburg <pk@cs.few.eur.nl> supplied
+ technical details.
+
+ Bracketed HP-UX 11 use of <sys/spinlock.h> with
+ #if/#endif _KERNEL.
+
+ Corrected printing of PCB address in DEVICE column
+ for IRIX.
+
+4.34 June 26, 1998
+ Updated 00FAQ to discuss TCP and UDP ports private
+ to the AIX kernel and 00README to describe how ACLs
+ can be used to give lsof permission to read the
+ kernel memory devices. Add information to 00FAQ
+ and 00README about other OpenBSD architectures
+ where lsof is reported to compile and run. Added
+ section to 00FAQ discussing how an incorrect loader
+ path environment variable value can prevent lsof
+ from loading correctly.
+
+ Improved Solaris namefs and doorfs support so that
+ it is now possible to search for an open VDOOR file
+ by the path name of its fattached file system
+ object. Igor Schein <igor@txc.com> requested the
+ ability to do such a search. Even with the change,
+ lsof can't always identify path names for open
+ VDOOR files.
+
+ Also at Igor's request, improved reporting of
+ information on open Solaris VCHR files that share
+ a common vnode, and Solaris UNIX domain socket
+ files.
+
+ Corrected print_kptr() argument error in PTX dnode.c,
+ reported by Mark Price <mprice@sequent.com>.
+ Compensated for ncache element naming differences,
+ introduced at PTX 4.4.2; Kurtis D. Rader
+ <krader@sequent.com> reported the problem.
+
+ Changed output column title from INODE to NODE to
+ better reflect the column's contents of node IDs
+ for more than just inodes.
+
+ Improved Configuration and processing for Solaris
+ AFS. Corrected AIX AFS 3.4 afs_rwlock_t simulation.
+
+ Corrected a cast problem with two AIX knlist()
+ calls, thus quieting an AIX 4.2.1 compiler argument
+ type warning. Jon Champlin <champlin@us.ibm.com>
+ reported the problem.
+
+ Added support to most dialect versions (exception:
+ /proc-based Linux) to warn when the identity of
+ the kernel where lsof was compiled doesn't match
+ the running identity. The warning can be suppressed
+ with -w. Note: determining AIX state requires
+ calling oslevel, a potentially slow operation.
+ Jon Champlin <champlin@us.ibm.com> suggested this
+ addition.
+
+ !!!! WARNING !!!! !!!! WARNING !!!! !!!! WARNING !!!!
+
+ Those using the lsof cross-configuration capability
+ (see 00XCONFIG), should be aware that the kernel
+ identity test feature introduces two new basic
+ cross configuration environment variables, LSOF_ARCH
+ and LSOF_VSTR.
+
+ !!!! WARNING !!!! !!!! WARNING !!!! !!!! WARNING !!!!
+
+ Identified a situation where a Solaris UNIX domain
+ socket name is known and can be searched for by
+ name; added the necessary code.
+
+4.35 July 17, 1998
+ Made the kernel identity check an option with the
+ HASKERNIDCK #define in machine.h. Enabled altering
+ of HASKERNIDCK with the Customize script. Added
+ a clause to the help output that indicates the
+ build-time HASKERNIDCK status.
+
+ Added more information to the NAME column for
+ Solaris UNIX domain sockets. Made them searchable
+ by their clone device path name. Igor Schein
+ <igor@txc.com> requested this.
+
+ Completed the HP-UX 11 port with support for its
+ optional 64 bit kernel. Rich Rauenzahn
+ <rrauenza@cup.hp.com> provided a test system.
+ Corrected errors with HP-UX 11 lock reporting and
+ private kernel structure and type definitions.
+ Added support for HP-UX NFS3 files.
+
+ Limited mount table warnings -- e.g., when -b is
+ used -- to one set per mount point.
+
+ Fixed some mount table scanning and usage bugs,
+ including one in Solaris, reported by Kjetil Torgrim
+ Homme <kjetilho@ifi.uio.no>.
+
+4.36 August 4, 1998
+ Made corrections and additions to IPv6 support and
+ to AF_ROUTE socket handling, supplied by Jean-Luc
+ Richier <Jean-Luc.Richier@imag.fr>. Jean-Luc's
+ additions provide IPv6 support for the Inria IPv6
+ implementations on FreeBSD and NetBSD.
+
+ Fixed two Solaris 2.5, 2.5.1, 2.6 and 2.7 TCP and
+ UDP host name or IP address reporting bugs, reported
+ by James Mathiesen <James-Mathiesen@deshaw.com>.
+ This fix was offered as a patch to 4.35.
+
+ Updated the Customize script to cause ENTER to use
+ all defaults. Amir J. Katz <amir@ndsoft.com>
+ suggested this and helped test the changes.
+
+ Updated Solaris ICMP and IP stream handling, based
+ on a report from Igor Schein <igor@txc.com>.
+
+ Fixed a bug in the Digital UNIX mount table handling,
+ reported by Bob Ward <bward@thehartford.com>.
+ While working on the bug, found and updated some
+ obsolete AdvFS code. This fix was offered as a
+ patch to 4.35.
+
+4.37 September 15, 1998
+ Deactivated SGI IRIX support and archived revision
+ 4.36 sources and binaries in pub/tools/unix/lsof/OLD.
+
+ Improved performance of FD searching. This was
+ offered as a patch to 4.36.
+
+ Amir J. Katz <amir@ndsoft.com> pointed out that
+ ranlib isn't needed for AIX or Solaris. Made
+ appropriate Configure script changes.
+
+ Fixed a file offset reporting bug for HP-UX VCHR
+ and VBLK device nodes located on a VxFS root. Doug
+ Siebert <douglas-siebert@iowa.edu> reported the
+ bug. The fix was offered as a patch to 4.36.
+
+ Resolved an HP-UX root device name reporting bug,
+ partly caused by an out-dated local copy of the
+ <sys/mount.h> mount structure, by generating a
+ local header file with the structure that can be
+ compiled without needing _KERNEL defined. Doug
+ Siebert also reported this bug.
+
+ Changed some dialect source code -- Digital UNIX,
+ Solaris, SunOS, and UnixWare -- to make more
+ consistent with ps the user ID lsof reports in the
+ USER column. Added a 00FAQ entry about it. Igor
+ Schein <igor@txc.com> reported the Solaris and
+ SunOS lsof inconsistencies with what ps(1) reports.
+
+ Ported lsof to Pyramid ReliantUNIX 5.44.
+
+ Added brackets as comments to case, do, done, else,
+ endif, esac, if, and while statements in Configure
+ to assist in navigating its clauses.
+
+ Added more Linux 2.0.x glibc work-arounds.
+
+ Added support for UnixWare 7.0.1.
+
+ Ralph Forsythe <ralph@contact-paging.com> provided
+ a new FreeBSD test system.
+
+4.38 November 25, 1998
+ Added support for recent FreeBSD 3.0 distributions.
+ A 3.0 test system was provided by David O'Brien
+ <obrien@NUXI.com>. This was offered as a patch
+ to 4.37.
+
+ Updated the scripts/idrlogin.perl* files to look
+ for sshd processes in addition to rlogind and
+ telnetd ones.
+
+ Added support for DU 5.0 Beta. Berkley Shands
+ <berkley@cs.wustl.edu> provided a test system.
+
+ Added support for OpenBSD 2.4 with changes supplied
+ by Kenneth Stailey <kstailey@disclosure.com>.
+
+ Changed the Solaris 2.7 tests and documentation to
+ Solaris 7.
+
+ Made some changes to the header files for NEXTSTEP
+ 3.3 and added support for OPENSTEP 4.x with help
+ from Michael A. Hovan III <mhovan@BLaCKSMITH.com>
+ and Carl Lindberg <Carl_Lindberg@BLaCKSMITH.com>.
+ The combined dialect subdirectory is named n+os.
+ One of Carl's changes propagates RC_CFLAGS to the
+ library Makefile. Timothy J. Luoma <luomat@peak.org>
+ helped test under NEXTSTEP 3.3 and OPENSTEP 4.2.
+
+ Made UW 7.x version sensitive to the presence of
+ ptf7038. Added peer PCB address to Unix domain
+ socket Name column, even when a path name has been
+ located. Information for these changes was supplied
+ by Francis Le Bourse <flebourse@intelcom.fr>. Lee
+ Penn <lee@dlpco.com> provided a test system.
+
+ Tested lsof under OSR 5.0.5 on a test system also
+ provided by Lee Penn.
+
+ Made path name argument processing more tolerant
+ of errors per a suggestion from Julian Gordon
+ <julian@cadence.com>.
+
+ Acquired a new UnixWare 2.x test system, generously
+ provided by Computer Classroom, Inc. -- Matthew
+ Thurmaier <matt@compclass.com>, Ken Laing
+ <ken@compclass.com>, and Andrew Merril
+ <andrew@compclass.com>. Updated Configure to accept
+ a UnixWare version of 2.1.3.
+
+ Updated kmem-based lsof for Linux 2.0.36.
+
+ Updated NetBSD sources for a change in a UVM virtual
+ mapping header file.
+
+ Corrected a cache allocation bug in Sun format
+ kernel name cache handling. The bug only shows up
+ when the kernel name cache is inaccessible.
+
+4.39 December 29, 1998
+ Corrected problems with large device number handling
+ for 64 bit Solaris 7. The problems were reported
+ by Steve Bellenot <bellenot@math.fsu.edu>. Steve
+ helped test the fixes. The fixes were offered as
+ two patches to lsof 4.38.
+
+ Improved FreeBSD Configure operations for header
+ files that must be obtained from the kernel source
+ tree, based on a suggestion from David O'Brien
+ <obrien@NUXI.com>.
+
+ For Bela Lubkin <filbo@deepthought.armory.com> made
+ optional with +f[cfn] the display of file structure
+ address, shared use count, and node structure
+ address. /proc-based Linux doesn't implement this
+ feature, because it doesn't read kernel structures
+ from kernel memory. Modified the PTX -X option to
+ take advantage of the new file structure display
+ option. Added shared.perl5 to the scripts/
+ subdirectory to provide an example of how +f[fn]
+ might be used to track shared file descriptors and
+ files.
+
+ Added more /dev/kmem-based Linux glibc evasions,
+ provided by Jeff Johnson <jbj@redhat.com> and Maciej
+ Lesniewski <nimir@kis.p.lodz.pl>. Jeff helped test
+ them on various Linux architectures.
+
+ Tested on AIX 4.3.2; no changes were required.
+ Doug Crabill <dgc@purdue.edu> provided a test
+ system.
+
+ Fixed -c option to detect missing command name when
+ following option begins with `+'.
+
+4.40 January 25, 1999
+ Added support for using the CDS compiler for Reliant
+ Unix 5.44 and above. Made Reliant Unix MIPC support
+ optional, dependent on the presence of <sys/mipc.h>.
+
+ Based on a report from Michael Schmitz <MSchmitz@lbl.gov>
+ that /dev/kmem-based lsof misbehaves on a Linux
+ 2.0.x m68k kernel without module support, made the
+ absence of query_module() or get_kernel_syms()
+ Linux kernel support a fatal error. Updated relevant
+ sections of 00FAQ to reflect the change.
+
+ Added the ability to force the Linux Configure
+ stanza to use the /proc or /dev/kmem source base
+ via a LINUX_BASE environment variable specification.
+ This is a cross-configuration assist.
+
+ Added "+D <dir>" and "+d <dir>" options for directory
+ searching. +D searches the entire tree, starting
+ at <dir>, including <dir>, its contents, and its
+ subdirectory branches; +d searches only <dir> and
+ its contents, but not its subdirectory branches.
+ Improved lsof's searching of the specified name
+ list to compensate for anticipated long lists from
+ +d and +D.
+
+ Made an egrep in the Solaris Configure stanza usable
+ by the standard and XPG4 egrep's. Kenneth Stailey
+ <kstailey@disclosure.com> pointed out the improvement.
+
+ Fixed bugs in /dev/kmem-based Linux and UnixWare
+ Unix domain socket name searching.
+
+ Changed a Linux Alpha #include to be conditional
+ on the presence of its named header file, so that
+ lsof will compile on Red Hat 5.1 and 5.2 (Linux
+ kernel 2.0.35) where the header file is absent.
+ The problem was reported by Alexandre Oliva
+ <oliva@dcc.unicamp.br>.
+
+ Fixed an AIX 4.3+ bug in procinfo struct space
+ allocation, reported by Jeff Stewart <jws@purdue.edu>.
+ This was offered as a patch to 4.39.
+
+ Added an lstatsafely() function to offer the same
+ isolation for lstat() calls that statsafely() offers
+ for stat() calls. This made DOSTAT_FUNCTION no
+ longer necessary, so deleted it.
+
+ With help from Laurent P. Montaron <lpm@sequent.com>
+ ported lsof to PTX 4.4.4. Laurent did a monumental
+ job of identifying TCP/IP changes by their TCP
+ version, rather than by their PTX (With mix 'n
+ match PTX and TCP/IP versions, the PTX version
+ often has no bearing on the TCP/IP version.), and
+ changed the Configure script and pre-processor
+ #if/#else/#endif blocks to match. He also updated
+ Unix domain socket handling for PTX TCP/IP versions
+ 4.5 and above.
+
+ Updated CLIENT handle acquisition of fill_portmap()
+ in print.c to use the more modern RPC function
+ clnt_create() in place of clnttcp_create() where
+ possible. PTX 4.4.4 requires clnt_create().
+
+4.41 February 27, 1999
+ Added FreeBSD 3.1 and and 4.0 support with help
+ from Sheldon Hearn <axl@iafrica.com>, David O'Brien
+ <obrien@NUXI.com>, and John Polstra <jdp@polstra.com>.
+
+ Corrected bungled AIX 4.3+ patch that went into
+ lsof 4.40.
+
+ Reorganized the Configure script to improve Makefile
+ construction. A specific impetus for this was to
+ allow FreeBSD system-wide make flags to be propagated
+ to the lsof Makefiles, but other goals were to make
+ sure that the DEBUG= make entry can over-ride
+ standard CFLAGS values, and to better manage the
+ identification of compilers and their versions.
+ Two compiler-related values may now be supplied in
+ environment variables: 1) the compiler path in
+ LSOF_CC; and 2) the compiler version in LSOF_CCV.
+ 00XCONFIG documents them.
+
+ Added support for Pyramid Reliant Unix bsdsfs,
+ msockfs, and sockfs file systems.
+
+ Added an optional LSOF_CINFO string to Configure,
+ producing a CINFO string in selected Makefiles,
+ producing a #define LSOF_CINFO in selected version.h
+ header files. The purpose of this is to allow
+ Configure the option to propagate information to
+ the lsof -v output. It is now used for Linux to
+ identify the code base, and for HP-UX 10.30 and
+ 11.0 and Solaris 7 to identify the kernel bit size.
+
+ Added system information to NEXTSTEP and OPENSTEP
+ -v output, from the second line of hostinfo's
+ output.
+
+ Fixed a login name buffer overflow problem in the
+ processing of -u option values. This was offered
+ as a patch to 4.40. !!!THIS IS A SERIOUS STACK
+ OVERFLOW BUG; A LINUX EXPLOIT EXISTS FOR IT THAT
+ OPENS A BASH SHELL WITH LSOF'S AUTHORITY -- E.G,
+ SETGID(KMEM) POWER!!!
+
+ Improved the Solaris mount table filter so the
+ volume manager's fake mount point, "/vol", is
+ ignored and doesn't supplant "/" in NAME column
+ path assemblies. Igor Schein <igor@txc.com> reported
+ this bug and provided important help in finding
+ it. This was offered as a patch to 4.40.
+
+ Changed the Linux /dev/kmem-based lock ownership
+ test to answer a problem reported by Tom Christiansen
+ <tchrist@jhereg.perl.com>. This was offered as a
+ patch to 4.40.
+
+ Installed an HP-UX 11 patch, suggested by Kevin
+ Vajk <kvajk@cup.hp.com>, that adjusts a private
+ lsof kernel header file, derived via Q4, to correspond
+ to an HP-UX patch bundle.
+
+ Made NetBSD 1.3I sockproto structure adjustment.
+
+4.42 March 30, 1999
+ Fixed a typo in the HP-UX dfile.c that caused +fF
+ and +fN output controls to swap effect.
+
+ Enabled for OpenBSD 2.5 per notice from Kenneth
+ Stailey <kstailey@kstailey.tzo.com>
+
+ Made more VM accommodations for FreeBSD 4.0.
+
+ Improved file system search reporting to include
+ path name components when they're available, instead
+ of mindlessly reporting the file system name in
+ the NAME column. Guy Dallaire <gdallair@geocities.com>
+ brought the need for this change to my attention.
+
+ Updated Solaris 2.6 VxFS for Veritas Oracle Database
+ Edition 2.0, VxFS version 3.3, and VxVm version
+ 2.5.4, based on a report from Chris Kordish
+ <chris.kordish@East.Sun.COM>. Chris kindly provided
+ a test system.
+
+ Improved HP-UX ipc_s patch detection in Configure,
+ response in .../dialects/hpux/hpux11/ipc_s.h, and
+ documentation in 00FAQ, Kevin Vajk <kvajk@cup.hp.com>
+ helped test.
+
+ Added to Customize the option to suppress HASKERNIDCK
+ selection for specified dialects. Suppressed it
+ for /proc-based Linux lsof, and removed its test
+ and code from there. Tin Le <tin@netimages.com>
+ alerted me to the need for this update.
+
+ Ported to official Digital UNIX 5.0 release.
+
+ Changed DU lsof to use the knlist(3) function when
+ no kernel file has been specified with -k. This
+ change was suggested by Erich Wimmer
+ <Erich.Wimmer@digital.com>.
+
+ Updated Configure for latest NetBSD (1.3I?) with
+ UVM support the default.
+
+4.43 May 11, 1999
+ Corrected a typo in the Solaris gcc discussion in
+ 00FAQ. Made changes to the Solaris 2.5[.1] private
+ tcp_s structure. Both changes were done in response
+ to reports from Igor Schein <igor@txc.com>, who
+ tested the Solaris 2.5 change.
+
+ Made more IPv6 adjustments to lsof for Tru64 UNIX
+ (Digital UNIX) 5.0, based on information obtained
+ from Compaq by Berkley Shands <berkley@cs.wustl.edu>.
+
+ Corrected HP-UX error message about HP-UX 11 q4 usage.
+ Amir Katz <amir@ndsoft.com> reported the correction.
+
+ Fixed a GlibC 2.1 conflict in /proc-based Linux lsof.
+
+ Fixed a man page typo reported by Vlad Harchev
+ <hvv@hippo.ru>.
+
+ Changed some Solaris 2.7 references to Solaris 7
+ in Configure and 00XPORTING.
+
+ Added a Solaris example to the echo statements that
+ are the install rule in the SunOS/Solaris Makefile.
+
+ Added a field to the file structure output --
+ FILE-FLAG (file structure open flags, f_flag[s],
+ and process file flags, typically u_pofile)) --
+ enabled with +f[gG]. Its field output character
+ is 'G'.
+
+ Figured out another piece of the HP-UX 11 patched
+ ipc_s structure puzzle with the help of Keith Kalet
+ <KEITH_KALET@HP-USA-om41.om.hp.com>.
+
+ Fixed a PTX real vnode to real inode interpretation
+ bug.
+
+ Added link count to lsof output. Eric Dumazet
+ <dumazet@risgw.ris.fr> requested and helped test
+ it. The new +L option enables and filters it.
+ Its field output character is `k'.
+
+ Updated Configure script to recognize NetBSD 1.4.
+
+ Updated AFSConfig to handle default answers to
+ questions.
+
+ Incorporated patch from Jonathan Sergent <sergent@io.com>
+ that enables /proc-based Linux lsof to run on both
+ 32 and 64 bit kernels.
+
+ Updated Configure script with a patch from David
+ O'Brien <obrien@NUXI.com> that recognizes FreeBSD 3.2.
+
+4.44 June 24, 1999
+ Corrected use of nlink member of hsnode for SunOS
+ 4.1.x High Sierra File System files. John Dzubera
+ <zube@tlaloc.stat.colostate.edu> reported the
+ problem and helped test the fix. Also fixed a
+ SunOS segmentation fault bug. These fixes were
+ offered as a patch to 4.43.
+
+ Improved handling of /proc-based Linux UNIX PCB
+ address.
+
+ Fixed a NEXTSTEP and OPENSTEP bug that made repeat
+ option (-r) processing malfunction. This fix was
+ offered as a patch to 4.43.
+
+ Fixed Configure so it doesn't use -O in the Cflags
+ for the bundled HP-UX C compiler. Jim Ankenbrandt
+ <jankenbrandt@penton.com> reported the problem.
+
+ Corrected output ordering of parent PID and process
+ group ID when both -R and -g are specified.
+
+ Enhanced the pdev.c and pdvn.c library modules for
+ wider use. These dialect versions use the new
+ library modules: DEC OSF/1, Digital UNIX, and Tru64
+ UNIX; Pyramid DC/OSx and Reliant UNIX; SCO OSR and
+ UnixWare; and Sequent PTX.
+
+ Added basic clone device support to /dev/kmem-based
+ HP-UX lsof for HP-UX 10.30 and higher.
+
+ Added raw socket support to /proc-based Linux lsof.
+
+ Changed NODE-ADDR column title to NODE-ID in
+ anticipation of using more general identification
+ information in the column.
+
+ Ported to UnixWare 7.1, using a test system kindly
+ provided by Matt Thurmaier <matt@compclass.com>
+ and Don Draper <dond@sco.com>.
+
+ Updated for NetBSD 1.4C VM changes, and a new
+ current and root working directory structure.
+
+ Made minor adjustment for latest Tru64 UNIX 5.0
+ Beta release.
+
+4.45 July 30, 1999
+ Fixed quoting problem in DEC OSF/1, Digital Unix,
+ and Tru64 UNIX Makefile's install rule. The problem
+ was reported by Berkley Shands <berkley@cs.wustl.edu>.
+ Fixed bug in Tru64 UNIX 4 lsof that caused FDs to
+ be skipped. These fixes were offered in a patch
+ to 4.44.
+
+ Fixed a repeat-mode /proc-based Linux lsof bug,
+ reported by Sami Farin <sfarin@ratol.fi>. This
+ was offered as a patch to 4.44.
+
+ Picked lint, some reported by Sami Farin.
+
+ Corrected a 00DCACHE documentation error in a sample
+ shell script. The problem was reported by Chad R.
+ Larson <chad@larsons.org>. Changed commented-out
+ entries in machine.h files so they require more
+ thought and work when the comments are removed,
+ based on a remark by Chad.
+
+ Compensated for the practice of Solaris 7 and above
+ to record the dev= value in /etc/mnttab in 32 bit
+ mode, even on 64 bit systems. This was offered as
+ a patch to 4.44.
+
+ Added a C library test for /proc-based Linux lsof,
+ so that the #include files can be adjusted for a
+ non-GlibC environment. The need for this was
+ reported by Andrew Hill <andrewh@tirin.openworld.co.uk>.
+ This was offered as a patch to 4.44.
+
+ Added support for Auspex LFS 1.8.1 and 1.9.2 to
+ SunOS 4.1.4 lsof. The support was requested by
+ Quentin Fennessy <quentin@dvorak.amd.com>, who
+ provided information and did testing.
+
+ Enabled IPv6 support code for NetBSD and OpenBSD,
+ conditional on Configure script tests. Wolfgang
+ Rupprecht <wolfgang@wsrcc.com> supplied the NetBSD
+ code and tested it. The OpenBSD code I constructed
+ has been compiled but not tested.
+
+ Updated the identd Perl 5 script, based on a report
+ from Wendy Lin <af5@taiyang.cc.purdue.edu> that
+ the space in its response line in front of the user
+ name violates RFC 1413.
+
+ Added IPv6 support to /proc-based Linux lsof.
+ Jonathan Sergent <sergent@ETLA.NET> and Andrew
+ Thomas Sydelko <sydelko@ecn.purdue.edu> kindly
+ provided a test system.
+
+ Updated man page description of AIX multiplexed
+ files to indicate that they might be /dev/ptc or
+ /dev/pts, depending on the AIX version. The
+ correction was suggested by Onno van der Linden
+ <onno@simplex.nl>.
+
+ Sylvain Robitaille <syl@alcor.concordia.ca> reports
+ lsof passes his Y2K tests.
+
+4.46 October 23, 1999
+ Corrected /proc-based Linux lsof to detect that an
+ IPv6 address is a mapped IPv4 address. The problem
+ was reported and analyzed by Arkadiusz Miskiewicz
+ <misiek@misiek.eu.org>, who also tested the fix.
+
+ Added a libc5 library /dev/kmem-based Linux lsof
+ circumvention, supplied by Jason Lingohr
+ <lingman@lucid.net.au>.
+
+ Corrected a bug in -t (terse) AIX output, reported
+ by Wendy Lin <af5@taiyang.cc.purdue.edu>. I
+ introduced the bug at revision 4.43 when adding
+ FILE_FLAG reporting. This was offered as a patch
+ to 4.45.
+
+ Added a work-around for a problem in the OpenBSD
+ 2.3 <sys/pipe.h> header file. Volker Borchert
+ <bt@teknon.de> provided and tested it.
+
+ Improved description of cross-building lsof for a
+ 64 bit Solaris 7 system on a 32 bit system with
+ suggestions from Phillip Edwards
+ <Philip.Edwards@sn.wpafb.af.mil>.
+
+ Fixed a gawk POSIX-mode pattern error in the Linux
+ /dev/kmem-based Mksrc script, based on a tip from
+ Ambrose C. Li <acli@mingpaoxpress.com>.
+
+ Fixed a bug in the Tru64 UNIX IPv6 handling, courtesy
+ of a report from Casper Dik <casper@holland.sun.com>.
+
+ Enabled support for OpenBSD 2.6.
+
+ Enabled support for BSDI BSD/OS 4.1, based on a
+ report from Jeffrey C Honig <jch@bsdi.com> that
+ only a Configure script change is necessary.
+
+ Enabled Configure script to use gcc for building
+ lsof for a 64 bit Solaris 7 and 8 kernels, if the
+ gcc version is 2.95 or above.
+
+ Improved -i option handling for systems with IPv6
+ support so that it will search for a host name in
+ both IPv4 and IPv6 families, when that is possible.
+ As a companion modification, changed -V processing
+ to report a single error when a multiple host name
+ match is requested. Casper Dik <casper@holland.Sun.COM>
+ helped test.
+
+ Fixed a DEC OSF/1, Digital UNIX, Tru64 UNIX repeat
+ mode bug, reported by Mayer Ilovitz <mayer@cooper.edu>.
+ Mayer helped test the fix. The fix was offered as a
+ patch to 4.45.
+
+ Changed Solaris socket file recognition scheme, so it
+ is (nearly) the same through Solaris 8, where the
+ previous clone device scheme no longer works.
+
+ With significant assistance from Casper Dik, added
+ support for Solaris 8 Beta and Beta refresh. The
+ IPv6 support in Solaris 8 is still in some flux,
+ so there are temporary compensations for the
+ differences between Beta IPv6 support and Beta
+ refresh IPv6 support. Casper and I hope those
+ differences disappear by FCS.
+
+ Improved the delivery of information on Solaris
+ 2.5.1, 2.6, 7, and 8 door files.
+
+ Fixed a repeat mode bug that surfaces when /etc/passwd
+ changes between cycles. The bug report and diagnostic
+ help were supplied by Igor Schein <igor@txc.com>.
+ The fix was offered as a patch to 4.45.
+
+ Added support for INRIA IPv6 to NetBSD. Jean-Luc
+ Richier <Jean-Luc.Richier@imag.fr> provided patches
+ and a test system on which to verify them.
+
+ Added support for AIX 4.3.3. Jeff W. Stewart
+ <jws@anaconda.cc.purdue.edu> provided a test system.
+
+ Made adjustments for FreeBSD 4.0-current.
+
+ Improved reporting of information for AIX sockets that
+ lack protocol control blocks.
+
+4.47 November 29, 1999
+ Based on a query from Jean-Pierre Radley <jpr@jpr.com>,
+ changed the lsof top-level Makefile to propagate
+ CFGF to the library Makefile. (DEBUG was already
+ being propagated.) Added osrgcc and scogcc Configure
+ abbreviations (to use gcc) for Jean-Pierre.
+
+ In response to a query from Igor Schein <igor@txc.com>,
+ improved the Configure script test for Solaris 7
+ and 8 that decides if the compiler can produce 64
+ bit executables.
+
+ Made an ugly hack, based on making a private rnode
+ structure definition from q4 output, to compensate
+ for HP-UX 10.20 and lower recent NFS3 patches. HP
+ didn't supply an updated <nfs/rnode.h> with the
+ patches. The problem was reported by Will Partain
+ <partain@mekb2.sps.mot.com>. Elias Halldor Agustsson
+ <elias@hi.is> helped identify the patches as
+ PHNE_18173, PHNE_19426, PHNE_19937, and PHNE_20091,
+ and provided a test system.
+
+ Switched BSDI test system from 2.1 and 3.1 to 4.0.1,
+ courtesy of Terry Kennedy <terry@tmk.com>.
+
+ Added some more dev_t hacks for Alpha FreeBSD 4.0.
+
+ Added support for IPv6 on BSD 4.x. The support hasn't
+ yet been tested, just compiled.
+
+ Added support for the mnt file system (mntfs or
+ /etc/mnttab) on Solaris 8. Tested on Solaris 8
+ BETA-Refresh.
+
+ Made selection of optional fields (e.g., PPID with
+ -FR) in a field output specification select the
+ optional field, too, so that the option selector
+ for the field (e.g., -R) isn't also required. This
+ change was made in response to an inquiry from John
+ DuBois <spcecdt@armory.com>. This may require some
+ revision to scripts that parse all field output;
+ two scripts in the lsof distribution's scripts/
+ subdirectory had to be updated.
+
+ Corrected handling of Linux IPv4 addresses mapped
+ in IPv6 addresses.
+
+ Tested under OpenBSD 2.6.
+
+4.48 January 14, 2000
+ Modified -i argument processing of colon-separated
+ IPv6 addresses to recognize an IPv4 address mapped
+ in an IPv6 address and handle it as an IPv4 address.
+ This was offered as a patch to 4.47.
+
+ Added a defined symbol (NOWARNBLKDEV) to control
+ (inhibit) the issuance of a warning when no block
+ devices are found. This was done anticipating its
+ need in FreeBSD 4.x, but that dialect version no
+ longer has any block devices, so HASBLKDEV was
+ disabled for it instead. NOWARNBLKDEV was left in
+ place for possible use in the future.
+
+ Enabled KAME IPv6 Configure support for FreeBSD
+ when <netinet6/in6.h> is found.
+
+ Disabled use of gcc to compile lsof for 64 bit
+ HP-UX 11.
+
+ Updated Configure to recognized FreeBSD 3.4.
+
+ Based on suggestions from Bernt Christandl
+ <beb@MPA-Garching.MPG.DE> improved AFS configuration
+ for AIX and Solaris, and updated AIX AFS 3.5 support.
+ Johannes Tax <tax@bluedog.oit.unc.edu>, Hung T.
+ Pham <hung_pham@unc.edu>, and Curt Freeland
+ <curt@grumpy.cse.nd.edu> provided test systems.
+
+ Updated lsof's private rnode definition for AIX
+ 4.3.3, since IBM still doesn't ship the
+ <oncplus/nfs/rnode.h> header file and the rnode
+ structure definition in <nfs/rnode.h> doesn't match
+ what the kernel uses. This was offered as a patch
+ to 4.47.
+
+ Weakened the test in the Linux /proc-based lsof of
+ the field count of data lines in /proc/net/{tcp,udp}.
+ It appears that recent 2.3.x Linux kernels have
+ added untitled fields to these files. The bug
+ report came from Gabor Liptak <gaborliptak@usa.net>.
+
+ Adjusted for a FreeBSD 4.0 change in the definition
+ of [_]KERNEL. David O'Brien <obrien@NUXI.com> reported
+ the problem and provided a test system.
+
+ Removed the HASPPID bracket from Fppid (the -R
+ option state variable) so that the field select
+ table will compile even when HASPPID is not defined.
+ This problem was introduced at revision 4.47 with
+ code that causes some field output characters to
+ set option states. The problem was reported by
+ David Bacon <bacon@birch.eecs.lehigh.edu>.
+
+4.49 April 3, 2000
+ Made clearer in man page that "Lxx" FDs are AIX
+ loader table references. Also updated the 00FAQ
+ discussion of the Stale Segment ID bug to include
+ AIX 4.3.x.
+
+ Modified support for NetBSD 1.4Q to include the
+ <sys/buf.h> header file to cope with an MFS change.
+
+ Added support for OpenBSD UVM virtual memory.
+
+ Added support for AIX systems with > 2GB of memory.
+ Chris Sylvain <csylvain@itg.ummc.umaryland.edu>
+ reported the problem and provided the solution.
+ Chris also supplied some minor code cleanup. This
+ was offered as a patch to 4.48.
+
+ Based on new information from Igor Schein <igor@txc.com>
+ made additional compensation in Configure script
+ for 64 bit Solaris 7 and 8 gcc.
+
+ Added some 00FAQ info on the effect ordering of
+ the +fg and -FG options has on output format.
+
+ Improved NetBSD IPv6 configuration, based on a
+ suggestion from Thomas Klausner
+ <wiz@danbala.ifoer.tuwien.ac.at>. Added code to
+ convert IPv4-mapped-in-IPv6 addresses to IPv4
+ addresses.
+
+ Updated the information in 00FAQ and the HP-UX 11
+ binary directory README files on the HP-UX 11 ipis_s
+ patch with new information supplied by Eric McWhorter
+ <emcwhorter@xsis.xerox.com>.
+
+ Added documentation on changes to HASFSTYPE and
+ HASNCACHE, and the new HASPRIVPRIPP.
+
+ Adjusted Configure for FreeBSD 5.0. Made additional,
+ necessary changes to Configure and the BSDI sources
+ to eliminate load errors.
+
+ Added KAME IPv6 support to FreeBSD at the request
+ of Ollivier Robert <roberto@eurocontrol.fr>, who
+ provided a test system.
+
+ Corrected the script that generates the CHECKSUMS
+ files for binaries to correctly name the detached
+ PGP certificate. The documentation bug was reported
+ by Michael Hennecke <hennecke@rz.uni-karlsruhe.de>.
+
+4.50 June 29, 2000
+ Added a NetBSD alpha test host, courtesy of Ray
+ Phillips <r.phillips@mailbox.uq.edu.au>. An lsof
+ 4.49 binary, built on Ray's 1.4.1 system was made
+ available prior to the 3.50 release.
+
+ Upgraded the system map file tests in /dev/kmem-based
+ Linux lsof, making the use of DEBIAN_LINUX_LSOF
+ unnecessary. Tested the changes on a system made
+ available by Vincent Kujala <kujala@geog.ubc.ca>
+ and Jim Mintha <jim@ic.uva.nl>.
+
+ Forced AIX to use the large-file-enabled versions
+ of lstat (lstat64) and stat (stat64) if <sys/stat.h>
+ contains stat64. This should allow lsof to stat()
+ AIX files > 2GB even when the builder has not
+ defined the "large file enabled programming
+ environment." Configure tests <sys/stat.h> and
+ puts -DHASSTAT64 in the Makefile's CFLAGS to make
+ this happen. Fernando A.B. Whitaker
+ <whitaker@cenapad.unicamp.br> reported the problem.
+ This was offered as a patch to 4.48.
+
+ Enabled Configure script to handle OpenBSD 2.7.
+ Angelos D. Keromytis <angelos@dsl.cis.upenn.edu>
+ reported the availability of OpenBSD 2.7 and supplied
+ the Configure script patch.
+
+ Improved handling of DOOR and fattach()'d files in
+ Solaris.
+
+ Changed message about missing kernel symbol file
+ from "not yet determined" to "none found".
+
+ Updated FreeBSD, NetBSD, NEXTSTEP, OpenBSD, and
+ OPENSTEP support to report "no PCB" and the values
+ of the SO_CANTSENDMORE and SO_CANTRCVMORE state
+ flags when a socket structure has no inpcb pointer.
+ This modification was made to AIX lsof at revision
+ 4.46. Added an entry to 00FAQ about sockets that
+ have no inpcb pointer.
+
+ Upgraded support for FreeBSD 5.0-CURRENT. Ben
+ Smithurst <ben@scientia.demon.co.uk> supplied
+ patches and did testing. David O'Brien <obrien@NUXI.com>
+ supplied a test system. The update included dropping
+ the Fctty part of file descriptor file system
+ support, conditional on a Configure script test.
+ I propagated those changes to BSDI, NetBSD, and
+ OpenBSD in anticipation of their having the
+ modification in the future. David also arranged
+ with Michael Haro <mharo@area51.fremont.ca.us> for
+ a FreeBSD 3.4 test system.
+
+ In response to an lsof 3.72 bug report from Jim Mewes
+ <jim@corp.phone.com>, added more kernel address
+ filtering to the lsof function, kread(), that reads
+ Solaris kernel data.
+
+ In response to a report from Marc Duponcheel
+ <marc@offline.be>, added tests to the /proc-based
+ Linux lsof to ignore file systems of types "autofs"
+ and "pipfs".
+
+ Based on a report and information supplied by Casper
+ Dik <casper@holland.Sun.COM>, updated the ncache_load()
+ function in lib/rnch.c with new code that deals
+ with a post Solaris 8 change in kernel name cache
+ (DNLC) handling. Casper tested the update, which
+ should be invisible to Solaris versions without
+ the new DNLC code.
+
+ Added support for Solaris VxFS QIO files, based on
+ a report from Kieran Broadfoot <kieran.broadfoot@gs.com>.
+ Kieran help test the support.
+
+ Added support for PTX 4.4.6 and 4.5[.1] with help
+ from the usual cast of good people at Sequent.
+
+ Added support for 64 bit file sizes and offsets on
+ BSDI, FreeBSD, NetBSD, and OpenBSD, based on a
+ report from Dan Nelson <dnelson@emsphone.com>.
+ Dan supplied a patch and did FreeBSD testing.
+
+ Added Configure script recognition of NetBSD 1.5,
+ based on a report from Andrew Brown <atatat@atatdot.net>.
+ Thomas Klausner <wiz@danbala.ifoer.tuwien.ac.at> updated
+ the NetBSD port package to use a pre-release of this
+ addition.
+
+ At the last minute saw a notice via deja.com's
+ UseNet search service that FreeBSD 3.5 had been
+ released and lsof didn't grok it. Added recognition
+ of 3.5 to lsof's Configure script, but didn't have
+ the opportunity to test lsof on 3.5.
+
+4.51 August 21, 2000
+ Added Configure script support for the upcoming
+ Solaris 9 release based on suggestions from Casper
+ Dik <Casper.Dik@holland.sun.com>.
+
+ Changed sample Perl scripts to assume that
+ /usr/local/bin/perl is Perl 5 and Perl 4 may be
+ found in /usr/local/bin/perl4.
+
+ Updated Configure to recognize FreeBSD 4.1 and made
+ a FreeBSD pre-release distribution available.
+
+ Bela Lubkin <belal@sco.COM> tested lsof on the
+ upcoming SCO OSR 5.0.6 release and reports that
+ lsof appears to work properly.
+
+ Updated the AIX compiler test in Configure to
+ recognize its version 5.
+
+ Updated AIX 4.3.3 support with automatic recognition
+ of the proper rnode structure, based on machine
+ bit width. Also added code to detect when processing
+ the -X option that lsof has been compiled with the
+ "other" AIX 4.3.3 user structure and to apply
+ compensations. When a compensation method works,
+ it's applied during subsequent -X processing; when
+ none works, further -X processing is disabled.
+
+ Added Tru64 UNIX 5.1 support. Updated Tru64 UNIX
+ library text file support to recognize new kernel
+ support for AdvFS library files. Berkley Shands
+ <berkley@cs.wustl.edu> and Klaus Saggerer USG
+ [saggerer@zk3.dec.com> helped put me in contact
+ with Chang Song <song@zk3.dec.com>, the developer
+ of 5.1's new kernel name cache and he helped me
+ develop new code in lsof to access it.
+
+ Corrected reporting of PTX fattach()'d address.
+
+ Changed Configure and dlsof.h for NetBSD and OpenBSD
+ to use /usr/include/uvm header files when available.
+ Andrew Brown <atatat@atatdot.net>, Thomas Klausner
+ <wiz@danbala.ifoer.tuwien.ac.at>, and Wolfgang
+ Rupprecht <wolfgang@wsrcc.com> pointed out the need
+ to do this for NetBSD. Andrew provided access to
+ a NetBSD 1.5 system for verifying the changes.
+
+ Installed snprintf() support, including a private
+ version in the lsof library for those UNIX dialects
+ without the function. Changed all sources to use
+ it instead of sprintf() and strcpy().
+
+ Fixed a memory leak in the readvfs() functions of
+ BSDI, DEC/OSF1, Digital UNIX, FreeBSD, NetBSD,
+ OpenBSD, and Tru64 UNIX.
+
+ Tested on Linux 2.4.
+
+ Modified the Pyramid MkKernOpts script to compensate
+ for `uname -s` configuration alternatives. Robert
+ Dahlem <Robert.Dahlem@ffm2.siemens.de> supplied
+ the modification.
+
+ Obtained access to an FCS Solaris 8 64 bit system
+ and built lsof on it, using Sun Workshop C 5.0 and
+ gcc 2.96 20000814 (experimental). Both compilers
+ produce a working lsof.
+
+
+4.52 November 8, 2000
+ Completed work on an HP-UX 11.11 port that uses a
+ pstat(2) interface provided by HP. To distinguish
+ it from its predecessors for HP-UX, this lsof
+ version is called PSTAT-based and the predecessor
+ versions are now called /dev/kmem-based. I am
+ indebted to the far-sightedness and support of
+ these good people at HP for making PSTAT-based lsof
+ possible: Carl Davidson, Louis Huemiller, Rich
+ Rauenzahn, and Sailu Yallapragada. The PSTAT-based
+ sources are in lsof_4.52/dialects/hpux/pstat, the
+ /dev/kmem-based ones in lsof_4.52/dialects/hpux/kmem.
+
+ Ported to IBM Monterey for Merced|Itanium, aka AIX
+ 5L. It configures via the Configure script's "aix"
+ abbreviation and has been tested on AIX 5L Beta 3.
+ Jay Beck, Steve Dibbell, Loc Le, Nasser Momtaheni,
+ and Malcom Zung of IBM provided generous support.
+ Since AIX 5L is still in Beta testing, this port
+ can't be considered complete.
+
+ Added Configure support for OpenBSD 2.8. David
+ Mazieres <dm@cs.nyu.edu> provided a test system.
+
+ Based on a report from Marc Christensen
+ <marc@mecworks.com> added sockfs to the mount scan
+ exemption list for /proc-based Linux lsof.
+
+ Added large file, CDFS, and DOSFS for UnixWare 7.x.
+ Added UnixWare device memory mapping support. All
+ UnixWare changes were supplied by Eric Dumazet
+ <edumazet@cosmosbay.com> Eric also supplied some
+ miscellaneous bug fixes.
+
+ Deferred name cache loading until printname() needs
+ to use the name cache.
+
+ Terminated Pyramid, SunOS 4.1.x, and Ultrix support,
+ because test systems are no longer available.
+ Final Pyramid and Ultrix source code distributions
+ for lsof revision 4.51 may be found on lsof.itap.purdue.edu
+ in pub/tools/unix/lsof/OLD/src. The no longer
+ supported SunOS 4.1.x source code is still distributed
+ with the Solaris source code.
+
+ Added code to set Solaris node address to real vnode
+ address, when applicable.
+
+ John Speno <speno@lopan.isc-net.upenn.edu> provided
+ information that enabled me to update the Tru64
+ AdvFS (MSFS) node definition for AdvFS version 5.
+
+ Added Tru64 5.x CFS support with help from Kris
+ Chandrasekhar <Kris.Chandrasekhar@compaq.com>,
+ Diane Lebel <lebel@zk3.dec.com>, and John Speno.
+ The support only provides information about cached
+ file attributes.
+
+ Installed a Configure patch for HP-UX 11 supplied by
+ Kenneth Stailey <kstailey@disclosure.com> that adds
+ another command to q4 input.
+
+ Tested on FreeBSD 4.2.
+
+ Will Day <willday@rom.oit.gatech.edu> and Frank
+ Winkler <frank.winkler@germany.sun.com> graciously
+ supplied Solaris 8 binaries.
+
+ Added Solaris 9 text file support, supplied by
+ Casper Dik <Casper.Dik@holland.sun.com>.
+
+4.53 December 6, 2000
+ Added the AIX 5L j2_lock.h to the distribution with
+ a Configure script step to use it when it's missing
+ from /usr/include/j2.
+
+ Removed SunOS 4.1.x support.
+
+ Removed Linux 2.0.x /dev/kmem support.
+
+ Fixed VBLK and VCHR special device file reporting
+ to handle /dev information more accurately.
+
+ Added a Apple Darwin / Mac OS X 1.2 port, provided
+ by Allan Nathanson <ajn@apple.com>. Allan also
+ arranged for a test system so I can maintain this
+ port. An additional test system was provided by
+ Dale Talcott.
+
+ Dropped claims of support for all UnixWare versions
+ except 7.1.0, since that is the only version on
+ which I can test lsof. Even though lsof 4.53 is
+ deprecated for UnixWare 2.1.3, installed a patch
+ for it with testing done by A. Channing Clark
+ <clark.channing@heb.com>.
+
+ Dropped claims of support for all SCO OpenServer
+ versions except 5.0.5, since that is the only
+ version on which I can test lsof.
+
+4.54 January 19, 2001
+ Added compensation for a change that made the
+ FreeBSD mount structure invisible. I can only test
+ back to 3.2 and the compensation works there, so
+ it's been #ifdef'd for 3.2 and above. David O'Brien
+ <obrien@FreeBSD.org> provided the necessary clue.
+
+ Based on a report from Valdis Kletnieks
+ <Valdis.Kletnieks@vt.edu>, changed all IPv6 support
+ to report a TYPE of IPv6 for sockets with IPv4
+ addresses mapped in IPv6 addresses. The previous
+ lsof behavior was to report their TYPE as IPv4.
+
+ Restored the Linux GlibC test to Configure, removed
+ at revision 4.53, based on a report from John Dzubera
+ <zube@cs.colostate.edu>, that RedHat Linux 6.0 still
+ needs the test.
+
+ Made setting of link count for Solaris more selective.
+
+ Limited Readlink() recursion to MAXSYMLINKS. The bug
+ was reported by Jan Dvorak <johnydog@go.cz>.
+
+ Dropped the *claim* that lsof runs on Solaris 2.5.1.
+ It may well do so, but I no longer have access to a
+ test system.
+
+ Fixed an #endif comment typo, reported by Igor Schein.
+
+ Fixed a typo in a cast for a Tru64 UNIX 5.1 function
+ and updated Configure for Tru64 UNIX 5.0 and 5.1 with
+ information from Jesse Perry <jesse.perry@compaq.com>.
+
+ Corrected non-fatal typos in the AdvFS support in
+ dnode.c for Tru64 UNIX.
+
+ Added msdos file system support for NetBSD and OpenBSD.
+ Andrew Brown <atatat@atatdot.net> requested and helped
+ test it.
+
+4.55 February 15, 2001
+ Based on a report from Bernd Eckenfels <ecki@lina.inka.de>
+ added support in lsof for files in /proc/<PID>/maps
+ that have been deleted.
+
+ Changed PGRP output title to PGID, conforming to
+ the most common current abbreviation for Process
+ Group ID (PGID). While some systems continue to
+ use *pgrp for internal kernel variable names, most
+ systems that support the display of PGID via ps(1)
+ now title it PGID. The lsof -g and -Fg options
+ operations are unchanged in function; only titles
+ and descriptions have changed. Also changed internal
+ variable names from *PGRP and *pgrp to *PGID and
+ *pgid where possible.
+
+ Dropped the *claim* that lsof runs on HP-UX 9.x.
+ It may well do so, but I no longer have access to
+ a test system.
+
+ In response to a suggestion from Jeff Howie
+ <jeff.howie@federated.ca> added support for command
+ name selection by regular expression. A new form
+ of the -c option value is use to identify and
+ specify a regular expression.
+
+ Restore the *claim* that lsof works on UnixWare
+ 7.0, since I re-acquired a test system.
+
+4.56 May 3, 2001
+ Corrected some problems Amir Katz <Amir_Katz@bmc.com>
+ found with Insure++, one in lib/dvch.c, the rest
+ in Solaris sources. Amir's report also helped me
+ find an error in an snpf() call that caused (the
+ unsupported) Solaris 2.5.1 lsof to crash. Wally
+ Winzer, Jr. <wally.winzer@ChampUSA.COM> helped test.
+
+ Added support for UnixWare 7.1.1 and above in-kernel
+ UNIX sockets. John Hughes <john@Calva.COM> kindly
+ provided code and access to a test system. John
+ also provided a test system and advice for adding
+ UnixWare 7.1.1 NonStop Cluster and CFS support.
+ More help with that effort came from Kurt Gollhardt
+ (SCO), Barbara Howe (SCO), Bela Lubkin (SCO), and
+ Dewan Rashid <Dewan.Rashid@ir.com>.
+
+ Archived a set of compilation hints (patches) from
+ Bill Melvin <Bill.Melvin@esc.edu> that make it
+ possible to compile the old, unsupported lsof 3.08
+ sources on UnixWare 1.x without NFS or CDFS support.
+
+ Installed support supplied by Allan Nathanson
+ <ajn@apple.com> for the Darwin "Gold Master" release,
+ Mac OS X 10.0 (aka Darwin 1.3 in its public source
+ version). Added Allan's CVS repository suggestions
+ to the script that gets additional header files
+ from an open source repository.
+
+ Tested an HP-UX 11.11 kernel patch from Sailu
+ Yallapragada that enables reporting of TCP/IP
+ information for telnetd processes that use the
+ telnet multiplexor. I don't yet know the kernel
+ patch ID.
+
+ Made the Solaris inclusion of <inet/mi.h> conditional
+ on the Solaris version. (It's apparently not needed
+ at 2.6 and above.) Bill Watson <bill.watson@uk.sun.com>
+ brought this to my attention.
+
+ Added alternate Linux 2.4.x lock extent test, supplied
+ by Jim Mintha <jim@ic.uva.nl>.
+
+ Rearranged the lines and pre-processor tests in
+ regex.h, lib/regex.c, and lib/snpf.c so that unifdef
+ can be used to eliminate copyright and GPL statements
+ when the files aren't being used for a particular
+ dialect. (USE_LIB_* definitions in a dialect's
+ machine.h header file determine if one or more of
+ those three files are to be used.)
+
+ Added preliminary support for Solaris 8 with VxFS
+ 3.4. This support will be refined as I get
+ information from Veritas about how they will
+ distribute the kernel header files lsof needs.
+ Those header files were omitted from the standard
+ VxFS 3.4 distribution. Technical assistance and
+ testing were provided by Calle Dybedahl <cdy@algonet.se>,
+ Gary Millen <gary.millen@veritas.com>, Rainer Orth
+ <ro@TechFak.Uni-Bielefeld.DE>, Peter C. Vernam
+ <pvernam@draper.com>, and Donna Yobs
+ <Donna.Yobs@veritas.com>
+
+ Tested on FreeBSD 4.3-STABLE.
+
+ Dropped the *claim* that lsof works on UNIX dialects
+ where I no longer have test systems: BSDI 2.1,
+ 3.[01] and 4.0; DEC OSF/1, Digital UNIX and True
+ 64 UNIX 2.0 and 3.2; FreeBSD 2.1.[67], 2.2[.x],
+ 3.[012345] and 4.[01]; HP-UX 10.20; NetBSD 1.[234];
+ SCO OpenServer 5.0.5; and SCO UnixWare 7.0
+
+ Tested on Solaris 9 BETA, s81_36.
+
+4.57 July 19, 2001
+ Help (-h) and version (-v) output now have URLs
+ for the newly created and timeliest lsof FAQ
+ (00FAQ in the lsof distribution) at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
+
+ and the man page for the current lsof distribution
+ at:
+
+ ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
+
+ Based on a report from Steve Laubscher
+ <slaubs@woodward.com>, modified dlsof.h for PTX
+ 4.6[.1] to avoid a temporary dnlc_t definition
+ needed at PTX 4.5.1.
+
+ Corrected test for old Linux kernels in Configure.
+ Henri Karrenbeld <ishtar@cal044202.student.utwente.nl>
+ brought the error to my attention. Limited Linux
+ claims to 2.1.72 and above in the documentation.
+
+ Improved HP-UX 11 Configure stanza and stream socket
+ handling.
+
+ Constructed a work-around for the HP-UX 11 optional
+ OnlineJFS package. The work-around sadly requires
+ lsof to have a private version of the vx_inode
+ structure, since the OnlineJFS package doesn't
+ update <sys/fs/vx_inode.h>. Troyan Krastev
+ <Troyan.Krastev@ricoh-usa.com> brought the bug to
+ my attention and Michael Bracewell
+ <michael@ra.TSS.PeachNet.EDU> provided a test system
+ where I developed the work-around.
+
+ Added locale support to lsof's isprint() test,
+ based on a suggestion from Dan Mercer <damercer@mmm.com>.
+ Lsof will use setlocale(), when that function and
+ its supporting <locale.h> header file are available.
+
+ Added OpenBSD 2.9 support.
+
+ Based on a report from Aaron Rhodes <arhodes@psionic.com>
+ and with testing help from Aaron, made the lsof
+ 4.56 revision compile and work on OpenBSD 2.6.
+ While that OpenBSD version is no longer supported,
+ Aaron's report exposed a Configure script bug
+ affecting OpenBSD versions lsof does support.
+
+ Updated for FreeBSD 5.0-CURRENT. Szilveszter Adam
+ <sziszi@petra.hos.u-szeged.hu> help test. The lsof
+ FreeBSD ports packager, David O'Brien <obrien@FreeBSD.org>,
+ assisted.
+
+ Tested on AIX 5.1. Loc Le and Nasser Momtaheni of
+ IBM provided test systems.
+
+4.58 September 13, 2001
+ Added options to safestrprt() and safestrprtn() to
+ surround the string with '"' and to suppress the
+ printing of an ending '\n'. Use of these functions
+ in device cache file error message reporting answers
+ a suggestion for better error reporting from John
+ Jackson <jrj@purdue.edu>.
+
+ Fixed a Solaris 2.6 and above problem related to
+ searching for "large" (O_LARGEFILE) files by name;
+ lsof was using the wrong version of [l]stat(2).
+ The bug was reported by Daniel Trinkle
+ <trinkle@cs.purdue.edu>.
+
+ Added AIX 4.1.4 and above XTI socket support.
+
+ Added OSR Xenix Shared Data and Semaphore file type
+ support with modifications supplied by Bela Lubkin.
+
+ Updated OPENSTEP support with modifications from Carl
+ E. Lindberg <lindberg@clindberg.org>. The changes
+ enable the correct reporting of executable and
+ library open files ("txt" type).
+
+ Limited claims of OpenServer support to the versions
+ where I currently test, 5.0.4 and 5.0.6. (Lsof
+ probably works on 5.0.5.)
+
+ Enabled processing of -C option for PSTAT-based HP-UX
+ lsof.
+
+ Enabled and tested on FreeBSD 4.4.
+
+ Corrected a file system test example in 00QUICKSTART,
+ based on a report from Jun Biao WANG <wangjunb@cn.ibm.com>.
+
+ Made available for re-distribution a user-contributed
+ port of lsof 4.51 to Reliant UNIX 5.45. Thomas
+ Mauterer <Thomas.Mauterer@philosys.de> contributed
+ the port.
+
+4.59 October 20, 2001
+ With the closing of the Sequent Synergy Links Lab
+ by IBM, terminated lsof support for PTX. The last
+ tested PTX lsof revision, 4.58, is available on
+ lsof.itap.purdue.edu in .../lsof/OLD/src.
+
+ Adjusted for FreeBSD 5.0-CURRENT NFS header file
+ changes, based on a report from Jos Backus
+ <josb@cncdsl.com>.
+
+ Corrected a bug in the way Linux lsof identifies
+ the owner of a process. Lionel Cons <lionel.cons@cern.ch>
+ reported the problem and tested the fix. Added
+ code to avoid stat(2) calls on regular Linux files
+ whenever possible. Lionel reported the need to do
+ this (AFS files) and tested the new code.
+
+ Added new output field for raw device number in
+ hex. The field is identified with 'r'. This field
+ is NOT selected when -F or -F0 is specified so that
+ its appearance won't disturb existing scripts that
+ process field output.
+
+ Added support for OpenUNIX 8. A test system was
+ provided by Larry Rosenman <ler@lerctr.org>.
+ Matthew Thurmaier <matt@compclass.com> and many
+ people from Caldera provided technical assistance.
+
+ Added an additional UVM test to the NetBSD Configure
+ stanza. Andrew Brown <atatat@atatdot.net> supplied
+ the test; it recognizes NetBSD 1.5Y UVM changes to
+ the vnode structure recently committed by Chuck
+ Silvers.
+
+ Applied Configure and get-xnu-headers.sh script
+ changes suppled by Allan Nathanson <ajn@apple.com>
+ for Darwin 1.4.
+
+ Added for Bela Lubkin <belal@mammoth.ca.caldera.com>
+ OSR-specific environment variables to supply values
+ to the Configure script. The variables are described
+ in 00XCONFIG.
+
+ Added an IP version selector to the -i option
+ parameters.
+
+4.60 November 9, 2001
+ Added special handling to and corrected bugs in
+ the matching of IPv4 in IPv6 addresses to -i6:<...>
+ selectors.
+
+ Made 00FAQ corrections and updates, based on
+ discussions with Igor Schein <igor@txc.com>.
+
+ Modified Configure script to detect a 64 bit capable
+ gcc compiler and permit it to be used to build 64
+ bit (PA-RISC 2) lsof for HP-UX 11.00. Tested with
+ HP's gcc package, which Rich Rauenzahn of HP kindly
+ installed on a test system at HP. Stefan Marquardt
+ <stefan.marquardt@hagebau.de> helped test.
+
+ Made lsof's method of killing its child process
+ more robust, based on a suggestion from Bela Lubkin
+ <belal@caldera.com>.
+
+ Modified all dialect Makefile segments to accept
+ select -v #define's from the environment -- a
+ builder's comment, host, logname, system information
+ and user name. This was done for Bela Lubkin, so
+ he can "tune" the -v output when he packages lsof
+ in the upcoming Caldera OSR 5.0.7 release.
+
+ Changed Perl scripts in scripts/ to put the lsof
+ path consistently in $LSOF. Also added a fix from
+ Bela Lubkin to scripts/big_brother.perl5 that allows
+ it to tolerate SCO OSR "ago" clauses in open UDP
+ file information. Strengthened emphasis in
+ scripts/00README that the scripts are examples that
+ shouldn't be expected to run on all UNIX dialects
+ without modification.
+
+ At Bela Lubkin's suggestion changed the device
+ cache file format examples in 00DCACHE and 00FAQ
+ to avoid "%U%". That's an SCCS escape sequence.
+
+ Added support for OpenBSD 3.0.
+
+ Added +DAportable to CFLAGS for 32 bit HP-UX 11.
+ Amir Katz <Amir_Katz@bmc.com> suggested the addition.
+
+4.61 January 22, 2002
+ Updated field output example Perl scripts in the
+ scripts/ subdirectory to discover the lsof path,
+ starting at .. and proceeding through the PATH
+ environment variable's directories.
+
+ Added minor OSR Configure script fixes, provided
+ by Bela Lubkin <belal@caldera.com>.
+
+ In response to a report from Joshua Wright
+ <Joshua.Wright@jwu.edu> modified NetBSD and OpenBSD
+ Configure stanzas and sources so that lsof can be
+ built when there is no system source tree (e.g.,
+ /usr/src/sys).
+
+ In response to a report from Peter Valchev
+ <pvalchev@openbsd.org> improved the UVM test in
+ the OpenBSD Configure stanza.
+
+ Updated Configure script to recognize FreeBSD 4.5.
+ Updated for FreeBSD 5.0 procfs and pseudofs changes.
+
+ Updated HP-UX stanza to see if the compiler named
+ in the LSOF_CC environment variable is the bundled
+ compiler. If it is, "-O" is omitted from the
+ compiler flags.
+
+ Updated Digital UNIX 4.x and Tru64 UNIX error message
+ related to kernel name list failures. Added an FAQ
+ section about how a kloadsrv daemon failure can cause
+ knlist(3) to fail. The condition was reported by
+ Douglas B. Jones <douglas@gpc.peachnet.edu>
+
+ Based on a report from Mark W. Eichin <eichin@thok.org>
+ made Linux lsof capable of handling and reporting
+ file sizes greater than 32 bits.
+
+ Tested on Solaris 9 BETA-Refresh.
+
+ Corrected a bug in the matching of IPv4 addresses,
+ mapped in IPv6 addresses, to an IPv4 parameter to
+ an -i option.
+
+ Ported to 64 bit Power AIX 5.1 kernel with advice
+ from David Clissold <cliss@austin.ibm.com> and Marc
+ Stephenson <marc@austin.ibm.com>, and on a test
+ system provided by Loc Le <lple@us.ibm.com>.
+
+4.62 March 7, 2002
+ Updated 00README to reflect the usefulness of gcc
+ for building AIX lsof. Documented a report from
+ Brian L. Gentry <BGentry@nationsrent.com> of success
+ on AIX 4.3.3. I documented my success on 32 bit
+ Power AIX 5.1 and my lack of success on ia64 AIX
+ 5.1 and 64 bit Power AIX 5.1.
+
+ Improved UnixWare >=7.1.1 reporting of UNIX socket
+ NAME field information for NonStop Cluster systems
+ with a patch provided by John Hughes <john@Calva.COM>.
+ Offered John's improvement as a patch to lsof 4.61.
+
+ Corrected bugs in handling of open files on block
+ devices by OSR lsof. The bugs were reported by
+ Bela Lubkin <filbo@deepthought.armory.com>.
+
+ Fixed bug in writing >32 bit device numbers for
+ block devices to the device cache file.
+
+ Added support for reporting block special nodes
+ not in /dev (or /devices). That required "like
+ device special" be changed to "like block special"
+ and "like character special". (00FAQ was updated.)
+
+ Based on a report from Peter Valchev <pvalchev@openbsd.org>
+ improved the definition of the source for NetBSD
+ and OpenBSD kernel symbols (the nlist() source
+ file). NetBSD now defaults to getbootfile(3) if
+ it is available, /netbsd otherwise. OpenBSD now
+ defaults to /dev/ksyms if it is available, /bsd
+ otherwise.
+
+ Made possible compilation under BSD/OS (BSDI) 5.0
+ with changes to Configure, dialects/bsdi/dlsof,
+ dialects/bsdi/dproc.c and lib/rnmh.c. The changes
+ were suggested by Steven Hinkle <hinkle@bsdi.com>.
+ Note that these changes do not substantiate a claim
+ that lsof works on BSDI 5.0, because I haven't
+ tested it there.
+
+ Updated OpenUNIX private <sys/fs/memfs_mnode.h>,
+ based on a report from Larry Rosenman <ler@lerctr.org>
+ that it had been updated by Caldera patch OU800PK3.
+ Unfortunately the patch only corrects some of the
+ problems with the header file, so it is still
+ necessary to distribute a private patched version
+ of it with the lsof sources.
+
+ Applied a man page correction reported by Frederic
+ Delanoy <max_ok@yahoo.com>.
+
+ Corrected cast bugs related to using the HP-UX
+ bundled C compiler on HP-UX 11.11.
+
+4.63 April 23, 2002
+ Added HPUX_BOOTFILE environment variable for use
+ by the Configure script in determining HP-UX kernel
+ configuration information -- e.g., the state of
+ the ipis_s structure in the HP-UX 11 kernel. The
+ change was suggested by Marc Bejarano <beej@alum.mit.edu>.
+ Marc also suggested some changes to the HP-UX
+ section in 00FAQ that discusses Configure's use of
+ q4 for HP-UX 11.
+
+ Fixed a bug in the Solaris lsof file system matching
+ code. It was not reporting that VCHR files in
+ /devices were in / when /devices was in /, too.
+
+ Corrected bugs in device number, file size, file
+ offset, and raw device number field output generation.
+
+ Added recognition of OpenBSD 3.1 to the Configure
+ script with a suggestion from Peter Valchev
+ <pvalchev@sightly.net>. Note that this change does
+ not constitute a claim that lsof works on OpenBSD
+ 3.1, because I haven't tested it there.
+
+ Built an automated test suite. (See 00TEST and
+ the tests/ sub-directory of the lsof main directory).
+ Bela Lubkin requested it. Dale Talcott, John
+ Hughes, and Larry Rosenman helped me validate it
+ on their systems.
+
+ During the development of the test suite I discovered
+ the following lsof bugs or missing features, and
+ corrected or supplied them.
+
+ * Corrected the reporting of locks for:
+ o Digital UNIX 4.0d and Tru64 Unix 5.[01];
+ o HP-UX 10.30 and 11.00;
+ o OpenUNIX 8;
+ o UnixWare 7.1.1.
+
+ * Enabled HP-UX 10.30 and 11.00 to report open NFS
+ file link counts.
+
+ * Corrected the reporting of UNIX domain socket
+ names for Apple Darwin, FreeBSD 4.5 and above,
+ NetBSD 1.4.1 and above, and for OpenBSD 3.0 and
+ above.
+
+ * Enabled HP-UX 11.11 to stat(2) large files.
+
+ * Fixed handling of combination 32 and 64 bit
+ device numbers in AIX 64 bit architectures.
+
+ Updated the AIX 4.3.3 NFS rnode recognition code,
+ first installed at revision 4.51. It looks like
+ some IBM update has restored a single rnode structure
+ independent of the machine bit width.
+
+ Updated the NetBSD and OpenBSD sources so NetBSD
+ can process DTYPE_PIPE files, as OpenBSD was already
+ able to do.
+
+ Updated Darwin get-xnu-headers.sh script to reflect
+ information about a recent reorganization of the
+ Darwin CVS hierarchy, supplied by Allan Nathanson
+ <ajn@apple.com>.
+
+ Added defense against the standard I/O descriptor
+ attack.
+
+4.64 June 26, 2002
+ Corrected some FreeBSD pre-processor directives.
+ David O'Brien <obrien@NUXI.com> pointed them out.
+
+ Updated lsof's main() function to: 1) close all
+ open file descriptors above 2 before starting; and
+ 2) to set a non-interfering umask. Moved GET_MAX_FD
+ test from misc.c to proto.h, so that main() could
+ use it. Added multiple-include protection to
+ proto.h.
+
+ Moved FAQ's test suite Q's & A's to a more appropriate
+ section. Added a Q&A on HASSECURITY option and
+ its affect on searching for open files. (That was
+ already in the man page.)
+
+ Updated hpux/kmem/dnode.c for HP-UX < 11 compilation
+ with information from John Dzubera <Zube@CS.ColoState.EDU>.
+ While lsof doesn't support HP-UX < 11 any more, I
+ try to avoid disabling it there when possible, and
+ a locking fix for HP-UX >= 11 in lsof 4.63
+ inadvertently disabled compilation of lsof for
+ HP-UX < 11. Fixed long-standing bug in HP-UX 10.20
+ lock reporting.
+
+ Removed language from the test suite programs that
+ requires an ANSI-C compiler. This allowed the test
+ suite to be validated with cc and gcc on the un-
+ supported HP-UX 10.20.
+
+ At the suggestion of Manuel Bouyer <bouyer@antioche.eu.org>
+ switched NetBSD and OpenBSD lsof from using nlist()
+ to using kvm_nlist(). Made the same change for
+ BSDI, Darwin, and FreeBSD.
+
+ Validated test suite on OPENSTEP 4.2.
+
+ In response to a suggestion from Jeff Stoner
+ <jstoner@blackboard.com> enhanced support for the
+ FD list of the -d option to allow it to be either
+ an exclusion or inclusion list, using the '^' prefix
+ to denote exclusions.
+
+ Made adjustments for FreeBSD 4.6 and 5.0-CURRENT.
+ Fixed a FreeBSD /etc/make.conf CFLAGS extraction
+ bug, reported by Kris Kennaway <kris@obsecurity.org>,
+ and new a bug in the fix, reported by Eric Cronin
+ <ecronin@eecs.umich.edu>
+
+ Added nullfs support for FreeBSD, NetBSD, and OpenBSD
+ at the request of Andrew Brown <atatat@atatdot.net>.
+
+ Modified all readmnt() functions to ignore mounted-on
+ directory names that don't begin with '/'.
+
+ Tested on NetBSD 1.6A and OpenBSD 3.1.
+
+ Upgraded to Solaris 9 FCS with two changes to the
+ BETA-Refresh support: 1) an adjustment to dnode.c
+ for a change in the so_so (sonode) structure; and
+ 2) addition of Solaris 9 FCS specific DNLC code.
+ David Comay <David.Comay@Eng.Sun.COM> sent me the
+ dnode.c change and Casper Dik <Casper.Dik@sun.com>
+ helped with the new DNLC support code.
+
+ Applied OpenUNIX changes that permit lsof to compile
+ and run on the upcoming 8.0.1 release. The changes
+ were supplied by Robert Lipe <robertl@caldera.com>.
+ Larry Rosenman <ler@lerctr.org> provided a test
+ system.
+
+ Added Solaris fd file system support.
+
+4.65 October 10, 2002
+ Adjusted for change in FreeBSD 5.0-CURRENT inode
+ structure, reported by David O'Brien <obrien@NUXI.com>.
+ Adjusted for changes in FreeBSD 5.0-CURRENT <sys/vnode.h>.
+ One change was reported by Anders Nordby
+ <anders@FreeBSD.org>. Adjusted for FreeBSD 5.0-CURRENT
+ on sparc64 architecture.
+
+ Enhanced the error reporting of Solaris lsof when
+ it detects a kvm_open() failure, and added a 00FAQ
+ entry on the cause, based on a report from Peter
+ J. Bertoncini <pjb@anl.gov>.
+
+ Enabled compiling of lsof for NetBSD 1.5 with the
+ NULL file system, using a patch from Andrew Brown
+ <atatat@atatdot.net>.
+
+ Removed a hack in the LTbigf test program that was
+ once needed when it was compiled on Solaris 9 BETA-
+ Refresh with gcc. The hack isn't needed on Solaris
+ 9 FCS. Janet Hempstead <jan@library.carleton.ca>
+ brought the need for this change to my attention.
+
+ Applied a patch, supplied by Andrew Brown
+ <atatat@atatdot.net>, that updates lsof for NetBSD
+ version 1.6F. Corrected handling of the NetBSD
+ nullfs.
+
+ Updated to BSDI BSD/OS 4.3 on a test system kindly
+ provided by Terry Kennedy <terry@tmk.com>.
+
+ Updated to FreeBSD 4.7.
+
+ Updated to Apple Darwin 1.5, 5.x and 6.x with
+ patches supplied by Allan Nathanson <ajn@apple.com>.
+ The patches include IPv6 support.
+
+ Updated Configure to use the -bnolibpath loader
+ option when building lsof on a PowerPC, running
+ AIX 5 or greater. Valdis Kletnieks
+ <Valdis.Kletnieks@vt.edu> informed me this was
+ needed. Lsof for AIX 5.x was initially developed
+ on the IA64, where -bnolibpath can't be used and
+ I didn't think to restore it to PowerPC loads when
+ AIX 5.x became available for that architecture.
+
+ Updated to UnixWare 7.1.3 on a test system provided
+ by Larry Rosenman <ler@lerctr.org>. Removed claims
+ that lsof works on OpenUNIX 8.0.1, because UnixWare
+ 7.1.3 is the release name of OpenUNIX 8.0.1.
+
+ Based on a comment that his e-mail address was
+ wrong in the lsof distribution from Kenneth Stailey
+ <kstailey@disclosure.com>, removed all e-mail
+ addresses from lsof documentation files except this
+ one, 00DIST. The addresses in 00DIST are used to
+ send revision release notices to those who contributed
+ to a revision, but the addresses in this file for
+ previous revisions and in other documentation files
+ sometimes grow stale and are never validated.
+
+4.66 December 22, 2002
+ Acquired Solaris 7 and 8 test systems, courtesy of
+ John Dzubera <Zube@CS.ColoState.EDU>. Updated
+ 00TEST and tests/TestDB accordingly.
+
+ Clarified FreeBSD 5.0 architecture claims at the
+ suggestion of David O'Brien <obrien@NUXI.com>.
+ Also implemented David's suggestion to change
+ Intel to x86.
+
+ Installed changes to DNLC handling in OSR lsof in
+ preparation for handling changes in the OSR 5.0.7
+ DNLC cache. Information about the changes and
+ patches to handle them were supplied by Bela Lubkin
+ <filbo@deepthought.armory.com>.
+
+ Upgraded True 64 UNIX support to the 5.1B release
+ on a test system provided by Berkley Shands
+ <berkley@cse.wustl.edu> Had to used relaxed ANSI
+ compilation because of an error in a system header
+ file and other lsof source usages.
+
+ Implemented the HASNOSOCKSECURITY compile-time
+ option. When it and HASSECURITY are defined, lsof
+ will be built to list only the user's open files,
+ but will also list anyone else's open socket files,
+ provided the "-i" option selects their listing.
+ Updated the Customize script to ask about setting
+ HASNOSOCKSECURITY. Left it undefined in all dialect
+ machine.h header files. This change was requested
+ by Kenneth Stailey <kstailey@speakeasy.net> for
+ use with ntop.
+
+ Added support for OpenBSD 3.2 and its kernel trace
+ file.
+
+ Improved lsof help (-h) and version (-v) information
+ reporting.
+
+ Fixed a FreeBSD 4.7 and above off-by-two UNIX domain
+ socket path termination bug, reported by Ken Stailey
+ <kstailey@speakeasy.net>
+
+4.67 March 27, 2003
+ Began the transition of the lsof ftp server host
+ name from vic.cc.purdue.edu to lsof.itap.purdue.edu.
+ That reflects Purdue organizational changes. This
+ first step makes the new name an alias to the old
+ one. The old name, vic.cc.purdue.edu, will remain
+ usable for an extended period.
+
+ Corrected a revision number reference in section
+ 17.17 of 00FAQ on the appearance of Solaris negative
+ DNLC caching handing.
+
+ Updated 00FAQ discussion of compilers for 64 bit
+ Solaris.
+
+ Validated test suite for 64 bit Solaris 8 and gcc.
+
+ At the request of Alek O. Komarnitsky <alek@komar.org>
+ added the "+c <width>" option to enable optional
+ changing of the COMMAND column output maximum width
+ from the default to <width>. The default maximum
+ width remains CMDL, as defined in lsof.h.
+
+ Fixed three AIX kernel bit size detection bugs,
+ one in the AIX Configure script stanza, the second
+ and third in the AIX dproc.c get_kernel_access()
+ function. The bugs were reported by Pierre-Yves
+ Fontaniere <pyf@cc.in2p3.fr>, who tested the fixes.
+
+ Added kernel event queue file support for FreeBSD,
+ NetBSD and OpenBSD. Andrew Brown <atatat@atatdot.net>
+ supplied the code.
+
+ Updated to AIX 5.2 on a test system provided by
+ Dale Talcott <dtalcott@purdue.edu>. Had to build
+ work-arounds for two missing AIX 5.2 header files,
+ <j2/j2_snapshot> and <proc/proc_public.h>. Corrected
+ an off-by-one UNIX socket addressing bug. Taught
+ AIX lsof to handle both jfs and jfs2 files at the
+ same time. Adjusted for an IBM mistake in the
+ sizing of the fdsinfo structure in <procinfo.h>
+ Toshiya Nakamura <TOSHIYAN@jp.ibm.com> helped test,
+
+ Updated to FreeBSD 4.8. Corrected another bug in
+ FreeBSD UNIX domain socket name handling.
+
+ Corrected gcc build problems on HP-UX 11i, reported
+ by Yuliy Minchev <yuliy@mobiltel.bg>.
+
+ Updated BSDI BSD/OS support to 4.3.1.
+
+ Augmented a lock ID test on NetBSD to check if the
+ ID is an LWP pointer.
+
+4.68 June 18, 2003
+ Enhanced Configure script's cleanup operations.
+
+ Added support for OpenBSD 3.3, based on a report
+ from Peter Valchev <pvalchev@sightly.net>.
+
+ Improved the description of the detached PGP
+ signature certificate file in the main lsof README
+ file, based on a suggestion from Diana Stockdale
+ <diana@mpl.ucsd.edu>.
+
+ Installed a work-around for FreeBSD 5.0-CURRENT on
+ Alpha to avoid a compiler register use complaint.
+
+ Corrected a 'c' option error message. Gnele
+ <blaadeleng@yahoo.com> reported the problem.
+
+ Upgraded EXT2FS and UFS support for NetBSD and
+ OpenBSD to handle new inode information, and the
+ fast UFS1 and UFS2 file systems.
+
+ With the help of Andrew Brown <atatat@atatdot.net>
+ determined the NetBSD snapshot (1.6F) at which
+ <sys/mount.h> could be included under _KERNEL, thus
+ eliminating the lsof netexport.h hack. The same
+ change applies to OpenBSD versions 3.3 and above.
+
+ Applied a patch from Armin Gruner <ag@muc.de> that
+ corrects the use of the HASPROCFS definition in the
+ FreeBSD dialect sources.
+
+ Corrected spelling errors in 00FAQ and in the
+ generated 00.README.FIRST_<version> file of the
+ distribution archive. John Jackson <jrj@purdue.edu>
+ and Ray Phillips <r.phillips@jkmrc.uq.edu.au>
+ spotted and reported the errors.
+
+ Corrected a spelling error in a comment and incorrect
+ use of an alarm function in the LTsock test program.
+
+ At the suggestion of Stuart Anderson <sba@srl.caltech.edu>
+ added preliminary (and incomplete) SAM-FS file system
+ support to Solaris lsof. Completion awaits availability
+ of SAM-FS internals.
+
+ Fixed a Solaris device name printing bug, reported by
+ Ric Anderson <ric@tick.Telcom.Arizona.EDU>, only
+ visible when HASDCACHE is not defined. Ric helped
+ test the fix.
+
+ Fixed an AIX kernel bit size handling bug related
+ to the NFS node (rnode) structure.
+
+ Corrected a print_kptr() function call error in the AIX
+ AFS code, reported by David Steiner
+ <david.r.steiner@Dartmouth.EDU>. Upon further reflection
+ and because I no longer have appropriate AIX AFS test
+ systems, disabled AIX AFS support in the Configure script
+ for AIX versions above 4.3.3.0 or AIX AFS versions above 3.5.
+
+ Added support for FreeBSD 5.1.
+
+ With advice from Allan Nathanson <ajn@apple.com> adjusted
+ the Darwin get-xnu-headers.sh script to access the kernel
+ header files needed by lsof from a new form of the Apple
+ open source repository.
+
+ Installed Linux and lsof library bug fixes and
+ improvements, supplied by Marian Jancar <mjancar@suse.cz>.
+ One Linux improvement handles mount strings that
+ have octal escapes in them, eg., \040 for embedded
+ blanks. Marian tested the changes.
+
+4.69 October 16, 2003
+ Received and applied an OpenBSD patch from Peter Valchev
+ <pvalchev@sightly.net> that replaces a ctob() call with
+ a sysconf() call. Peter claims sysconf() is needed for
+ OpenBSD on SPARC. (It is not needed for NetBSD on SPARC.)
+
+ With the upgrade of my only Solaris 7 test system
+ to, Solaris 8, dropped the *claim* that lsof works
+ on Solaris 7. That doesn't mean it won't work
+ there, so those who want lsof for Solaris 7 probably
+ should be able to build it there and it probably
+ will work there.
+
+ Revised lsof's DNLC handling for BSD derivatives,
+ including: BSDI; Darwin, DEC OSF/1, Digital UNIX
+ and Tru64 UNIX; FreeBSD; NetBSD; and OpenBSD. The
+ latest NetBSD distribution's dropping of the vnode
+ capability ID (v_id) required the revision.
+
+ Adjusted to the latest FreeBSD 5.1-CURRENT.
+
+ Added NetBSD support for using kvm_getproc2().
+
+ Added a patch from Andrew Brown <atatat@atatdot.net>
+ to handle NetBSD enum conflicts and changes in the
+ <miscfs/kernfs/kernfs.h> and <miscfs/procfs/procfs.h>
+ header files.
+
+ Added a "#define _KERNEL" to the AIX dnode2.c source
+ file for compatibility with a new <j2/j2_inode.h>
+ AIX 5.2 header file version. The addition was
+ supplied by Dick Dunbar <Dick.Dunbar@Siebel.com>
+ and was offered as a patch to lsof 4.68/
+
+ Added support for a second type of Solaris SAMFS.
+ Stuart Anderson <sba@srl.caltech.edu> provided the
+ support. SAMFS support in lsof SOLARIS remains
+ scanty, because Sun won't release any details on
+ its kernel structures.
+
+ Dropped the *claim* that lsof works on AIX 4.3.3,
+ because I was unable to test it there. That doesn't
+ mean it won't work there, so those who want lsof
+ for AIX 4.3.3 probably should be able to build it
+ there and it probably will work there.
+
+ Updated for Solaris 10 on test systems provided by
+ Mike Miscevic <miscevic@hotpop.com>. Casper Dik
+ <casper@holland.sun.com> provided significant help.
+ During the Solaris 10 port found and fixed an lofs
+ handling bug that prevented reporting of open lofs
+ file lock status.
+
+ Updated the DNLC test, LTdnlc, to provide a possible
+ explanation about file systems on which the test
+ might fail.
+
+ Modified the procedure for obtaining missing Darwin
+ XNU kernel header files. The new one requires more
+ manual intervention, but is the best that can be
+ done with the way Apple open sources are now
+ organized. 00FAQ explains the new procedures for
+ those not used to downloading Apple open source
+ files.
+
+ Added support for Apple Darwin 7.0 (Mac OS X 10.3)
+ with patches supplied by Allan Nathanson <ajn@apple.com>.
+ Dropped the *claim* that lsof builds and works on
+ Apple Darwin below 6.0.
+
+ Validated lsof on FreeBSD 4.9, using a test system
+ provided by Ben Lewis <bl@purdue.edu>.
+
+ Validated lsof on FreeBSD 5.1-CURRENT for Amd64.
+ David O'Brien <obrien@FreeBSD.org> provided a test
+ system.
+
+ Changed the NetBSD Configure stanza to do header
+ file searches in /usr/include by default. The
+ LSOF_INCLUDE and NETBSD_SYS environment variables
+ may still be used to specify other search paths.
+ Discussions with Andrew Brown and Wolfgang S.
+ Rupprecht <wolfgang@wsrcc.com> led to the change.
+
+4.70 January 16, 2004
+ Improved shell-portability of the linux stanza of
+ the Configure script with a patch from Paul Jarc
+ <prj@po.cwru.edu>.
+
+ Added a "silent" rule to tests/Makefile for Paul.
+ Updated, extended and clarified the test suite
+ documentation in 00FAQ and 00TEST.
+
+ Fixed Solaris 10 dlsof.h typo, reported by Mike
+ Miscevic <miscevic@hotpop.com>. The typo prevents lsof
+ from loading cleanly in Solaris 10 builds past 40.
+
+ Fixed a Solaris HSFS node number reporting bug and
+ added a structure definition work-around for Solaris
+ 10.
+
+ Converted PGP signing to GPG. My previous PGP key can
+ be used, but the gpg "--allow-non-selfsigned-uid"
+ option may have to be used when it is imported into a
+ GPG key ring.
+
+ Added bz2 compression.
+
+ Updated for OpenBSD 3.4.
+
+ Added a work-around for a missing header file in the
+ s10_44 Solaris 10 build.
+
+ Added support for FreeBSD 5.2-BETA and 5.2-CURRENT.
+
+ Updated Linux AX25 support with modifications supplied
+ by Lutz Poetschulat <dl9cu@db0zwi.de>.
+
+ Added raw IPv6 support to Linux lsof.
+
+ Improved handling of parameters after "-i@".
+
+ Improved file name test in LTdnlc.c.
+
+ Added loop count controls to the reading of Solaris
+ lock chains. The change was implemented as a result of
+ a report from Steve Gonczi <steve@relicore.com>.
+
+ Based on a report from John Jackson <jrj@purdue.edu>,
+ enabled a Solaris 10 <sys/lgrp.h> work-around for
+ Solaris 9, too. (Patch 112233 installs an lgrp.h on
+ Solaris 9 that needs the work-around.)
+
+ With help from Andrew Brown <atatat@atatdot.net> and
+ John Heasley <heas@netbsd.org> added log-structured
+ file system (LFS) support for NetBSD and OpenBSD.
+
+ Added AMD64 to the list of FreeBSD 5.x-CURRENT
+ supported architectures. FreeBSD.org provides a test
+ system, courtesy of (I believe) David O'Brien
+ <obrien@FreeBSD.org>.
+
+ Added a cast to lseek() in the HP-UX /dev/kmem-based
+ kread() function to make it work properly with the
+ bundled HP C compiler.
+
+4.71 March 11, 2004
+ Added text file support to Apple Darwin lsof and
+ enabled the lsof executable portion of the LTbasic
+ test. Added support for Darwin kernel queue, POSIX
+ semaphore and POSIX shared memory files. Tested on
+ Darwin 7.2 (aka Mac OS 10.3.2).
+
+ Added process_kqueue() function prototypes for FreeBSD,
+ NetBSD and OpenBSD.
+
+ Picked some lint in AIX sources, lib/rnmh.c and
+ tests/LTsock.c.
+
+ Added "-x [fl]" cross-over option, which enables +d and
+ +D processing to cross over symbolic links and|or file
+ system mount points. Discussion with Johan Lindquist
+ <johan@smilfinken.net> and Eric Williams (aka The Ghost
+ In The Machine) <ewill3@earthlink.net> on Linux news
+ groups revealed the need for the option.
+
+ Updated support for UnixWare 7.1.4.
+
+ Added support for the optional reporting of socket
+ options, socket states and TCP flags for most currently
+ supported dialects. John Smith <lbalbalba@hotmail.com>
+ and Tristan Nefzger <tn@bhtrader.com> requested the
+ information. The dialects and their versions for which
+ this feature has become available include:
+
+ AIX 4.3.2 and 5.[12]
+ Apple Darwin 7.2
+ BSDI BSD/OS 4.3.1
+ Digital UNIX and Tru64 UNIX 4.0
+ FreeBSD 4.9 and 5.2
+ HP-UX 11 and 11.11 (aka 11i)
+ NetBSD 1.6ZH
+ OpenBSD 3.4
+ OPENSTEP 4.2
+ OpenUNIX 8
+ SCO OpenServer Release 5.0.6
+ Solaris 2.6, 8, 9 and 10
+ UnixWare 7.1.[134]
+
+ Modified the Configure stanza for HP-UX 11 with better
+ q4 detection. Steve Bonds <3vhmxxm02@sneakemail.com>
+ supplied the modification.
+
+ Applied a patch from Mike Miscevic <miscevic@hotpop.com>
+ to enable lsof to compile with the zone support in the
+ Solaris 10 s10_b51 release. Added information on lsof
+ zone behavior to 00FAQ.
+
+ Added a "-z [z]" option to Solaris 10 lsof. It enables
+ the listing of zone name and can also be used to select
+ the listing of processes and their files from specified
+ zones.
+
+4.72 July 13, 2004
+ Corrected Solaris 10 ZONE column title display bug with
+ a patch from Joep Vesseur <Joep.Vesseur@Sun.COM>. Joep's
+ fix was offered as a patch to 4.71.
+
+ Based on a report from Jean-Pierre Radley <jpr@jpr.com>
+ about an unexpected GNU uname Configure interaction on
+ OSR, and working from information received from Bela
+ Lubkin, changed the OSR Configure stanza to use
+ /bin/uname instead of uname. Added an FAQ entry about
+ Configure version detection problems.
+
+ Added the +m and "+m m" options in response to a dialog
+ with Robert T. Brown <rbrown@netmentor.com>. The
+ options allow the creation of a mount table supplement
+ file which can be used on selected dialects to get
+ device numbers when stat(2) and lstat(2) can't deliver
+ them. (That's generally the result of an inaccessible
+ NFS server.) Currently the new options are supported
+ only on Linux.
+
+ Made cpumask_t typedef _KERNEL compensation for FreeBSD
+ 5.2-CURRENT. Refined it for 5.2.1-RELEASE with testing
+ help from Scott Ellentuch <tuc@ttsg.com>.
+
+ Added support for FreeBSD 4.10. Larry Rosenmann
+ <ler@lerctr.org> kindly provided a test system.
+
+ Added support for NetBSD 2.0 with patches supplied by
+ Andrew Brown <atatat@atatdot.net>. Andrew also
+ provided two test systems.
+
+ Made handling of Linux maps file more robust, based on
+ a report from Jan Blunck <J.Blunck@tu-harburg.de>. As
+ a side benefit, made handling of generated stat(2)
+ information more flexible.
+
+ As a result of a discussion with Jason Fortezzo
+ <fortezza@mechanicalism.net>, adjusted lsof for Solaris
+ to obtain the maximum user name length from ut_name of
+ the utmpx structure, if <utmpx.h> exists.
+
+ Tested under OpenBSD 3.5.
+
+ Updated 00README information about using gcc (via the
+ Configure aixgcc abbrevisiation) to compile lsof on
+ AIX. Ann Janssen <ajanssen@nebook.com> made me aware
+ the information was out of date.
+
+ Added an AIX SIGDANGER handler and some 00FAQ sections
+ on lsof memory usage after a discussion with Tom Qin
+ <tom.qin@citigroup.com> about lsof memory usage.
+
+ Added scripts/sort_res.perl5, contributed by Fabian
+ Frederick <fabian.frederick@gmx.fr>. The script
+ displays lsof output sorted by size and path name.
+
+ Improved handling of files on Linux NFS mount points
+ that use the root_squash option, based on discussions
+ with Paul Szabo <psz@maths.usyd.edu.au>.
+
+ Updated FreeBSD 5.2-CURRENT support, based on a problem
+ report from Filippo Natali <filippo@widestore.net>.
+
+ Corrected improper FreeeBSD 5.x-CURRENT #if condition,
+ reported by Kim Culhan <kimc@kim.net>.
+
+ Added a Configure script work-around for AIX 5.2 lsof
+ with JFS2, compiled by gcc >= 3.3. The work-around
+ was supplied by Florian M. Weps <fmw@hactrn.ch>.
+
+4.73 October 21, 2004
+ Added an __XPG4_CHAR_CLASS__ #define before
+ #include'ing <ctype.h> on Solaris to restore lsof's
+ ability to display special characters such as acute-e.
+
+ Added wide-character (e.g., UTF-8) support where
+ possible, prompted by a request from Kyungjoon Lee
+ <kjoonlee@gmail.com>. Some older dialects -- e.g.,
+ NetBSD 1.4.1 -- don't support wide characters, so the
+ wide character support is enabled by definitions in
+ each dialect's machine.h. Dialects with wide-
+ character support are listed in 00FAQ.
+
+ Make a FreeBSD 5.2-CURRENT adjustment for <sys/pipe.h>,
+ supplied by Sergey A. Osokin <osa@FreeBSD.ORG>.
+
+ Implemented a Linux feature request made by Jakub
+ Jelinek <jakub@redhat.com> that enhances lsof's ability
+ to locate UNIX domain sockets whose paths are named as
+ arguments. Jakub supplied suggested code.
+
+ Dropped *claims* that lsof works on AIX below 5.1, SCO
+ Dropped *claims* that lsof works on AIX below 5.1, SCO
+ Openserver 5.0.4, Tru64 UNIX 5.0, and UnixWare below
+ 7.1.4. Lsof will probably build and work on those UNIX
+ dialect versions, but I no longer have any way to test
+ lsof on them.
+
+ Added support for FreeBSD 5.3 and 6.0. The FreeBSD
+ 5.3 support hasn't been tested.
+
+ Added FD test code that will allow dialect versions to
+ test FD option selections. Used the new code in the
+ PSTAT-based HP-UX lsof to enable it to avoid scanning
+ the mount table when its information is not needed.
+ The addition was made in response to a query from
+ Harvey Garner <Harvey.Garner@championusa.com> about
+ lsof performance in a busy NFS environment.
+
+ Upgraded lsof's AIX support level to AIX 5.3, based on
+ a report from Dick Dunbar <Dick.Dunbar@Siebel.com>. (I
+ have not tested lsof under AIX 5.3.) Based on Dick's
+ recommendation and local testing changed the C for AIX
+ version 6 and higher -qmaxmem option value to -1.
+
+ Made LSOF_AR environment variable more useful and
+ documented it in 00XCONFIG.
+
+ Corrected the use of sum(1) to generate signatures for
+ the lsof distribution and binaries to match the
+ documentation that claims it is sum -r output. Jin
+ Guojun <jin@george.lbl.gov> noticed and reported the
+ problem.
+
+ Tested under OpenBSD 3.6.
+
+ Added checksum and GPG certificate files for the bz2,
+ gz and Z lsof distribution archives. The new files
+ reside with the distribution archives and supplement
+ the signature information already inside the archives.
+
+ Validated on Solaris 10, i8xpc, build s10_63.
+
+4.74 January 17, 2005
+ Fixed a Solaris segment fault bug on systems that lack
+ a /dev/allkmem device. Offered the fix as a patch to
+ lsof 4.73. The bug was reported by Donald Zoch
+ <donald.zoch@amd.com>.
+
+ Updated lsof for FreeBSD 6.0 and higher for a change in
+ <sys/vnode.h>, based on a report from Sergey A. Osokin
+ <osa@FreeBSD.ORG>. Made the update available in a 4.74
+ 'A' edition pre-release.
+
+ Filed an HP bug report about missing pstat(2) CWD info
+ for LOFS on HP-UX 11.11 and higher. The missing CWD
+ info was noticed by Ermin Borovac <e.borovac@bom.gov.au>.
+ Added info to 00FAQ about the problem, which can cause
+ the lsof test suite's LTbasic test to fail.
+
+ Updated the q4-generated tcp_s.h in the lsof
+ distribution and added socket option support for HP-UX
+ 11.00. Erwin Reyns <ereyns@europarl.eu.int> helped
+ test.
+
+ Updated for Solaris 10, build s10_69, with a patch
+ supplied by Mike Miscevic <miscevic@hotpop.com>.
+
+ Added v_path support to Solaris 10 lsof. That relieves
+ it of having to read and decode the kernel DNLC, and
+ delivers full paths more reliably.
+
+ Added specialized NFS4 support to Solaris 10 lsof.
+
+ Applied Solaris 10 patches to lsof supplied by Casper
+ Dik <casper@holland.sun.com>.
+
+ Updated lsof for NetBSD 2.99.10 and tested it on a
+ system provided by Andrew Brown <atatat@atatdot.net>.
+
+ Added support for the FreeBSD 6.0-CURRENT f_vnode
+ pointer in the file structure.
+
+ Added BSDI, FreeBSD, NetBSD and OpenBSD support for the
+ *effnlink member of the inode structure. This makes
+ the lsof LTnlink test run faster on all modified
+ dialects and correctly on OpenBSD.
+
+ Added ptyfs support for NetBSD, using modifications
+ provided by Andrew Brown.
+
+ Changed the netbsd Configure stanza to look by default
+ for system header files in both /usr/include and
+ /usr/src. (The NETBSD_SYS environment variable can
+ still be used to select an alternate for /usr/src.)
+
+ Corrects two FreeBSD 4.10 RPC/XDR type definitions.
+
+ Added an FAQ Q&A about setuid and setgid restrictions
+ in HP-UX 11.11. The information in the answer was
+ supplied by Frank Sanders <frank.sanders@siemens.com>.
+
+ Added abbreviations for AXI FCIO and FSNAPSHOT file
+ flags. Holger VanKoll <Holger.VanKoll@swisscom.com>
+ reported the missing FCIO.
+
+ Adjusted lsof's private AIX 64 bit rnode structure for
+ 64 bit AIX 5.2 systems. (IBM doesn't distribute a
+ correct <nfs/rnode.h> for it.)
+
+ Corrected a Linux socket inode printing bug reported by
+ Igor Schein <igor@txc.com>.
+
+ Updated for FreeBSD 4.11. The support compiles but
+ hasn't been tested.
+
+ Back-ported a FreeBSD 6.0-CURRENT fix to FreeBSD
+ 5.3-RELEASE-p1. That was done to solve a compilation
+ problem reported by Radko Keves <rado@daemon.sk>.
+
+4.75 May 16, 2005
+ Dropped the *claim* that lsof works on DEC OSF/1 and
+ Digital UNIX, since my last 4.0 test system has been
+ removed. The last tested distribution of lsof on DEC OSF/1
+ and Digital UNIX was revision 4.74. It has been archived
+ on lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
+
+ Added negation forms to the values in the -g (PGID) and
+ -p (PID) lists. Negated PGID and PID values, like
+ negated UID or login name values, are applied without
+ ORing or ANDing and take effect before any other
+ selection criteria are applied.
+
+ At the request of Marcin Gozdalik <gozdal@gmail.com>
+ added a -X option for Linux. The option inhibits the
+ reading of the /proc/net/tcp* and /proc/net/udp*
+ files.
+
+ Based on a report from David Gutierrez
+ <davegu1@hotmail.com> changed DEC OSF/1 process table
+ allocation to request memory in smaller increments.
+
+ Based on a report from jayjwa <jayjwa@atr2.ath.cx>
+ updated the Customize script to use "tail -n 1" where
+ possible.
+
+ Enabled support for FreeBSD 5.4.
+
+ Improved the BSDI, FreeBSD, NetBSD, OpenBSD and Solaris
+ kvm_open() and kvm_openfiles() error messages.
+
+ Enabled support for NetBSD 2.99.12.
+
+ Improved HP-UX Configure stanza with help from Piet
+ Starreveld <pstarrev@csc.com>. Picked some lint Piet
+ found.
+
+ Enabled IPv6 support for HP-UX > 11. Piet Starreveld
+ helped test it on 11.23, among others.
+
+ Updated for HP-UX 11.23 on the ia64 architecture.
+
+ Updated to latest FreeBSD 6.0-CURRENT, using a test
+ system provided by Andrzej Tobola <ato@iem.pw.edu.pl>.
+
+ Added support for SCO OSR 6.0.0 and UnixWare 7.1.4 with
+ help from Richard at SCO.
+
+ Corrected a Linux bug in NFS handling, reported by Karel Zak
+ <kzak@redhat.com>. Karel supplied a patch.
+
+ Improved the code for accessing an AIX 3.2 and higher
+ sockaddr_un structure, thus eliminating a segmentation
+ fault possibility.
+
+ Updated for AIX 5.3.
+
+ Added preliminary (DEBUG) support for the AIX SANFS
+ file system.
+
+ Fixed a bug in the Solaris 10 processing of the vnode's
+ v_path pointer with code supplied by Edward Jajko
+ <ejajko@portal.com>. The fix was offered as a patch to
+ 4.74.
+
+ Dropped support for OpenUNIX 8, since a test system is
+ no longer available. Archived an OpenUNIX-only
+ distribution of the last revision (4.74) tested on
+ OpenUNIX in pub/tools/unix/lsof/OLD/src.
+
+ Tested under Openbsd 3.7.
+
+ Tested under Darwin 7.7.0.
+
+ Enabled building on amd64 Solaris 10 with hints from
+ Marc Aurele La France <tsi@ualberta.ca>. Marc provided
+ a test system.
+
+ Supplied a missing quote in the FreeBSD Configure
+ stanza. Carl Cook <Info@quantum-sci.com> reported the
+ problem.
+
+ Removed "-O" option from tests/Makefile so that the
+ HP-UX bundled compiler won't complain.
+
+4.76 August 30, 2005
+ Corrected an example and spelling errors in man page.
+
+ Updated for Apple Darwin 8.x with changes supplied by
+ Allan Nathanson <ajn@apple.com>. Allan also provided a
+ test system.
+
+ Completed documentation of CLRLFILEADD in all machine.h
+ files.
+
+ At the request of Chris Markle <cmarkle@sendmail.com>
+ added partial listen queue length to socket options
+ displayed when -Tf is specified. Partial queue length
+ is not reported for all dialects. (00FAQ lists the
+ ones where it is reported.)
+
+ Updated for FreeBSD 7.0 with information supplied by
+ Andrzej Tobola <ato@iem.pw.edu.pl>.
+
+ Updated Solaris VxFS support for VxFS versions 4 and
+ above with technical advice from Craig Harmer
+ <craig_harmer@symantec.com>, Gary Millen
+ <gary_millen@symantec.com> and Chuck Silvers
+ <charles_silvers@symantec.com>. Testing help was
+ provided by Michael Antlitz <mantlitz@prophasys.com>,
+ Steve Ginsberg <steve@dhapdigital.com> and Kenneth
+ Stailey <kstailey@yahoo.com>.
+
+ Fixed a Solaris address space map processing bug.
+ Janardhan Molumuri <mjanardhan@gmail.com> reported the
+ bug and help me identify it. Made the fix available as
+ a patch to 4.75.
+
+ Added support for Solaris 10 port and CTFS files. The
+ CTFS support is imcomplete, because I don't know how
+ to get inode number, size and link count. (There's
+ a new 00FAQ entry about that.)
+
+ Investigated a report from Christopher J Warweg
+ <warwegc@GAO.GOV> that the CHECKSUMS for the lsof 4.75
+ binary for 64 bit Solaris 8 was incorrect. It was my
+ packaging error. I rebuilt and repackaged the binary.
+
+ Enabled support for Linux map file names with embedded
+ spaces.
+
+4.77 April 10, 2006
+ Added -X option support for Solaris 10 and above. When
+ -X is specified lsof will report cached v_node path
+ names for unlinked files, followed by "(deleted)".
+ Improved cached vnode path name handling by adding
+ "(?)" to the end of path names of questionable accuracy.
+ Updated 00FAQ to reflect these changes.
+
+ Updated for FreeBSD 7.0-CURRENT.
+
+ Fixed name addition spacing bug, reported by Stuart
+ Anderson <anderson@ligo.caltech.edu>. Also updated
+ Solaris 10 SAMFS support at Stuart's request.
+
+ Added missing "break;" and another HASSTATVFS test to
+ the NetBSD and OpenBSD dnode.c. Bill Behr
+ <bbehr@networkstoragecorp.com> reported those needs.
+
+ Fixed an HP-UX 11 file descriptor "chunk" size problem,
+ reported by Per Allansson <per@appgate.com>. Per helped
+ devise the fix and tested it. This fix was offered as
+ a patch to lsof 4.76.
+
+ Updated for FreeBSD 6.0-STABLE and FreeBSD
+ 6.1-PRERELEASE.
+
+ Updated scripts/sort_res.perl5 with changes supplied by
+ Frederick Fabian <fabian.frederick@skynet.be>, the
+ author of the script.
+
+ Corrected +|-M man page documentation error, reported
+ by Roger Cornelius <rac@tenzing.org>.
+
+ Improved FreeBSD user device random seed generation in
+ response to a problem report from Danny Braniss
+ <danny@cs.huji.ac.il>.
+
+ Eliminated three syntax error bugs and other compiler
+ complaints from the PSTAT-based lsof. H. Merijn Brand
+ <h.m.brand@xs4all.nl> reported the problems and tested
+ the fixes.
+
+ Eliminated compiler complaints in the test suite.
+
+ Investigated problems with the building of lsof on
+ PA-RISC HP-UX 11.23, based on a report from John
+ Orndorff <John.Orndorff@sungard.com>. Found that
+ neither the HP bundled C compiler nor gcc would build
+ lsof, but the the HP unbundled ANSI C compiler would.
+ Concluded that HP bundled C compiler can't handle
+ <gssapi/gssapi.h>. Devised a work-around to gcc's
+ omission of the rpcent structure definition of
+ <netdb.h> that allows it to compile lsof's print.c, but
+ the resulting binary doesn't run reliably. Documented
+ the situation in 00FAQ.
+
+ Changed reporting of unknown file types. The number of
+ an unknown type is now reported as four octets. The
+ change was made in response to a Linux lsof bug report
+ from Karel Zak <kzak@redhat.com>.
+
+ Dropped the *claim* that lsof works on BSDI BSD/OS
+ since my last test system has been removed. The last
+ tested distribution of lsof for BSDI BSD/OS was
+ revision 4.76. It has been archived on
+ lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
+
+ As a result of discussing the lsof source tar's MD5
+ checksum with Andrew Bell <andrew.bell.ia@gmail.com>,
+ changed the description of a suitable MD5 tool in the
+ lsof distribution's documentation to name the openssl
+ "dgst" command.
+
+ Enabled compilation on Solaris 10 1/06 with a fix sent
+ by Jason Fortezzo <fortezza@mechanicalism.net>. Made
+ the fix available as a patch to 4.76.
+
+ Adjusted to FreeBSD 5.5-PRERELEASE.
+
+ Corrected a bug in the lsof library's process_file()
+ function to enable the locating of AIX XTI sockets by
+ their TCP/IP address values. The bug was reported by
+ Michel Dubois <Dubois@sears.ca>.
+
+ Based on a bug report from Karel Zak <kzak@redhat.com>
+ added command name length checking to as many dialects
+ as possible (Linux for Karel) for the "-c c" option.
+
+ Updated for OpenBSD 3.[89]. Tested the 3.9 update on a
+ system provided by David Mazieres. I have not tested
+ on OpenBSD 3.8, but David reports lsof 4.76 worked
+ there.
+
+ Ended regression testing of lsof on 32 bit Solaris 8
+ with the ending of access to a test system. Lsof
+ continues to be tested on 64 bit Solaris 8.
+
+4.78 April 24, 2007
+ Added more information to the lsof FAQ about missing
+ link counts and sizes on Linux files.
+
+ Simplified Linux stat() and lstat() usage.
+
+ Relocated #define's that prevent OpenBSD compilation on
+ systems without a /proc file system. Pieter Bowman
+ <bowman@math.utah.edu> reported the problem.
+
+ Added code to avoid processing Linux /proc/<PID>/maps
+ file entries with zero device and node numbers. Some
+ such entries now have names associated with them that
+ are not path names -- e.g., "[heap]", "[stack]" or
+ "[vdso]". Scott Worley <sworley@chkno.net> reported
+ lsof's mishandling of such entries.
+
+ Added SELinux security context support, provided by
+ James Antill <james.antill@redhat.com>. I have not
+ tested this, but James and Karel Zak <kzak@redhat.com>
+ have.
+
+ Added the #include of <sys/types.h> to Solaris lsof to
+ enabled compilation on Solaris 10 6/06. Peter Harvey
+ Peter.Harvey@Sun.COM diagnosed the problem and supplied
+ a patch.
+
+ Added better support for JFS2 on AIX 5.2 and 5.3, based
+ on bug reports and help from Thomas Braunbeck
+ <BRAUNBEC@de.ibm.com> and Tom Whitty <TWHITTY@cerner.com>.
+
+ Documented that lsof supports AIX 5.3 only up through
+ maintenance level 1 (ML1).
+
+ Enabled Solaris lsof to locate the AFS vnode operation
+ address for OpenAFS 1.4.1. The fix was supplied by
+ Robert Jelinek <Robert.Jelinek@MorganStanley.com>.
+
+ Enabled support for Solaris 10 ZFS. If the necessary
+ ZFS header files aren't found, lsof offers the option
+ to drop ZFS support, to use internal, possibly
+ inaccurate structure definitions, or to supply a path
+ to the missing header files. Horst Scheuermann
+ <Horst.Scheuermann@uni-trier.de> provided a development
+ system and helped test the support.
+
+ Corrected a typo in the man page, reported by Eric S.
+ Raymond <esr@thyrsus.com>.
+
+ Changed the spelling of macroes to macros in lsof
+ source and documentations files, based on a suggestion
+ from Josh Soref <timeless@gmail.com> and verification
+ with the OED.
+
+ The following dialects are no longer supported: 32 bit
+ AIX 5.2, HP-UX 11, OpenStep 4.2, Solaris 2.6, Solaris
+ 8, True Unix 64 and UnixWare 7.1.4. Lsof may work on
+ them, but I no longer have test systems for them.
+ Support for OpenBSD ends at its version 3.9 for lack of
+ interest in the port.
+
+4.79 April 15, 2008
+
+ **************** IMPORTANT NOTE ******************
+ * *
+ * Lsof support has been reduced to the following *
+ * dialects: AIX, FreeBSD, Linux and Solaris, and *
+ * only in selected versions of those dialects. *
+ * The selected versions are listed in this file *
+ * and in other lsof documentation. *
+ * *
+ * I have made this move because of retirement *
+ * and because I no longer have many test systems *
+ * available to me. *
+ * *
+ * Vic Abell *
+ * *
+ **************************************************
+
+ Fixed a Solaris VXFS permission problem when accessing
+ the VXFS inode offsets. The bug was reported by
+ Gregory A. Ivanov <ivga@mts.ru>. Gregory tested the
+ fix.
+
+ Moved an #include <string.h> later in FreeBSD dlsof.h
+ to enable compilation on recent FreeBSD releases. The
+ change was supplied by Roy Marples <uberlord@gentoo.org>.
+
+ Improved Linux /proc file stream reading speed by applying
+ an expanded version of a patch from Eric Dumazet
+ <dada1@cosmosbay.com> that allocates a page size buffer
+ to each stream. Improved TCP, TCP6, UDP and UDP6 hashing
+ by determining the hash bucket count from the /proc/net
+ sockstat and sockstat6 files. The improvement was
+ suggested by Eric and he provided sample code. Eric also
+ tested both improvements.
+
+ Modified Configure script to build lsof on FreeBSD
+ 6.2. Tested it on a system provided by Larry Rosenman
+ <ler@lerctr.org>.
+
+ Fixed a Linux maps file processing bug that prevented path
+ names from having an embedded colon. James Lingard
+ <jchl@arastra.com> reported the bug and helped with its
+ fix.
+
+ Based on reports from Eric Dumazet and Samuel Thibault
+ <samuel.thibault@ens-lyon.org> added support for the
+ Linux 2.6.22 kernel's /proc/<PID>/fdinfo files -- i.e.,
+ file offset and flags. Samuel Thibault provided a test
+ system.
+
+ Fixed a Linux UNIX socket memory leak, reported by
+ Philip Shin <pshin@xceedium.com>. Phillip supplied the
+ fix.
+
+ With generous assistance from HP added support for an HP-UX
+ 11.23 patch that makes TLI/XTI socket address information
+ available.
+
+ Fixed a header file problem for FreeBSD 6.2 on the Alpha
+ architecture. The problem was reported by Pekka Honkanen
+ <phonkane@cc.hut.fi>. Pekka tested the fix.
+
+ Based on a report and using suggested fixes from Karel Zak
+ <kzak@redhat.com>, made these changes to Linux lsof: corrected
+ a getpidcon() error message; insured that inode numbers are
+ handled correctly for their unsigned long long type; and
+ improved SELinux handling. At the request of Alon Bar-Lev
+ <alonbl@gentoo.org> added the LINUX_HASSELINUX environment
+ variable to enable or inhibit SElinux support unconditionally.
+
+ Updated Configure for FreeBSD 8.0-CURRENT and tested lsof on
+ AMD64 there.
+
+ Added a patch provided by Oles Hnatkevych
+ <don_oles@able.com.ua> for FreeBSD systems where the root
+ file system is on a CD9660 device.
+
+ Added compensation for the disappearance of FMARK and FDEFER
+ from the FreeBSD 8.0-CURRENT <sys/file.h>.
+
+ Updated FreeBSD lsof with ZFS support. Larry Rosenman
+ <ler@lerctr.org>, Erwin Lansing <erwin@FreeBSD.org>, Wesley
+ Shields <wxs@atarininja.org> and Dmitry Morozovsky
+ <marck@rinet.ru> provided test systems.
+
+ Fixed a socket file identification problem reported by
+ Pavol Rusnak <stick@gk2.sk>. Pavol also reported the
+ cause of the problem.
+
+ Added the ability to format the repeat mode marker line
+ with strftime(3), where the dialect supports the
+ localtime(3) and strftime(3) C library functions. The
+ addition was suggested by Mike Depot <mdepot@comcast.net>,
+ who also tested it. The addition required creating a new
+ main lsof source module, util.c, that contains functions
+ whose compilation conflicts with the general header file
+ tree defined by lsof.h and dlsof.h.
+
+ Based on reports from Andrei V. Lavreniyuk
+ <andy.lavr@reactor-xg.kiev.ua> and Pav Lucistnik
+ <pav@FreeBSD.org> updated the FreeBSD 7.0 and above
+ file lock handling to use new locking structures. The
+ update requires a terrible hack to get a definition for
+ the lock owner structure from a kernel source module
+ into a local lsof header file.
+
+4.80 May 12, 2008
+ Updated for a FreeBSD 7.0 and above byte level locking
+ change. The problem was reported by Conrad J. Sabatier
+ <conrads@cox.net>, who helped test the update. Wesley
+ Shields <wxs@FreeBSD.org> provided an 8.0-CURRENT test
+ system.
+
+ Propagated the FreeBSD 7.0 and above locking changes to
+ FreeBSD 6.x, based on a report from Edwin Groothuis
+ <edwin@FreeBSD.org>.
+
+ Added warnings for unsupported dialects or versions.
+
+ Added Linux support for the UDPLITE protocol. Eric
+ Dumazet <dada1@cosmosbay.com> supplied a patch.
+
+ Added a missing quote to the Configure script's
+ FreeBSD stanza.
+
+ Added a usage.o rule to the HP-UX PSTAT-based
+ Makefile. I mistakenly deleted the rule at revision
+ 4.79. The missing rule was reported by Kawaljeet Kaur
+ <kawaljeet.malviya@gmail.com> who tested the corrected
+ Makefile.
+
+4.81 October 21, 2008
+ Updated the Darwin libproc sources with changes from
+ Allan Nathanson <ajn@apple.com>. Tested them on a iMac
+ mini, provided by Apple Inc.
+
+ Changed dummy declarations in library source files to
+ eliminate complaints about unused variables and empty
+ object files. This change may not work on dialects I
+ can no longer test; it has been tested on some versions
+ of AIX, Darwin, FreeBSD, Linux and Solaris.
+
+ At the request of Hal Brooks <hal@uga.edu> added support
+ for Linux /proc/net/packet files. Hal tested it.
+
+ Added socket file only performance enhancements to Linux
+ and PSTAT-based HPUX lsof.
+
+ Added htonl call around improper usage of INADDR_LOOPBACK;
+ report from an Apple engineer forwarded by Allan Nathanson
+ <ajn@apple.com>.
+
+ Adjusted for FreeBSD-8.0 change in device number handling.
+ The adjustment should work for FreeBSD 5 and above, should
+ the 8.0 change be propagated downward. The problem was
+ reported by Pav Lucistnik <pav@FreeBSD.org>. An updated
+ test system was provided by Erwin Lansing <erwin@FreeBSD.org>.
+
+ Reduced AIX support to version 5.3, since test systems with
+ older versions are no longer available to me.
+
+ At the request of Marjo F. Mercado <mmercado@xceedium.com>
+ and Phil Shin <pshin@xceedium.com> applied some speed
+ improvements to lsof, particularly when the files of
+ interest are /Internet files -- i.e., selected with lsof's
+ -i" option. Added a two new options to assist the
+ improvements: 1) "-c^<command>" to tell lsof to exclude the
+ named command(s); and 2) "-stcp|ud>:[^]state' to tell lsof
+ to include in its reporting or exclude ('^') from its
+ reporting Internet files in the named states (e.g., LISTEN,
+ ^CLOSE_WAIT, IDLE, etc.) For the most part these changes
+ apply only to AIX, Darwin, FreeBSD, PSTAT-based HP-UX, Linux
+ and Solaris, since those are the only places I could test
+ them. They are controlled by the HASTCPUDPSTATE definition
+ in each dialect's machine.h header file. Marjo and Phil
+ provided HP-UX 11.23 and 11.31 test systems.
+
+ Fixed a stat(2) problem on HP-UX 11.31 while testing the
+ speed improvements.
+
+ Adjusted for kernel header file changes in FreeBSD
+ 8.0-CURRENT. Larry Rosenman <ler@lerctr.org> provided
+ a test system.
+
+ Added a warning for Solaris systems where VxFS node info
+ can't be obtained from the VxFS utility library. The
+ warning was requested by Tom Matthews <Tom.MATTHEWS@rbs.com>.
+
+ Corrected mishandling of file system path name arguments
+ that have trailing slashes, except, of course, the root
+ file system, "/". Allan Nathanson <ajn@apple.com> reported
+ the bug.
+
+4.82 March 25, 2009
+ Corrected an over-zealous exclusion test that caused
+ lsof to report nothing when it was given no arguments
+ and built with HASSECURITY and HASNOSOCKSECURITY enabled.
+ Joshua Kinard <kumba@gentoo.org> reported the bug and
+ supplied information for reproducing it.
+
+ Based on a report from Dan Trinkle <trinkle@cs.purdue.edu>
+ corrected use of <sys/utsname.h> for 32 bit Solaris 10
+ and above compilations. Simultaneously eliminated a
+ casting complaint in arg.c and updated Configure to use
+ the appropriate 64 bit compilation option (-xarch=v9 or
+ -m64) with the Solaris Sun C compiler.
+
+ Updated for FreeBSD 7.1-PRERELEASE with information
+ supplied by Larry Rosenman <ler@lerctr.org>.
+
+ Updated the Darwin libproc sources with changes from
+ Allan Nathanson <ajn@apple.com>. Tested them on a iMac
+ mini, provided by Apple Inc. Allan also provided man
+ page corrections.
+
+ Updated the FreeBSD Makefile to use the ${MAKE} variable
+ for ZFS dnode2.c module compilation, based on a suggestion
+ from Alexis Ballier <aballier@gentoo.org>.
+
+ Improved the Solaris VxFS library location test, based on a
+ suggestion from Jason Fortezzo <fortezza@mechanicalism.net>.
+ Jason tested the change.
+
+ Updated Solaris 10 ZFS support for ZFS version 4 and ZFS
+ pool version 10, using a test system kindly provided by
+ Vladislav Nespor <vladislav.nespor@id.ethz.ch>. Renata
+ Maria Dart <renata@slac.stanford.edu> tested on ZFS
+ version 4, verifying that the update works there, too.
+ (ZFS pool version 10 is apparently the ZFS version shipped
+ with the 10/08 update to Solaris. The original ZFS
+ support targeted ZFS version 3.)
+
+ I still consider ZFS support in Solaris lsof a hack,
+ because it depends on a znode structure definition that
+ I developed using dbx. Sun is remiss in not distributing
+ the ZFS header files used to build the distributed kernel.
+
+ Because of the znode structure definition hack, I can't
+ guarantee that lsof ZFS support will work for any other
+ versions of ZFS.
+
+ Solaris 10: adjusted to a change in the way devices are
+ stored in the kernel; fixed a problem in zone handling;
+ and added rudimentary sharedfs support. Carson Gaspar
+ <carson@taltos.org> reported the device number problem,
+ provided a test system, and tested the changes. Peter
+ Vines <psv2b@eservices.virginia.edu> reported the zone
+ handling problem and tested the fix.
+
+ Adapted to FreeBSD 8.0-CURRENT changes in device number
+ computation. Problem was reported by Erwin Lansing
+ <erwin@FreeBSD.org>. Larry Rosenman <ler@lerctr.org>
+ provided a test system.
+
+ Corrected Solaris Configure test for appropriate VxFS
+ library when using gcc to compile lsof.
+
+ Updated for loss of KAME IPv6 FreeBSD accommodations.
+
+ Adapted to FreeBSD 7.2. Made Configure script recognized
+ FreeBSD 6.3.
+
+4.83 January 18, 2010
+ Converted Solaris 10 and above ZFS support to use the CTF
+ debugger library, libctf. Code was supplied by Robert
+ Byrnes <Robert.Byrnes@deshaw.com>.
+
+ Corrected a typo in the testing of the LINUX_HASSELINUX
+ environment variable in the Configure script. The error
+ was reported by Mike Frysinger <vapier@gentoo.org>.
+ At Mike's request made Configure script accept LSOF_RANLIB
+ (ranlib command), LSOF_CFGF (additional configuration flags)
+ and LSOF_CFGL (additional library specifications) from the
+ environment.
+
+ Enabled complilation of Solaris 10 lsof after a recent Sun
+ patch which changed the PC file system's structure. Peter
+ Vernam <pvernam@draper.com> reported the problem and helped
+ with the fix.
+
+ Made the sort of configuration CFLAGS in the CkTestDB
+ script impervious to locale settings.
+
+ Ported to Solaris 11, using a test system kindly provided
+ by David Day <dday76@gmail.com>.
+
+ Adjusted to the disappearance of <nfs/rpcv2.h> in FreeBSD
+ 8.0-BETA1.
+
+ Changed Solaris node type lookup to a hashed method and
+ added some ability for it to handle duplicate vnodeop names
+ in /dev/ksyms.
+
+ Updated for FreeBSD 9.0-CURRENT. Andrzej Tobola
+ <ato@iem.pw.edu.pl> provided a test system. Extends the
+ fix to FreeBSD 6.0 and above via a Configure test and a
+ compile-time definition. The need for the extension was
+ reported by Erik Trulsson <ertr1013@student.uu.se>>
+
+ Made corrections to FAQ typographical errors, suggested
+ by Josh Soref <timeless@gmail.com>.
+
+ Added __UCLIBC__ test to Linux dlsof.h so lsof would compile
+ on an Intel ARM XScale processor. The addition was provided
+ by Doug Kehn <rdkehn@yahoo.com>.
+
+ Added test for <utmpx.h> to FreeBSD configuration. Improved
+ its use in lsof.h. The changes were supplied by Martin Wilke
+ <miwi@FreeBSD.org>.
+
+4.84 July 29, 2010
+ Fixed a man page nroff command error with a correction
+ supplied by Josh Soref <timeless@gmail.com>.
+
+ Made Configure script recognize FreeBSD 7.3. Larry Rosenman
+ <ler@lerctr.org> provided a test system.
+
+ Improved task support, initially for Linux only, with help
+ provided by Jerome Marchand <jmarchan@redhat.com> and
+ Miklos Szeredi <mszeredi@suse.cz>. The support includes a
+ new compile-time definition, HASTASKS, and a new run time
+ option, "-K" to select task reporting.
+
+ While adding help output support for "-K", reorganized the
+ printing of help columns to make it much easier to add a new
+ option description.
+
+ Updated the Solaris PC file system structure patch in
+ revision 4.83 so it will compile with gcc.
+
+ Disabled the Solaris lgrp_root work-around in the Solaris
+ machine.h so it won't cause compilation problems on Solaris
+ 11. It no longer causes compilation problems on my Solaris
+ 9 and 10 test systems, but some older Solaris 9 and 10
+ versions may still need it, so the work-around was left in
+ the Sun machine.h and a FAQ entry was created about it.
+
+ Updated for Solaris 11 b134, using a test system kindly
+ provided by Carson Gaspar <carson@taltos.org>. Made
+ provisions for the next ZFS version. Added info about
+ the failure of the LTnlink test on ZFS file systems.
+
+ Corrected typo in Configure script, reported by Dmitry
+ Berezin <dmitryb@oit.rutgers.edu>.
+
+4.85 September 27, 2011
+ John Dzubera <Zube@CS.ColoState.EDU> kindly provided a patched
+ Solaris 9 test system with the lgrp_root conflict and I was
+ able to devise an automatic work-around for the conflict. The
+ special note in .../dialects/sun/machine.h was removed and
+ the 17.28.1 FAQ entry was modified to reflect the update.
+
+ Added a Solaris 11 work-around for a typedef problem with
+ <sys/mutex.h>. Carson Gaspar <carson@taltos.org> reported
+ the problem and supplied the work-around.
+
+ Added support for FreeBSD 7.4 and 8.2; tested on systems
+ provided by Larry Rosenman <ler@lerctr.org>.
+
+ Added support for 32 bit Solaris 11 lsof with mods supplied
+ by Jan Wortelboer <J.H.P.Wortelboer@uva.nl>.
+
+ Added Solaris 11 support for using an alternate genunix
+ location. Bill Goodridge <bill@its.brooklyn.cuny.edu>
+ reported the alternate location.
+
+ Added further Linux cross configuration support to lsof's
+ Configure script. The additional support was supplied by
+ Grant Erickson <erick205@umn.edu>. See the descriptions of
+ the LINUX_* environmen variables in 00XCONFIG for more
+ information. Tested lsof on Linux kernel 2.6.32 and picked
+ some lint that surfaced during the test.
+
+ Added fixes and changes for Apple Mac OS X 10.6, provided by
+ Allan Nathanson <ajn@apple.com>. Allan also provided a test
+ system.
+
+ Tested on FreeBSD 6.4 i386, using a test system provided by
+ Terry Kennedy <TERRY@tmk.com>. Updated for recent FreeBSD ZFS
+ changes on an 8.2 amd64 test system also provided by Terry.
+
+ Changed documentation to indicate FreeBSD 7.x is no longer
+ supported, since I no longer have a test system.
+
+ Made some changes to the lsof man page, suggested by Navid
+ <evi1m4chine@googlemail.com>.
+
+ Added compensation for Solaris 10 systems that have patch
+ 144488-10. The patch requires that the new header file
+ <sys/socket_proto.h> be included while _KERNEL is defined.
+ Brett Bartick <Brett.bartick@nomura.com> reported the problem
+ first, followed by Stuart Anderson <anderson@ligo.caltech.edu>.
+ Michael Hocke <michael.hocke@nyu.edu> suggested a work-around
+ which I refined to limit it to the specific Solaris 10 instance
+ and then tested on a system provided by Charles Stephens
+ <cfs@cowlabs.com>
+
+ Added the +|-e option for Linux. It exempts file systems
+ named by path from function calls that might block in the
+ kernel -- i.e., stat(2) and lstat(2), and when the +e form
+ is used, readlink (2). The new packager of lsof for the
+ Linux Fedora and RHEL distributions, Peter Schiffer
+ <pschiffe@redhat.com>, asked for the feature so it could
+ be used with Clearcase file systems, whose implementation
+ can block stat(2) calls. I consider this feature very risky
+ and easy to misuse -- e.g., specifying the file system as
+ '/' would exempt all file systems. I don't intend to
+ propagate this option to any other UNIX dialect that lsof
+ currently supports.
+
+ Made FreeBSD 9 adjustment.
+
+ Fixed a Linux bug that prevented the display of paths for
+ abstact UNIX sockets. Masatake Yamato <yamato@redhat.com>
+ reported the bug and supplied a patch.
+
+ Added compensation for the removal of RPC header files from
+ GlibC 2.14 for Linux. Marek Behun <kabel@blackhole.sk>
+ reported the problem and supplied a patch.
+
+ Added support for Linux Netlink protocol. Masatake Yamato
+ requested the support and supplied a patch. Peter Schiffer
+ <pschiffe@redhat.com> provided a test system.
+
+ Corrected Linux UDP6-lite path. The error was reported by
+ Masatake Yamato and he also supplied a patch.
+
+Vic Abell <abe@purdue.edu>
+September 27, 2011
diff --git a/lsof_4.85/lsof_4.85_src/00FAQ b/lsof_4.85/lsof_4.85_src/00FAQ
new file mode 100644
index 0000000..24a4e52
--- /dev/null
+++ b/lsof_4.85/lsof_4.85_src/00FAQ
@@ -0,0 +1,7987 @@
+
+ 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>
+September 27, 2011
+______________________________________________________________________
+
+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.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?
+
+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.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?
+
+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 ZFS probblems
+17.27.1 Why does Configure ask for the location of ZFS header files?
+17.27.2 Why do -h and -v output warn about possibly inaccurate ZFS
+ structure definitions?
+17.27.3 Why don't the Open Solaris ZFS header files provide correct
+ ZFS kernel structure definitions?
+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.[02] 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. 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.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 has been specified, or if the dialect doesn't support
+ the displaying of file offset (position).
+
+ 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.
+
+
+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.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.
+
+
+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/ipx (needs kernel patch)
+ /proc/net/raw
+ /proc/net/raw6
+ /proc/net/tcp
+ /proc/net/tcp6
+ /proc/net/udp
+ /proc/net/udp6
+ /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.
+
+ 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 ZFS probblems
+
+17.27.1 Why does Configure ask for the location of ZFS header files?
+
+ To provide ZFS support when lsof is compiled it needs to have
+ access to the definitions of ZFS structures used by the kernel.
+ Those definitions are contained in header files that Sun does
+ not distribute with Solaris 10.
+
+ When the Configure script detects the system might support ZFS
+ by finding the <sys/fs/zfs.h> header file, it checks for the
+ required ZFS kernel structure definition header files. When
+ they are not found, it asks if ZFS support should be included
+ and if so, with what definitions.
+
+ Two sources can be declared for definitions: 1) lsof's internal
+ ones; or 2) the necessary header files at some location other
+ than /usr/include/sys.
+
+ The necessary header files are:
+
+ dmu.h zfs_acl.h zfs_debug.h zfs_rlock.h zil.h
+ spa.h zfs_context.h zfs_dir.h zfs_vfsops.h zio.h
+ txg.h zfs_ctldir.h zfs_ioctl.h zfs_znode.h zio_impl.h
+
+ The necessary header files might have been obtained, for
+ example, from the http://src.opensolaris.org Open Solaris
+ source site. However, the Open Solaris header files might not
+ be adequate -- see the answer to the "Why don't the Open
+ Solaris ZFS header files provide correct ZFS kernel structure
+ definitions?' question for information on why the Open Solaris
+ ZFS header files might not provide correct ZFS kernel structure
+ definitions.
+
+ The supplied header file path must point to a directory that
+ contains a sys/ subdirectory where the matching header files
+ are located -- e.g., if the supplied path is /tmp/zfs, then
+ /tmp/zfs/sys must contain the necessary header files.
+
+ See the answer to the "Why do -h and -v output warn about
+ possibly inaccurate ZFS kernel structure definitions?" question
+ for information on the risks associated with using lsof's
+ internal definitions.
+
+17.27.2 Why do -h and -v output warn about possibly inaccurate ZFS
+ kernel structure definitions?
+
+ When lsof is configured to use its internal ZFS kernel
+ structure definitions, there is the chance that the definitions
+ may be out of date. Hence, an lsof built with them may report
+ incorrect device numbers, file sizes, node numbers and link
+ counts.
+
+ Please contact me via e-mail at <abe@purdue.edu> for work-around
+ suggestions. Make sure "lsof" appears in the "Subject:" line so
+ my e-mail filter won't classify your letter as Spam.
+
+17.27.3 Why don't the Open Solaris ZFS header files provide correct
+ ZFS kernel structure definitions?
+
+ The Open Solaris ZFS header files may not provide correct ZFS
+ kernel definitions. An lsof built with them may report
+ incorrect device numbers, file sizes, node numbers and link
+ counts.
+
+ The definitions may be incorrect because the Open Solaris
+ header files are not synchronized with any particular Solaris
+ 10 release. Consequently they might contain modifications to
+ the structures not in the structure definitions used to build
+ the running kernel. It may be that only Sun has header files
+ that match the kernel structures of the running Solaris 10
+ kernel.
+
+ Please contact me via e-mail at <abe@purdue.edu> for work-around
+ suggestions. Make sure "lsof" appears in the "Subject:" line so
+ my e-mail filter won't classify your letter as Spam.
+
+
+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 