From: Andres Salomon Date: Tue, 18 Feb 2025 05:45:12 +0000 (+0000) Subject: Import lsof_4.99.4+dfsg.orig.tar.xz X-Git-Tag: archive/raspbian/4.99.4+dfsg-2+rpi1^2~4 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=bdd49a817bd2b8c0323cf6e37787a3048c6f0e64;p=lsof.git Import lsof_4.99.4+dfsg.orig.tar.xz [dgit import orig lsof_4.99.4+dfsg.orig.tar.xz] --- bdd49a817bd2b8c0323cf6e37787a3048c6f0e64 diff --git a/.builds/netbsd.yml b/.builds/netbsd.yml new file mode 100644 index 0000000..f053658 --- /dev/null +++ b/.builds/netbsd.yml @@ -0,0 +1,25 @@ +image: netbsd/9.x +packages: + - autoconf + - automake + - pkg-config + - libtool + - groff +tasks: + - syssrc: | + curl https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/source/sets/syssrc.tgz -o syssrc.tgz + sudo mkdir -p /usr/src + cd / && sudo tar -zxf ~/syssrc.tgz + - setup: | + cd lsof + autoreconf -vif + ./configure + - build: | + cd lsof + export PATH=/usr/pkg/gnu/bin:$PATH + make + - test: | + cd lsof + export PATH=/usr/pkg/gnu/bin:$PATH + sudo make check + sudo make distcheck diff --git a/.builds/openbsd.yml b/.builds/openbsd.yml new file mode 100644 index 0000000..a74e21f --- /dev/null +++ b/.builds/openbsd.yml @@ -0,0 +1,29 @@ +image: openbsd/7.2 +packages: + - autoconf-2.71 + - automake-1.16.5 + - pkgconf + - libtool + - groff +tasks: + - legacy: | + cd lsof + ./Configure -n openbsd + make + bash ./check.bash openbsd + git clean -fdx . + - setup: | + cd lsof + export AUTOCONF_VERSION=2.71 + export AUTOMAKE_VERSION=1.16 + autoreconf -vif + ./configure + - build: | + cd lsof + make + - test: | + cd lsof + export AUTOCONF_VERSION=2.71 + export AUTOMAKE_VERSION=1.16 + make check + make distcheck diff --git a/.circleci/config.yml b/.circleci/config.yml new file mode 100644 index 0000000..b7f18d5 --- /dev/null +++ b/.circleci/config.yml @@ -0,0 +1,173 @@ +# Use the latest 2.1 version of CircleCI pipeline process engine. +# See: https://circleci.com/docs/2.0/configuration-reference +version: 2.1 + +executors: + ubuntu2204: + machine: + image: ubuntu-2204:2022.10.2 + alpine317: + docker: + - image: docker.io/alpine:3.17 + opensuse15: + docker: + - image: docker.io/opensuse/leap:15 + archlinux: + docker: + - image: docker.io/archlinux:latest + debian11: + docker: + - image: docker.io/debian:11 + debian12: + docker: + - image: docker.io/debian:12 + fedora37: + docker: + - image: docker.io/fedora:37 + fedora38: + docker: + - image: docker.io/fedora:38 + centos9: + docker: + - image: quay.io/centos/centos:stream9 + +# Define a job to be invoked later in a workflow. +# See: https://circleci.com/docs/2.0/configuration-reference/#jobs +jobs: + linux: + parameters: + distro: + type: executor + executor: << parameters.distro >> + steps: + - run: + name: Install build tools + command: | + dnf -y install autoconf automake gcc git iproute libtool make nmap-ncat pkg-config procps sudo || true + dnf -y install libtirpc-devel || true + dnf -y install make || true + apt update || true + apt install -y autoconf automake gcc git groff iproute2 libtirpc-dev libtool make ncat pkg-config procps sudo || true + pacman -Sy --noconfirm autoconf automake gcc git groff iproute2 libtool make pkg-config procps sudo || true + zypper install -y autoconf automake gcc git groff gzip iproute2 libtool make pkg-config procps sudo tar make || true + apk add sudo autoconf automake bash gcc git groff gzip iproute2 libtool linux-headers make musl-dev nmap-ncat pkgconf strace which || true + - when: + condition: + equal: [ fedora38, << parameters.distro >> ] + steps: + - run: + command: | + dnf -y install lcov gem procps python3-pip + pip3 install --user cpp-coveralls + - checkout + - run: + name: Configure + command: | + ./Configure -n linux + - when: + condition: + equal: [ fedora38, << parameters.distro >> ] + steps: + - run: + name: Build + command: | + CC="cc" + CC_EXTRA="--coverage" + make -j 2 CDEF="${CC_EXTRA}" CC="${CC} ${CC_EXTRA}" + - when: + condition: + not: + equal: [ fedora38, << parameters.distro >> ] + steps: + - run: + name: Build + command: | + make -j 2 + - run: + name: Test + command: | + bash ./check.bash linux + - when: + condition: + equal: [ fedora38, << parameters.distro >> ] + steps: + - run: + name: Report coverage + command: | + lcov -c -b . -d . -o coverage.info + /root/.local/bin/coveralls --root . + - run: + name: Build and test using autotools + command: | + git clean -fdx . + autoreconf -vif + ./configure + make + sudo make install + make check + cat test-suite.log + make distcheck + nixos: + docker: + - image: docker.io/nixos/nix:latest + steps: + - checkout + - run: + name: Build + command: | + nix-channel --update + nix-build + ventura: + macos: + xcode: 13.4.1 + steps: + - checkout + - run: + name: Install pkg-config + command: | + brew install pkg-config libtool autoconf automake + - run: + name: Configure + command: | + LSOF_INCLUDE=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include ./Configure -n darwin + - run: + name: Build + command: | + make -j 2 + - run: + name: Test + command: | + bash ./check.bash darwin + - run: + name: Build using autotools + command: | + git clean -fdx . + autoreconf -vif + ./configure + make + DESTDIR=$PWD/prefix make install + make check + - run: + name: Rebuild and test using distribution tarball + command: | + make dist + mkdir temp + cd temp + tar xvf ../lsof-*.tar.gz + cd lsof-* + ./configure + make + DESTDIR=$PWD/prefix make install + make check + +# Invoke jobs via workflows +# See: https://circleci.com/docs/2.0/configuration-reference/#workflows +workflows: + gnulinux-workflow: + jobs: + - linux: + matrix: + parameters: + distro: [fedora37, fedora38, centos9, debian11, debian12, ubuntu2204, archlinux, opensuse15, alpine317] + - nixos + - ventura diff --git a/.cirrus.yml b/.cirrus.yml new file mode 100644 index 0000000..41751e6 --- /dev/null +++ b/.cirrus.yml @@ -0,0 +1,23 @@ +task: + freebsd_instance: + cpu: 1 + matrix: + - image_family: freebsd-15-0-snap + - image_family: freebsd-14-0 + - image_family: freebsd-13-3 + install_script: pkg install -y bash git autoconf automake libtool groff pkgconf + build_script: + - ./Configure -n freebsd + - make + test_script: + - bash ./check.bash freebsd + autotools_build_script: + - git clean -fdx . + - autoreconf -vif + - ./configure + - make + - make install + autotools_test_script: + - make check + - cat test-suite.log + - make distcheck diff --git a/.ck00MAN b/.ck00MAN new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/.ck00MAN @@ -0,0 +1 @@ + diff --git a/.clang-format b/.clang-format new file mode 100644 index 0000000..4c5f9db --- /dev/null +++ b/.clang-format @@ -0,0 +1,4 @@ +BasedOnStyle: LLVM +IndentWidth: 4 +SortIncludes: Never +IndentPPDirectives: AfterHash \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..32c0248 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,32 @@ +--- +name: Bug report +about: Create a bug report to help us improve +title: "[BUG]" +labels: '' +assignees: '' + +--- + +**Describe the bug** +A clear and concise description of what the bug is. + +**To Reproduce** +Steps to reproduce the behavior: +1. Run '...' +2. See error + +**Expected behavior** +A clear and concise description of what you expected to happen. + +**Program output** +If applicable, paste program output text here to help explain your problem. + +**Environment (please complete the following information):** + + - Kernel: [e.g. Linux] + - OS: [e.g. Debian] + - lsof Version: [e.g. 4.xx.x] + - Origin: [e.g. installed by package manager, built from release tarball or git] + +**Additional context** +Add any other context about the problem here. diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..e0c0168 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,20 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: "[FEATURE]" +labels: '' +assignees: '' + +--- + +**Is your feature request related to a problem? Please describe.** +A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] + +**Describe the solution you'd like** +A clear and concise description of what you want to happen. + +**Describe alternatives you've considered** +A clear and concise description of any alternative solutions or features you've considered. + +**Additional context** +Add any other context or screenshots about the feature request here. diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 0000000..dddd2c2 --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,27 @@ +name: C/C++ CI + +on: + push: + pull_request: + branches: [ "master" ] + +jobs: + build: + strategy: + matrix: + os: [ubuntu-22.04, ubuntu-20.04] + runs-on: ${{ matrix.os }} + steps: + - uses: actions/checkout@v3 + - name: install dependencies + run: sudo apt install -y pkg-config + - name: autoconf + run: autoreconf -vif + - name: configure + run: ./configure + - name: make + run: make + - name: make check + run: make check + - name: make distcheck + run: make distcheck diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..372c43d --- /dev/null +++ b/.gitignore @@ -0,0 +1,169 @@ +# +# Glob patterns generated by GitHub +# +# Prerequisites +*.d + +# Object files +*.o +*.ko +*.obj +*.elf + +# Linker output +*.ilk +*.map +*.exp + +# Precompiled Headers +*.gch +*.pch + +# Libraries +*.lib +*.a +*.la +*.lo + +# Shared objects (inc. Windows DLLs) +*.dll +*.so +*.so.* +*.dylib + +# Executables +*.exe +*.out +*.app +*.i*86 +*.x86_64 +*.hex + +# Debug files +*.dSYM/ +*.su +*.idb +*.pdb + +# Kernel Module Compile Results +*.mod* +*.cmd +.tmp_versions/ +modules.order +Module.symvers +Mkfile.old +dkms.conf + +# +# Lsof specific patterns +# + +# Generated files +*.gcda +*.gcno +*~ +/Makefile +lib/Makefile +TAGS +lsof +lsof-netstat +tags +tests/config.* +version.h +autotools.h +lockf_owner.h +lockf.h +lsof.man +/site +lib/dialects/netbsd/include +/solaris11 + +# +# Symbolic links to lsof cli +# +/arg.c +/dprint.c +/main.c +/misc.c +/node.c +/print.c +/ptti.c +/store.c +/usage.c +/util.c + +# +# Symbolic links to a dialect implementation +# +/ddev.c +/dfile.c +/dlsof.h +/dmnt.c +/dnode.c +/dnode1.c +/dproc.c +/dproto.h +/dsock.c +/dstore.c +/machine.h + +# +# Traditional test related files +# +LTbasic +LTbasic2 +LTbigf +LTdnlc +LTlock +LTnfs +LTnlink +LTshm2 +LTsock +LTszoff +LTszoff2 +LTunix +LTunix2 + +# +# Dialect specific test related files +# +lib/dialects/linux/tests/epoll +lib/dialects/linux/tests/eventfd +lib/dialects/linux/tests/mq_fork +lib/dialects/linux/tests/mq_open +lib/dialects/linux/tests/open_with_flags +lib/dialects/linux/tests/pidfd +lib/dialects/linux/tests/pipe +lib/dialects/linux/tests/pty +lib/dialects/linux/tests/ux +lib/dialects/linux/tests/mmap + +# automake +Makefile.in +.libs/ +.deps/ +.dirstamp +*.log +*.trs + +# autoconf +autom4te.cache +/aclocal.m4 +/compile +/config.guess +/config.log +/config.status +/config.sub +/config.h +/config.h.in +/configure +/depcomp +/install-sh +/libtool +/ltmain.sh +/missing +/stamp-h1 +/test-driver + +# Doxygen +/output diff --git a/.readthedocs.yaml b/.readthedocs.yaml new file mode 100644 index 0000000..2f2f085 --- /dev/null +++ b/.readthedocs.yaml @@ -0,0 +1,21 @@ +# .readthedocs.yaml +# Read the Docs configuration file +# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details + +# Required +version: 2 + +# Set the version of Python and other tools you might need +build: + os: ubuntu-22.04 + tools: + python: "3.10" + +mkdocs: + configuration: mkdocs.yml + +# Optionally declare the Python requirements required to build your docs +python: + install: + - requirements: docs/requirements.txt + diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..e840122 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,73 @@ +# +# Derived from +# https://github.com/steveno/ctags/blob/master/.travis.yml +# + +dist: xenial + +language: c + +os: + - linux + - osx + +compiler: + - gcc + - clang + +sudo: true + +addons: + apt: + packages: + - lcov + - procps + - netcat +before_install: + - | + gem install lcoveralls + +script: + - | + case $TRAVIS_OS_NAME in + linux) dialect=linux;; + osx) dialect=darwin;; + esac + ./Configure -n $dialect + + - | + if [ $CC = 'gcc' ]; then + CC_EXTRA="--coverage" + fi + make CDEF="${CC_EXTRA}" CC="${CC} ${CC_EXTRA}" + + - | + case $TRAVIS_OS_NAME in + linux) dialect=linux;; + osx) dialect=darwin;; + esac + tdir=dialects/${dialect}/tests + if [ -f ${tdir}/Makefile ]; then + make -C "${tdir}" + fi + + - | + case $TRAVIS_OS_NAME in + linux) dialect=linux;; + osx) dialect=darwin;; + esac + sudo -E bash ./check.bash $dialect + +after_success: + - | + if [ $CC = 'gcc' ] && [ $TRAVIS_OS_NAME = 'linux' ]; then + ( + for f in /home/travis/.rvm/gems/ruby-2*/gems/lcoveralls-*/lib/lcoveralls/color_formatter.rb; do + sed -i -e 's/severity.capitalize!/severity = severity.capitalize/' $f + done + for f in /home/travis/.rvm/gems/ruby-2*/gems/lcoveralls-*/lib/lcoveralls/runner.rb; do + sed -i -e 's/\(.*format.*f\)\(%\)\('"'"'.*$\)/\1%%\3/' $f + done + ) || : + lcov -c -b . -d . -o coverage.info && lcoveralls --root . --retry-count 5 coverage.info + fi diff --git a/0..README.BEFORE.README.FIRST b/0..README.BEFORE.README.FIRST new file mode 120000 index 0000000..61cfe9a --- /dev/null +++ b/0..README.BEFORE.README.FIRST @@ -0,0 +1 @@ +./README.md \ No newline at end of file diff --git a/00.README.FIRST b/00.README.FIRST new file mode 100644 index 0000000..ea1355c --- /dev/null +++ b/00.README.FIRST @@ -0,0 +1,48 @@ +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 + (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. (The + ChangeLog file points to 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 +January 2, 2013 diff --git a/00CREDITS b/00CREDITS new file mode 100644 index 0000000..47fbb22 --- /dev/null +++ b/00CREDITS @@ -0,0 +1 @@ +This documentation has been replaced by docs/credits.md. Please refer to the new file or read it online. \ No newline at end of file diff --git a/00DCACHE b/00DCACHE new file mode 100644 index 0000000..21984f4 --- /dev/null +++ b/00DCACHE @@ -0,0 +1,742 @@ + + 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'' 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]'' 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 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]'' 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]'' 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]'' 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]'' 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]''. + +==================================================================== +* * +* 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]'' 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 ``#!''. + + 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.[567] + 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, [6789].x and 1[012].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 + OpenBSD 2.[89] and 3.[0-9] for x86-based systems + 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 + + +Vic Abell +February 14, 2018 diff --git a/00DIALECTS b/00DIALECTS new file mode 100644 index 0000000..831707d --- /dev/null +++ b/00DIALECTS @@ -0,0 +1,7 @@ + Apple Darwin 9, Mac OS X 10, macOS 11 and above + FreeBSD 8.2 and above + Linux 2.1.72 and above + NetBSD 1.2 and above + OpenBSD 7.2 and above + Solaris 9, 10 and 11 and above + OpenIndiana 5.11 and above diff --git a/00DIST b/00DIST new file mode 100644 index 0000000..353de42 --- /dev/null +++ b/00DIST @@ -0,0 +1,5624 @@ + Notes for the distribution of lsof version 4 + +******************************************************************** +| The latest release of lsof is always available from +| https://github.com/lsof-org/lsof/releases +| +| From 4.92.1, git is introduced to manage changes. +| You can consult the details of changes with git. +******************************************************************** + + 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 + 4.86, April 10, 2012 + 4.87, January 2, 2013 + 4.88, October 13, 2014 + 4.89, July 7, 2015 + 4.90, February 14, 2018 + 4.91, March 26, 2018 + 4.92, May 5, 2018 + 4.93.0 May 7, 2019 + 4.93.1 May 7, 2019 + 4.93.2 May 8, 2019 + 4.94.0 November 11, 2020 + 4.95.0 April 28, 2022 + 4.96.0 September 16, 2022 + 4.96.1 September 16, 2022 + 4.96.2 September 16, 2022 + 4.96.3 September 16, 2022 + 4.96.4 October 18, 2022 + 4.96.5 December 26, 2022 + 4.97.0 January 17, 2023 + 4.98.0 January 22, 2023 + 4.99.0 November 10, 2023 + + + +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: + + Apple Darwin 9 and Mac OS X 10.[567] + FreeBSD 10.3, 11.0, 12.0 and 13.0 for AMD64-based systems + Solaris 9 + +(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 file a new issue at +https://github.com/lsof-org/lsof. + +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 https://github.com/lsof-org/lsof. + + +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[_] + and 00RELEASE.SUMMARY_ -- 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 + 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 + on the 6.2 IMPACT distribution. + Heddy Boubaker + 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 + prompted this. + +4.02 March 21, 1997 + + Based on a report from Pasi Kaara , + 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 taught + HP-UX 10.x lsof to name file systems better by + using the virtual file system device number. Elias + Halldor Agustsson provided a test + system. + + Changed NEXTSTEP and UNIXWARE Makefiles to use + safer quoting when generating version.h. The change + was suggested by Bob Farmer . + + Added SHELL=/bin/sh string to all Makefiles. + + Added support for Linux 2.1.28 on a test system, + kindly provided by Jonathan Sergent . + 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 who helped test it. + Updated the old get_kernel_syms() code to recognize + and skip module name entries. + + Prompted by Marty Leisner , + 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 + 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 . Terry Kennedy + 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 , + 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 + 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 + 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 + helped develop and test the 5.3 definition. John + R. Vanderpool 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 + 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 + 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 + , 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 . + + 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 . (Configure's + -clean argument already did this.) + + Fixed an incorrect awk argument in the sunos*) + Configure stanza, reported by Alexandre Oliva + . + + Added CD9660 (aka ISO) file system support to + FreeBSD, NetBSD, and OpenBSD with mods and help + from Kenneth Stailey . + (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 + . Improved + the handling of IRIX 5.1 and greater FIFOs. + +4.07 May 12, 1997 + Based on AIX problem reports from David Capshaw + , 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 . + + 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 . + + 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 + and Jonathan Sergent + 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 + 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 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 + , 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 + 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 . 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 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 . 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 + + 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 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 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 , 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 . + +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 + . + + Cleaned up some typos and confusion in Configure's + help output, based on comments from Bela Lubkin + + + 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 + . + + Added socket state -- TCO or TPI -- for socket + files at the suggestion of Ian Fitchet + . + +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 . + + 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 + . 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 . + + 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 + 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 supplied the + changes. Kevin Smith 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 for + Solaris 2.x. W. Richard Stevens + 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 + 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 . + + 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 . 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 . + + 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 + 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 . + +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 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 . + +4.23 January 16, 1998 + Fixed conflict arising from the quondam replacement + of the Sun Solaris with a BIND/BSD version. + + With help from Jonathan Sergent + 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 . + + Added NFS node compensation for NetBSD 1.3. The + code and suggestion for it was supplied by Jean-Luc + Richier . + + 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 . + + 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 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 , enabling lsof to + compile for BSDI BSD/OS 2.0. + + Corrected a documentation error in 00DCACHE, pointed + out by Thomas Anders . 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 + 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 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 . + + 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 . + 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 + 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 + by IRIX 6.4 patch 2536. Added a + work-around for it to the lsof Configure script. + Igor Schein 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 , 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 , + , and .) + + 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 . The fix was + offered as a 4.28 patch. + + Adjusted for Digital UNIX 4.0D; the spec_node + structure is now defined in . Kris + Chandrasekhar + identified the need for the adjustment. + + Incorporated a bug fix from Brian McAllister + 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 reported the problem. + + Added a Solaris 2.6 work-around to keep the BIND + from colliding with the Solaris + . + + Strengthened the Configure test for /proc-based + Linux lsof, based on a report from Marty Leisner + . + + Tested on OpenBSD 2.3. + + Made AIX changes that allow use with 3.2.5. The + changes were suggested and tested by Brett Hogden + . + + 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 . He + supplied the correction. This was offered as a + patch to 4.29. + + Had a report from Igor Schein + 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 . 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 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 + 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 + provided a test system and Don + Draper 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 reported the + need for the update. Greg and Roger Klorese + provided technical information. + Scott McClung 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 . + This was offered as a patch to 4.30. + + Added support for Solaris 2.7 (first Beta release). + Mike Sullivan provided + technical advice and helped test. Charles Stephens + also helped test. + + Fixed bug in /proc-based Linux that caused it to + access /proc/mounts excessively. Marty Leisner + 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 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 + 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 . + 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 . + 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 + provided a test + system. Andrew Kephart + and Tom Weaver provided + technical assistance. Niklas Edmundsson + 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 + 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 supplied the + additions and helped with testing. Bill Pemberton + 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 supplied + technical details. + + Bracketed HP-UX 11 use of 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 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 . + Compensated for ncache element naming differences, + introduced at PTX 4.4.2; Kurtis D. Rader + 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 + 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 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 + requested this. + + Completed the HP-UX 11 port with support for its + optional 64 bit kernel. Rich Rauenzahn + 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 . + +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'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 . + This fix was offered as a patch to 4.35. + + Updated the Customize script to cause ENTER to use + all defaults. Amir J. Katz + suggested this and helped test the changes. + + Updated Solaris ICMP and IP stream handling, based + on a report from Igor Schein . + + Fixed a bug in the Digital UNIX mount table handling, + reported by Bob Ward . + 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 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 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 + 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 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 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 + . 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 + provided a test system. + + Added support for OpenBSD 2.4 with changes supplied + by Kenneth Stailey . + + 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 + and Carl Lindberg . + The combined dialect subdirectory is named n+os. + One of Carl's changes propagates RC_CFLAGS to the + library Makefile. Timothy J. Luoma + 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 . Lee + Penn 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 + . + + Acquired a new UnixWare 2.x test system, generously + provided by Computer Classroom, Inc. -- Matthew + Thurmaier , Ken Laing + , and Andrew Merril + . 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 . 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 + . + + For Bela Lubkin 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 and Maciej + Lesniewski . Jeff helped test + them on various Linux architectures. + + Tested on AIX 4.3.2; no changes were required. + Doug Crabill 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 . + + Based on a report from Michael Schmitz + 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 " and "+d " options for directory + searching. +D searches the entire tree, starting + at , including , its contents, and its + subdirectory branches; +d searches only 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 + 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 + . + + Fixed an AIX 4.3+ bug in procinfo struct space + allocation, reported by Jeff Stewart . + 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 + 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 4.0 support with help + from Sheldon Hearn , David O'Brien + , and John Polstra . + + 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 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 + . This was offered as a + patch to 4.40. + + Installed an HP-UX 11 patch, suggested by Kevin + Vajk , 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 + + 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 + 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 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 + 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 + 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 + . + + 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 , 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 . + + Corrected HP-UX error message about HP-UX 11 q4 usage. + Amir Katz reported the correction. + + Fixed a GlibC 2.1 conflict in /proc-based Linux lsof. + + Fixed a man page typo reported by Vlad Harchev + . + + 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 + . + + Fixed a PTX real vnode to real inode interpretation + bug. + + Added link count to lsof output. Eric Dumazet + 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 + 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 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 + 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 + 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 + and Don Draper . + + 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 . + 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 . 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 . 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 . + 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 , who + provided information and did testing. + + Enabled IPv6 support code for NetBSD and OpenBSD, + conditional on Configure script tests. Wolfgang + Rupprecht 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 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 and Andrew + Thomas Sydelko 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 + . + + Sylvain Robitaille 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 + , who also tested the fix. + + Added a libc5 library /dev/kmem-based Linux lsof + circumvention, supplied by Jason Lingohr + . + + Corrected a bug in -t (terse) AIX output, reported + by Wendy Lin . 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 header file. Volker Borchert + 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 + . + + Fixed a gawk POSIX-mode pattern error in the Linux + /dev/kmem-based Mksrc script, based on a tip from + Ambrose C. Li . + + Fixed a bug in the Tru64 UNIX IPv6 handling, courtesy + of a report from Casper Dik . + + Enabled support for OpenBSD 2.6. + + Enabled support for BSDI BSD/OS 4.1, based on a + report from Jeffrey C Honig 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 + helped test. + + Fixed a DEC OSF/1, Digital UNIX, Tru64 UNIX repeat + mode bug, reported by Mayer Ilovitz . + 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 . + The fix was offered as a patch to 4.45. + + Added support for INRIA IPv6 to NetBSD. Jean-Luc + Richier provided patches + and a test system on which to verify them. + + Added support for AIX 4.3.3. Jeff W. Stewart + 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 , + 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 , + 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 with the + patches. The problem was reported by Will Partain + . Elias Halldor Agustsson + 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 . + + 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 . 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 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 + improved AFS configuration + for AIX and Solaris, and updated AIX AFS 3.5 support. + Johannes Tax , Hung T. + Pham , and Curt Freeland + provided test systems. + + Updated lsof's private rnode definition for AIX + 4.3.3, since IBM still doesn't ship the + header file and the rnode + structure definition in 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 . + + Adjusted for a FreeBSD 4.0 change in the definition + of [_]KERNEL. David O'Brien 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 . + +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 + 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 + 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 + 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 + . 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 + . + + 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 , 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 . + +4.50 June 29, 2000 + Added a NetBSD alpha test host, courtesy of Ray + Phillips . 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 + and Jim Mintha . + + Forced AIX to use the large-file-enabled versions + of lstat (lstat64) and stat (stat64) if + 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 and + puts -DHASSTAT64 in the Makefile's CFLAGS to make + this happen. Fernando A.B. Whitaker + reported the problem. + This was offered as a patch to 4.48. + + Enabled Configure script to handle OpenBSD 2.7. + Angelos D. Keromytis + 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 supplied + patches and did testing. David O'Brien + 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 for + a FreeBSD 3.4 test system. + + In response to an lsof 3.72 bug report from Jim Mewes + , added more kernel address + filtering to the lsof function, kread(), that reads + Solaris kernel data. + + In response to a report from Marc Duponcheel + , 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 , 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 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 . + Dan supplied a patch and did FreeBSD testing. + + Added Configure script recognition of NetBSD 1.5, + based on a report from Andrew Brown . + Thomas Klausner 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 . + + 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 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 + and Klaus Saggerer USG + [saggerer@zk3.dec.com> helped put me in contact + with Chang Song , 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 , Thomas Klausner + , and Wolfgang + Rupprecht 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 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 provided a test system. + + Based on a report from Marc Christensen + 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 + 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 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 , + Diane Lebel , and John Speno. + The support only provides information about cached + file attributes. + + Installed a Configure patch for HP-UX 11 supplied by + Kenneth Stailey that adds + another command to q4 input. + + Tested on FreeBSD 4.2. + + Will Day and Frank + Winkler graciously + supplied Solaris 8 binaries. + + Added Solaris 9 text file support, supplied by + Casper Dik . + +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 . 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 + . + + 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 + provided the necessary clue. + + Based on a report from Valdis Kletnieks + , 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 + , 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 . + + 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 . + + 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 requested and helped + test it. + +4.55 February 15, 2001 + Based on a report from Bernd Eckenfels + added support in lsof for files in /proc//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 + 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 + 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. helped test. + + Added support for UnixWare 7.1.1 and above in-kernel + UNIX sockets. John Hughes 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 . + + Archived a set of compilation hints (patches) from + Bill Melvin 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 + 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 conditional + on the Solaris version. (It's apparently not needed + at 2.6 and above.) Bill Watson + brought this to my attention. + + Added alternate Linux 2.4.x lock extent test, supplied + by Jim Mintha . + + 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 , + Gary Millen , Rainer Orth + , Peter C. Vernam + , and Donna Yobs + + + 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 + , 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 + 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 . Troyan Krastev + brought the bug to + my attention and Michael Bracewell + 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 . + Lsof will use setlocale(), when that function and + its supporting header file are available. + + Added OpenBSD 2.9 support. + + Based on a report from Aaron Rhodes + 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 + help test. The lsof + FreeBSD ports packager, David O'Brien , + 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 . + + 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 + . + + 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 . 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 . + + Made available for re-distribution a user-contributed + port of lsof 4.51 to Reliant UNIX 5.45. Thomas + Mauterer 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 + . + + Corrected a bug in the way Linux lsof identifies + the owner of a process. Lionel Cons + 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 . + Matthew Thurmaier and many + people from Caldera provided technical assistance. + + Added an additional UVM test to the NetBSD Configure + stanza. Andrew Brown 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 + for Darwin 1.4. + + Added for Bela Lubkin + 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 . + + 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 + helped test. + + Made lsof's method of killing its child process + more robust, based on a suggestion from Bela Lubkin + . + + 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 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 . + + In response to a report from Joshua Wright + 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 + 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 + + Based on a report from Mark W. Eichin + 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 and Marc + Stephenson , and on a test + system provided by Loc Le . + +4.62 March 7, 2002 + Updated 00README to reflect the usefulness of gcc + for building AIX lsof. Documented a report from + Brian L. Gentry 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 . + 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 . + + 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 + 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 . + 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 , + based on a report from Larry Rosenman + 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 . + + 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 . + 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 + . 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 + . + + Added defense against the standard I/O descriptor + attack. + +4.64 June 26, 2002 + Corrected some FreeBSD pre-processor directives. + David O'Brien 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 . + 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 + 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 + 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 , + and new a bug in the fix, reported by Eric Cronin + + + Added nullfs support for FreeBSD, NetBSD, and OpenBSD + at the request of Andrew Brown . + + 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 sent me the + dnode.c change and Casper Dik + 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 . + Larry Rosenman 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 . + Adjusted for changes in FreeBSD 5.0-CURRENT . + One change was reported by Anders Nordby + . 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 . + + Enabled compiling of lsof for NetBSD 1.5 with the + NULL file system, using a patch from Andrew Brown + . + + 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 + brought the need for this change to my attention. + + Applied a patch, supplied by Andrew Brown + , 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 . + + Updated to FreeBSD 4.7. + + Updated to Apple Darwin 1.5, 5.x and 6.x with + patches supplied by Allan Nathanson . + 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 + 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 . 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 + , 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 . Updated + 00TEST and tests/TestDB accordingly. + + Clarified FreeBSD 5.0 architecture claims at the + suggestion of David O'Brien . + 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 + . + + Upgraded True 64 UNIX support to the 5.1B release + on a test system provided by Berkley Shands + 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 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 + + +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 + added the "+c " option to enable optional + changing of the COMMAND column output maximum width + from the default to . 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 , who tested the fixes. + + Added kernel event queue file support for FreeBSD, + NetBSD and OpenBSD. Andrew Brown + supplied the code. + + Updated to AIX 5.2 on a test system provided by + Dale Talcott . Had to build + work-arounds for two missing AIX 5.2 header files, + and . 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 + Toshiya Nakamura 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 . + + 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 . + + Improved the description of the detached PGP + signature certificate file in the main lsof README + file, based on a suggestion from Diana Stockdale + . + + 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 + 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 + determined the NetBSD snapshot (1.6F) at which + 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 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_ file of the + distribution archive. John Jackson + and Ray Phillips + 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 + 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 , 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 + . 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 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 . + 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 + 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 + to handle NetBSD enum conflicts and changes in the + and + header files. + + Added a "#define _KERNEL" to the AIX dnode2.c source + file for compatibility with a new + AIX 5.2 header file version. The addition was + supplied by Dick Dunbar + and was offered as a patch to lsof 4.68/ + + Added support for a second type of Solaris SAMFS. + Stuart Anderson 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 . Casper Dik + 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 . + 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 . + + Validated lsof on FreeBSD 5.1-CURRENT for Amd64. + David O'Brien 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 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 + . + + 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 . 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 . + + 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 . + + Based on a report from John Jackson , + enabled a Solaris 10 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 and + John Heasley 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 + . + + 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 + and Eric Williams (aka The Ghost + In The Machine) 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 + and Tristan Nefzger 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 + 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's + fix was offered as a patch to 4.71. + + Based on a report from Jean-Pierre Radley + 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 . 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 . + + Added support for FreeBSD 4.10. Larry Rosenman + kindly provided a test system. + + Added support for NetBSD 2.0 with patches supplied by + Andrew Brown . Andrew also + provided two test systems. + + Made handling of Linux maps file more robust, based on + a report from Jan Blunck . As + a side benefit, made handling of generated stat(2) + information more flexible. + + As a result of a discussion with Jason Fortezzo + , adjusted lsof for Solaris + to obtain the maximum user name length from ut_name of + the utmpx structure, if exists. + + Tested under OpenBSD 3.5. + + Updated 00README information about using gcc (via the + Configure aixgcc abbrevisiation) to compile lsof on + AIX. Ann Janssen 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 + about lsof memory usage. + + Added scripts/sort_res.perl5, contributed by Fabian + Frederick . 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 . + + Updated FreeBSD 5.2-CURRENT support, based on a problem + report from Filippo Natali . + + Corrected improper FreeeBSD 5.x-CURRENT #if condition, + reported by Kim Culhan . + + 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 . + +4.73 October 21, 2004 + Added an __XPG4_CHAR_CLASS__ #define before + #include'ing 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 + . 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 , + supplied by Sergey A. Osokin . + + Implemented a Linux feature request made by Jakub + Jelinek 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 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 . (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 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 + . + + Updated lsof for FreeBSD 6.0 and higher for a change in + , based on a report from Sergey A. Osokin + . 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 . + 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 helped + test. + + Updated for Solaris 10, build s10_69, with a patch + supplied by Mike Miscevic . + + 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 . + + Updated lsof for NetBSD 2.99.10 and tested it on a + system provided by Andrew Brown . + + 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 . + + Added abbreviations for AXI FCIO and FSNAPSHOT file + flags. Holger VanKoll + 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 for it.) + + Corrected a Linux socket inode printing bug reported by + Igor Schein . + + 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 . + +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 + 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 + changed DEC OSF/1 process table + allocation to request memory in smaller increments. + + Based on a report from jayjwa + 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 . 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 . + + 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 + . 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 + . 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 . Marc provided + a test system. + + Supplied a missing quote in the FreeBSD Configure + stanza. Carl Cook 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 . Allan also provided a + test system. + + Completed documentation of CLRLFILEADD in all machine.h + files. + + At the request of Chris Markle + 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 . + + Updated Solaris VxFS support for VxFS versions 4 and + above with technical advice from Craig Harmer + , Gary Millen + and Chuck Silvers + . Testing help was + provided by Michael Antlitz , + Steve Ginsberg and Kenneth + Stailey . + + Fixed a Solaris address space map processing bug. + Janardhan Molumuri 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 incomplete, 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 + 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 . 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 + reported those needs. + + Fixed an HP-UX 11 file descriptor "chunk" size problem, + reported by Per Allansson . 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 , the + author of the script. + + Corrected +|-M man page documentation error, reported + by Roger Cornelius . + + Improved FreeBSD user device random seed generation in + response to a problem report from Danny Braniss + . + + Eliminated three syntax error bugs and other compiler + complaints from the PSTAT-based lsof. H. Merijn Brand + 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 . Found that + neither the HP bundled C compiler nor gcc would build + lsof, but the HP unbundled ANSI C compiler would. + Concluded that HP bundled C compiler can't handle + . Devised a work-around to gcc's + omission of the rpcent structure definition of + 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 . + + 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 , + 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 . 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 . + + Based on a bug report from Karel Zak + 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 + reported the problem. + + Added code to avoid processing Linux /proc//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 reported + lsof's mishandling of such entries. + + Added SELinux security context support, provided by + James Antill . I have not + tested this, but James and Karel Zak + have. + + Added the #include of 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 + and Tom Whitty . + + 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 . + + 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 + provided a development + system and helped test the support. + + Corrected a typo in the man page, reported by Eric S. + Raymond . + + Changed the spelling of macroes to macros in lsof + source and documentations files, based on a suggestion + from Josh Soref 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 . Gregory tested the + fix. + + Moved an #include later in FreeBSD dlsof.h + to enable compilation on recent FreeBSD releases. The + change was supplied by Roy Marples . + + Improved Linux /proc file stream reading speed by applying + an expanded version of a patch from Eric Dumazet + 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 + . + + Fixed a Linux maps file processing bug that prevented path + names from having an embedded colon. James Lingard + reported the bug and helped with its + fix. + + Based on reports from Eric Dumazet and Samuel Thibault + added support for the + Linux 2.6.22 kernel's /proc//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 . 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 + . Pekka tested the fix. + + Based on a report and using suggested fixes from Karel Zak + , 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 + 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 + 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 . + + Updated FreeBSD lsof with ZFS support. Larry Rosenman + , Erwin Lansing , Wesley + Shields and Dmitry Morozovsky + provided test systems. + + Fixed a socket file identification problem reported by + Pavol Rusnak . 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 , + 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 + and Pav Lucistnik + 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 + , who helped test the update. Wesley + Shields 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 + . + + Added warnings for unsupported dialects or versions. + + Added Linux support for the UDPLITE protocol. Eric + Dumazet 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 + who tested the corrected + Makefile. + +4.81 October 21, 2008 + Updated the Darwin libproc sources with changes from + Allan Nathanson . 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 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 + . + + 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 . An updated + test system was provided by Erwin Lansing . + + 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 + and Phil Shin 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^" 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 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 . + + Corrected mishandling of file system path name arguments + that have trailing slashes, except, of course, the root + file system, "/". Allan Nathanson 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 reported the bug and + supplied information for reproducing it. + + Based on a report from Dan Trinkle + corrected use of 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 . + + Updated the Darwin libproc sources with changes from + Allan Nathanson . 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 . + + Improved the Solaris VxFS library location test, based on a + suggestion from Jason Fortezzo . + 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 . Renata + Maria Dart 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 + reported the device number problem, + provided a test system, and tested the changes. Peter + Vines 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 + . Larry Rosenman + 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 . + + Corrected a typo in the testing of the LINUX_HASSELINUX + environment variable in the Configure script. The error + was reported by Mike Frysinger . + 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 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 . + + Adjusted to the disappearance of 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 + 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 > + + Made corrections to FAQ typographical errors, suggested + by Josh Soref . + + Added __UCLIBC__ test to Linux dlsof.h so lsof would compile + on an Intel ARM XScale processor. The addition was provided + by Doug Kehn . + + Added test for to FreeBSD configuration. Improved + its use in lsof.h. The changes were supplied by Martin Wilke + . + +4.84 July 29, 2010 + Fixed a man page nroff command error with a correction + supplied by Josh Soref . + + Made Configure script recognize FreeBSD 7.3. Larry Rosenman + provided a test system. + + Improved task support, initially for Linux only, with help + provided by Jerome Marchand and + Miklos Szeredi . 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 . 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 . + +4.85 September 27, 2011 + John Dzubera 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 + . Carson Gaspar reported + the problem and supplied the work-around. + + Added support for FreeBSD 7.4 and 8.2; tested on systems + provided by Larry Rosenman . + + Added support for 32 bit Solaris 11 lsof with mods supplied + by Jan Wortelboer . + + Added Solaris 11 support for using an alternate genunix + location. Bill Goodridge + reported the alternate location. + + Added further Linux cross configuration support to lsof's + Configure script. The additional support was supplied by + Grant Erickson . 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 . Allan also provided a test + system. + + Tested on FreeBSD 6.4 i386, using a test system provided by + Terry Kennedy . 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 + . + + Added compensation for Solaris 10 systems that have patch + 144488-10. The patch requires that the new header file + be included while _KERNEL is defined. + Brett Bartick reported the problem + first, followed by Stuart Anderson . + Michael Hocke 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 + + + 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 + , 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 + abstract UNIX sockets. Masatake Yamato + reported the bug and supplied a patch. + + Added compensation for the removal of RPC header files from + GlibC 2.14 for Linux. Marek Behun + reported the problem and supplied a patch. + + Added support for Linux Netlink protocol. Masatake Yamato + requested the support and supplied a patch. Peter Schiffer + provided a test system. + + Corrected Linux UDP6-lite path. The error was reported by + Masatake Yamato and he also supplied a patch. + +4.86 April 10, 2012 + Lsof for AIX is no longer supported on any versions of that + operating system. + + Added information about the clang compiler for FreeBSD to the + FAQ. + + Corrected an arg.c bug in the accumulation of +|-e option + values, reported by Peter Schiffer . + This correction was supplied as a patch to revision 4.85. + + Enabled FreeBSD 10 support and tested it there on a system + provided by Larry Rosenman . + + Updated for latest Solaris 11 with patches supplied by + Carson Gaspar . Carson supplied a test + system. + + Adjusted Linux file system search method to compensate for + NFS mounts that have duplicate device numbers. The problem + was reported by Peter Schiffer , who + provided a test system. + + At the request of Peter Schiffer , added + support for Linux SCTP socket files. Peter provided a test + system. Applied a warning patch supplied by Peter. + + Added support for Mac OS X 10.7 (Lion), provided by Allan + Nathanson . Allan also supplied a test + system. + + Enabled FreeBSD 8.3 support and tested it there on a system + provided by Larry Rosenman . + + Corrected the FAQ information on ZFS with Solaris 10 after + Steven Blackmon and Prasad Jampala + pointed out that it was incorrect -- + i.e., outdated by the libctf changes at revision 4.83. + + Added code to handle a Linux NFS-mounted root. Jia He + reported the need for this. + +4.87 January 2, 2013 + Added an entry to 00FAQ about lsof behavior when the + HASSECURITY and HASNOSOCKSECURITY options are defined. + Carson Gaspar pointed out the need + for this clarification. + + Added a work-around for a missing definition of mach_port_t + in Darwin 9 (Mac OS/X 10.5.8). The work-around was supplied + by Jim Reid . + + Added support for Linux anon_inodefs, provided by Masatake + YAMATO . + + Documented a Solaris 9 and 10 portmap reporting problem + (+M) in 00FAQ. The problem was reported by Clint + Roberts . I have no solution + to the problem, but discuss a possible work-around in + the answer to this 00FAQ question: "Why doesn't lsof + report portmap registrations for some Solaris versions?" + + Added FreeBSD support for the oldnfs and newnfs file system + types. Daniel Braniss reported the + need for the addition. + + Added ICMP socket support for Linux with code provided by + Masatake YAMATO . + + Corrected the reporting of process group ID for libproc + versions of Mac OS X with a patch from Jeff Trawick + . The patch has not been applied to + Darwin kmem versions, because of little call for them + and inadequate test system access. The patch has been + tested on Mac OS X 10.8 (Mountain Lion), courtesy of a + test system provided by Allan Nathanson . + + Added thread support to those FreeBSD versions that have + ki_numthreads in their kinfo_proc structure. This also + activates the -K option for those FreeBSD versions. Jeff + Trawick reported problems with FreeBSD lsof when threads + are present and this addition solves those problems. + + Made changes to 00FAQ and the distribution, suggested by + Warren Young . The 00FAQ changes + center on sections that discuss the -s option. The changes + to the distribution include a ChangeLog file that is either + a pointer to or a copy of 00DIST, the distribution notes. + + Added support to FreeBSD for using the clang compiler. + + Added Linux support for using the getxattr() call to obtain + socket protocol identification when it is can't be obtained + from the /proc/net files that lsof examines. Masatake YAMATO + developed the kernel patch to getxattr() + and supplied the lsof patch. + +4.88 October 13, 2014 + Reduced to 50 the number of open file descriptors lsof + attempts to close while trying to protect itself from a + file descriptor exec() attack. This limits the overhead + lsof incurs on systems that have large file descriptor + limits, yet provides sufficient open descriptors for the + library functions lsof calls. + + Updated for changes in FreeBSD 10 with advice from Eygene + Ryabinkin . Taught Configure to recognize + FreeBSD 8.4. + + Herein am noting that lsof for Solaris 10 or 11 is no longer + supported. I no longer have test systems. Some support is + still available from Casper Dik and a + Solaris 11 patch he provided is included in this revision. + + Initialized local variables in the Linux process_id() function. + Jia He reported the problem. + + Added support for FreeBSD 11. + + Updated FreeBSD ZFS Configure stanza to supply a dummy + opt_kdtrace.h when needed. + + Added tmpfs file system support for FreeBSD. + + Since a test system is no longer available, dropped the + claim of FreeBSD 4.9 support. + + Added the +|-E options for Linux. -E displays endpoint info; + +E displays endpoint info and endpopint files. Masatake YAMATO + requested this support and suggested code + to implement it. + + Fixed a Linux bug handling processes whose command includes a + non-printing character, particularly a NEWLINE character, and + clarified printing of single '\\' characters in command and + file names. Stephane Chazelas + reported the problem. + + Added support for Linux RDMA and CRYPTO protocol names and UNIX + socket type with code from Masatake YAMATO . + + Fixed field output to insure that the field descriptor field is + always selected, since it identifies the file set. The bug was + reported by Gary Plewa . + +4.89 July 7, 2015 + Applied correction from Casper Dik to + his patch for Solaris 11 that I applied incorrectly in revision + 4.88. + + Updated for latest version of FreeBSD 11.0-CURRENT. + + Compensated for a missing FreeBSD 10.0 typedef of bool on the + i386 architecture. Allen Hewes provided + a test system. Andrey Chernov provided + useful advice. + + Improved tests/Add2TestDB script with a patch from Peter + Schiffer . Added patches from Peter to + eliminate Linux gcc warnings. Updated Lsof.8 with improvements + supplied by Bjarni Ingi Gislason . + + Changed FreeBSD global CFLAGS extraction per Terry Kennedy + . Also made sure -DNEEDS_BOOL_TYPEDEF is + #define'd when the resulting CFLAGS doesn't contain it. Terry + reported that need. + + Improved Linux test for tcp.h in response to a report from + Cato Auestad . Cato did the testing. + + Fixed Linux UNIX socket search by name bug reported by + Stephane Chazelas . + + Added Linux display of UNIX socket endpoint information with + code provided by Masatake YAMATO . Peter + Schiffer provided a test system. + + Insured that type definitions from were again made + visible to lsof on FreeBSD 11 after a system header file change + hid them. + +4.90 February 14, 2018 + + !!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! + ! ! + ! It is likely that this is the last lsof revision I ! + ! will issue, unless serious bugs are detected, Stay ! + ! tuned to lsof-l for information about future support ! + ! of lsof. ! + ! ! + ! I thank all the many contributors to lsof over the ! + ! many years (20+?) I have been distributing lsof ! + ! versions 1, 2, 3 and 4. ! + ! ! + ! Vic Abell ! + ! ! + !!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! + + Taught the Configure script to create a dummy opt_random.h + for FreeBSD systems whose includes it. + + Added support for the FreeBSD ZFUSE file system. + + Corrected the quoting in a Darwin putchar() statement in the + dfile.c source file. Andrew Janke reported + my error. + + Added support for the FreeBSD DTYPE_PTS file descriptor and + for unknown descriptors that reference the kernel's badfileops + operation switch. Enabled FreeBSD 12.0 support. Tested the + changes on systems provided by Larry Rosenman . + + Enhanced -K option with the form "-K i" to direct lsof to + (i)gnore tasks. A query from Rachel Kroll + suggested this option. Linux task reports now include both + process and task command names, making lsof's "-c " + option work correctly. + + Added a patch to prevent NFS blocking in Linux supplied by + Kristyna Streitova . + + Installed a FreeBSD patch that prevents examining a TCP state + structure during a race condition. The patch was supplied by + Bryan Drewery . + + Updated FreeBSD for new UFS inode structure that lacks an i_dev + member in the most recent 12.0-CURRENT. Larry Rosenman + reported the problem and provided a test + system. + + Added "#define KLD_MODULE" to dlsof.h and dnode2.c to prevent + from generating an "ARM_NARCH is 0" error. + This is needed so lsof can access kernel structures. Larry + Rosenman supplied the addition. + + Added recognition of the FreeBSD 11 file system name "nullfs". + Jamie Landeg-Jones supplied the fix. + + Added a patch from Larry Rosenman that is + needed on FreeBSD 12 so the lsof compilation can obtain the + inpcb and tcpcb structures from their respective header files. + + Updated FreeBSD dmnt.c for the ino64 changes. + + Inserted a patch for Solaris 12.x to avoid compilation errors + from , based on information provided by Jorn + Clausen . Jorn tested the + patch. + + Added performance enhancement that uses the FreeBSD closefrom() + and dup2() C library functions when available. The enhancement + was supplied by Conrad Meyer . + + Corrected FreeBSD lsof's gathering of ZFS file device numbers. + + Updated lsof test library for FreeBSD. + + Updated socket optons information collection from the socket + structure per changes supplied by Gleb Smirnoff + . + + Added patch to dlsof.h that avoids a _KERNEL conflict with + bzero. Mateusz Guzik supplied the patch. + + Corrected test library to handle 64 bit FreeBSD device numbers. + + Added #defines for FreeBSD 12, src r324225, from Gleb Smirnoff + . + + Incorporated Linux pseudoterminal endpoint processing (+|-E) + provided by Masatake YAMATO with access to + test systems provided by Peter Schiffer . + + Corrected Linux command extraction for commands that include + parentheses -- e.g., "(sd-pam)". + +4.91 March 26, 2018 + + A bug has been reported in the PTY endpoint processing of + Linux lsof 4.90 by Peter Wu , making it + necessary for me to release another revision of lsof. + + This revision applies two fixes that correct the Linux PTY + endpoint processing bug. Masatake YAMATO + supplied the fixes. + +4.92 July 14, 2018 + THIS IS A FREEBSD-ONLY DISTRIBUTION! + + Fixes Configure script section that creates the FreeBSD + lockf_owner.h header file; fixes conflicts with + FreeBSD kernel header files. Mateusz Gusik supplied part of + the fix. + + Released lsof to GitHub with Purdue releases documented in + support/GitHub-release. + + +4.92.1 May 6, 2019 + + !!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! + ! ! + ! The maintainership is switched from Vic to lsof-org ! + ! at GitHub team officially. ! + ! We thank Vic for working on lsof over the years. ! + ! ! + ! lsof-org at GitHub team (https://github.com/lsof-org) ! + !!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! + + This is just for testing "Release" feature of GitHub. + Many documentations are not updated yet. + URLs in -v output and -h output are updated. + +4.93.0 May 7, 2019 + + [freebsd] Made FreeBSD 13 adjustment. + [darwin] Fix a typo causing a build error. + Fix a potential memory leak. + [linux] use tirpc for rpc if libc doesn't provide rpc.h. + Fix a typo in man page. + [linux] fix memory leaks detected by valgrind about unix + endpoint information. + Update the description about -fg and -fG options on linux. + +4.93.1 May 7, 2019 + + Fix a broken symbolic link. + +4.93.2 May 8, 2019 + + Update the version number embedded in lsof executable. + +4.94.0 November 11, 2020 + + (All changes in this version are ported from + lsof-org/lsof-linux repository at GitHub). + + Introduced a new test harness. The harness can run + test cases specific to a dialect. It is designed for + running test cases on CI environment like Travis-CI. + However, it is runnable locally with following command + line: + $ ./check.sh DIALECT + after making lsof executable. + + + [linux] Fixed a bug +|-E options output for pipe. + If two processes use the same fd number for a pipe + connecting them, the option didn't print the + information about it. + + + [linux] Fixed a bug +|-E options output for PTY. + If two processes use the same fd number for a PTY + connecting them, the option didn't print the + information about it. + + + [linux] Fixed a bug +|-E options output for PTY. + The code for detecting a slave device was incorrect. + + + [linux] Fixed a potential bug +|-E options output for + PTY. A structure field for the feature was not + initialized. + + + [linux] Added a code for decoding O_PATH flag in +fg + option. + + + [linux] Added a code for decoding O_CLOEXEC flag as CX + in +fg option. + + + [linux] Added a code for decoding O_TMPFILE flag as + TMPF in +fg option. + + + [linux] Added Linux display of INET socket endpoint + information with +|-E option. The option handles + INET sockets using IPC. + + + [linux] Added support for POSIX MQ of Linux + implementation. A POSIX message queue (MQ) is + represented in a fd on Linux. lsof reported it as a + regular file. lsof with this change reports it as a + file with PSXMQ type if mqueue file system is mounted. + + + [linux] Added Linux display of POSIX message queue + endpoint information with +|-E option. mqueue file system + must be mounted to display the information. + + + [linux] Added Linux display of INET6 socket endpoint + information with +|-E option. The option handles + INET6 sockets using IPC. + + + [FreeBSD] update to include on recent -CURRENT + since it is no longer implicitly included via header pollution. + + + [linux] Added Linux display of eventfd endpoint information + with +|-E option. The option handles eventfd using IPC. + + + [FreeBSD] include for recent change requiring + refcount(9). + + + Enhanced -r option. With `c' specifier, lsof can stop itself + when the number of iterations reaches at . + + + [linux] Fixed accessing an uninitialized local variable. + Detected by valgrind. + + + [linux] fix a crash when printing the endpoint for unaccepted + unix socket with +E option. + This closes the github issue #74 reported by @jolmg. + + + [linux] abort execution when failing in memory allocation for + socket private data. + + + [linux] decode the name of DCCP socket type. + + + [linux] decode more netlink protocol numbers (RDMA, CRYPTO, and + SMC). + + + [linux] print the connection state of unix domain socket + Lsof can print the state of TCP socket like: + + nc 22247 yamato 3u IPv4 471409 0t0 TCP localhost:38802->localhost:9999 (ESTABLISHED) + + This change exnteds this feature to support unix domain sockets. + LISTEN, UNCONNECTED, CONNECTING, CONNECTED, DISCONNECTING, + and UNKNOWN can be taken as a state. + An example of output: + + evince 17333 yamato 1u unix 0x0000000054183795 0t0 89141 type=STREAM (CONNECTED) + + This feature is enabled by default. + To turn off printing state information, use -T option. + + Don't display command usage even when a file (or directory) listed + in command line doesn't exist. + This closes the github issue #90 reported by @rowlap. + + + [FreeBSD] merge all the FreeBSD specific fixes from the FreeBSD sysutils/lsof port + + + [linux] allow reproducible builds + In a reproducible build all varied information is removed. This + change does so, by checking if the standard SOURCE_DATE_EPOCH + variable is set. If it is, we are attempting a reproducible build + and will strip varying information. + About the standard, see https://reproducible-builds.org/specs/source-date-epoch/ + Provided in github pull request #93 by @T4cC0re. + + + + [freebsd] update for r363214 + - no user visible changes + + + Added the way to include (or exclude) all numbered file descriptors + in -d option. "fd" is a pseudo file descriptor name for the purpose. + See the following output on Linux; lsof doesn't print cwd, rtd, txt, + and mem files. + + # ./lsof -p $$ -a -d fd + COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME + bash 866421 root 0u CHR 136,1 0t0 4 /dev/pts/1 + bash 866421 root 1u CHR 136,1 0t0 4 /dev/pts/1 + bash 866421 root 2u CHR 136,1 0t0 4 /dev/pts/1 + bash 866421 root 255u CHR 136,1 0t0 4 /dev/pts/1 + + + + docs: fixed minor grammatical error in instructions in Customize file + The change is provided by @hardikpnsp. + + + man page: improve phrasing and add examples + The change is provided by Martin D Kealey. + + + man page: improve explanation of -t implying -w + The change is provided by Martin D Kealey. + + + test cases, [linux]: fix tests for large inode-numbers (i >= 2^32) + The change is provided by Henry Peteet. + + + [linux] handle ffff:ffff in ipv6 addr correctly + The listen address and port of an AF_INET6 socket were not display if + the socket listened at an ipv6 address including ffff:ffff. + + Here is a command session demonstrating the bug: + + # ip -6 addr add abcd:ef10:ffff:ffff:ffff:ffff:ffff:ff62 dev lo + # nc -6 -l abcd:ef10:ffff:ffff:ffff:ffff:ffff:ff62 8888 & + [1] 6762 + # ./lsof -p 6762 -a -d fd -P -n + COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME + nc 6762 yamato 0u CHR 136,6 0t0 9 /dev/pts/6 + nc 6762 yamato 1u CHR 136,6 0t0 9 /dev/pts/6 + nc 6762 yamato 2u CHR 136,6 0t0 9 /dev/pts/6 + nc 6762 yamato 3u sock 0,9 0t0 5833594 protocol: TCPv6 + + The last line should be: + + nc 6762 yamato 3u IPv6 5833594 0t0 TCP [abcd:ef10:ffff:ffff:ffff:ffff:ffff:ff62]:8888 (LISTEN) + + The original code decoding an ipv6 address uses UINT32_MAX constant + incorrect way. + + @zhrf2020 reported this bug in #102. + @zhrf2020 provided the initial version of fix, #109. + + + man page,[linux]: enumerate abbreviated flags printed with '+f g' option + + + Make -Fo option work + -Fo option is for printing file offset. For regular files, + the option didn't work. + + Here is a command session demonstrating the fix: + + # ./lsof -Fo -o0| grep ^o | sort | uniq -c + 90586 o0t0 + 87 o0t101 + 84 o0t103 + ... + @JustAnotherArchivist reported this bug in #118. + + + man page: fix definition of the `o` field on programmatic output + The change is provided by @JustAnotherArchivist who reported + the original issue in #118. + + + [linux]: show the pid monitored by a pidfd + With this change, lsof prints pidfd in the following form: + + [pidfd:%d] + + where %d represents the pid monitored by the pidfd. + + Example output: + + # ./lsof -p 12573 -p 12710 | grep pidfd + dbus-brok 12573 jet 11u a_inode 0,13 0 13312 [pidfd:12575] + dbus-brok 12710 jet 10u a_inode 0,13 0 13312 [pidfd:12711] + + fd 11 of pid 12573 monitors pid 12575. + fd 10 of pid 12710 monitors pid 12711. + This change closed #116. + + + Don't select the file descriptor field by default. + The version 4.88 introduced the change for selecting the file + descriptor field by default. However, the change is not + suitable for users who wants to print only PID field. + @po5857 suggests the use case and the way to improve the man page. + + + [linux]: enumerate fds monitored by an eventpoll fd + With this change, lsof prints an eventpoll fd in the following form: + + [eventpoll:,,...,...] + + Here fdX is a file descriptor monitored by the eventpoll fd. + If an eventpoll fd monitors too many file descriptors, lsof + truncates the list of fds. "..." at the end of list implies + the truncation. + + Example output: + + # sudo ./lsof -p 1 -a -d 10,11,12 + COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME + systemd 1 root 10u a_inode 0,13 0 11624 [eventpoll:11,12] + systemd 1 root 11r REG 0,4 0 17680 /proc/1/mountinfo + systemd 1 root 12r a_inode 0,13 0 11624 inotify + + systemd monitors fd 11 and fd 12 via eventpoll fd 10. + + + [linux]: implement "make check" + The target runs check.bash. + +4.95.0 April 28, 2022 + + [n+obsd] fix syntax error + Corrected end of comment. + This change closes #138. + @albert-github reported this issue in #138, + and provided the fix in #140 + + + Don't ignore failures in test/Makefile + Tobias Geerinckx-Rice provides the fix. + + + Update perl scripts for the past few decades of progress + Generally, perl is available on base systems - people who are manually + installing perl into /usr/local/bin are the exception rather than the + rule. In addition, Perl 5 was release in 1994, so Perl 4 isn't relevant + any more. We've also standardized on the .pl extension, rather than + .perl5 or whatever. + Provided by @dilinger (Andres Salomon) in #149. + A commit in the pull request includes work of Nicholas Bamber. + + + Drop LSOF_CCDATE across all dialects to ensure reproducible builds + Simplify things for reproducible builds by just getting rid of + the embedded date/time string. With LSOF_CCDATE gone, keeping + SOURCE_DATE_EPOCH around doesn't make much sense, so drop that as + well. Folks doing reproducible builds should still override the + LSOF_HOST, LSOF_LOGNAME, LSOF_SYSINFO, and LSOF_USER variables (as + they were previously doing before SOURCE_DATE_EPOCH). + Provided by @dilinger (Andres Salomon) in #150. + + + [FreeBSD] get the ISO9660 filesystem working again + The ISO9660 filesystem broke starting with FreeBSD 7 due to the header + location changing. Fix the header search path to get it to be detected + again. Fix the header inclusion order. Also add the new way of finding + dev_t on more recent FreeBSD versions. + Provided by Damjan Jovanovic in #151. + + + [FreeBSD] add support for msdosfs on FreeBSD + Provided by Damjan Jovanovic in #151. + + + Fix FD field description. + In 811dc78 the output format was changed to not printf the `f` + field by default, however the field description in `lsof_fields.h`, + as seen in `-F?` output still included the `(always selected)` text. + Provided by @algorythmic (Grisha Levit) in #158. + + + Adjust alignment of buffer passed to stat(). + The original code passes char[] buffer to stat(). This can be cause + a SIGBUS. #160 reported an actual crash on armv7a + glibc-2.33 platform. + See also https://sourceware.org/bugzilla/show_bug.cgi?id=27993. + Reported by @10ne1 in #160. + + + Clean up source code and documentats. + - remove trailing whitespace, + - fix some issues in scripts found through shellcheck, and + - fix spelling + Provided by @a1346054 in #163. + + + man page: fix hyphen issues + Properly use '-' and '\-' in the man page, ensuring that users + can cut & paste commandline options without issue. Original + patch from Raoul Gunnar Borenius , and + submitted/expanded by @dilinger (Andres Salomon) in #168. + + + + [FreeBSD] update for FreeBSD 13 & 14, and various internal changes + submitted by @DmitryAndric & @emaste. + + + [FreeBSD] remove various old FreeBSD versions from support + submitted by @emaste + + + [FreeBSD] configure: suggest variable to set if FreeBSD sys not + found + submitted by @emaste + + [FreeBSD] Use user mode APIs on FreeBSD + Extensively changes the FreeBSD dialect to use user mode APIs + (sysctls and libutil's kinfo_getfile()), only falling back to kvm + access when it's available and required for certain features. lsof can + now run as an ordinary user, though not all processes may be visible + and some features will be absent without kvm access (file lock state, + kqueue info, some pipe details, nullfs details). + This also fixes numerous long standing issues: file lock state is now + visible on all filesystems, the cwd, root dir, jail dir, text file and + controlling TTY are now visible, filenames are shown for all + filesystems, procfs is working again and supports file searches even + when there are multiple procfs mountpoints, the code is shorter, + cleaner and should need much less future maintenance. + It builds and works from FreeBSD 9.0 to 14-CURRENT, though older + versions have less features (eg. 12 doesn't provide socket buffer + usage, 11 also lacks TCP flags and state). + Provided by @DamjanJovanovic in #184. + + + Fix broken LSOF_CFLAGS_OVERRIDE. + Provided by Fabrice Fontaine in #172. + + + [linux] Remove sysvlegacy function. + Provided by Fabrice Fontaine in #195. + + + [linux] use close_range instead of calling close repeatedly + At the starting up, lsof closes its file descriptors greater + than 2 by calling close(2) repeatedly. As reported in #186, + it can take long time. Linux 5.9 introduced close_range(2). + The new system call can close multiple file descriptors faster. + @qianzhangyl reported the original issue (#186). + + + Add -Q option for adjusting exit status when failed to find a + search item (#129) + In the original code, lsof returned 1 when it failed to find a + search item. With the new option, lsof returns 0 in the case. + + + Document -Q option in manpage/00QUICKSTART, and adjust -h + output by @dilinger (Andres Salomon) in #129. + + + Improve readability of complex adverbial clause by adding a + comma. + Provided by Danny Fowler in #156. + +4.96.0 September 16, 2022 + + [linux] fix hash functions used for finding local tcp/udp IPCs + There were typos in the code calculating hash values. The typos might + break the flatness of hashtables where the endpoint information about + locally used tcp/udp was stored. Theoretically, this fix may improve + the performance of lsof with [+|-]E option. + Inspired by the issue #206 reported by Tomasz Kłoczko (@kloczek). + + + Show copyright notice in --version output. + + + [linux] compile with -Wall option + + + [linux] Avoid some easy collissions for udp/udp6 sockets when hashing + + + [linux] Changing the number of ipcbuckets to 4096 + + + [darwin] fix build with -fno-common (Cfp redefinition) + gcc-10 and llvm-11 changed the default from -fcommon to -fno-common: + https://gcc.gnu.org/PR85678 + As a result build fails as: + + duplicate symbol '_Cfp' in: ddev.o dfile.o + + Cfp is already explicitly defined in dstore.c. The change turns + header definition into declaration. + Provided by Sergei Trofimovich (@trofi) in #221. The same fix is + applied to libproc backend by Jiajie Chen (@jiegec) in #226. + + + [linux] Make build reproducible by checking SOURCE_DATE_EPOCH + and considering LSOF_{HOST,LOGNAME,SYSINFO,USER} as "none" when + it is set. + Provided by Danilo Spinella in #217 + + + [darwin] remove /usr/include prefix from include for Darwin 19+ + The /usr/include path is missing since macOS Catalina. + Fixes issue #234. + Provided by Jiajie Chen in #235 + + + [linux] obtain correct information of memory-mapped file. + Provided by Teng Hu in #239 + + + [FreeBSD] configure: suggest variable to set if FreeBSD sys not + found + Submitted by @emaste + + + Updated 00FAQ with lookup to open files via mountpoint + Provided by Jacob Chapman in #240 + + + [FreeBSD] modernize API usage and remove legacy FreeBSD releases + Contributor DamjanJovanovic (#184) Ed Maste (#250, #251, #252), + Warner Losh (#253) + +4.96.1 September 16, 2022 + + [FreeBSD] Unconditionally define HASKQUEUE (mjguzik) + +4.96.2 September 16, 2022 + + [FreeBSD] fix FreeBSD < 14 + +4.96.3 September 16, 2022 + + [FreeBSD] Fix kqueue compat for releases < 14 + +4.96.4 October 18, 2022 + + [FreeBSD] sys/files.h no longer needs _KERNEL defined to + include it (bsdimp #256) + + + docs: Describe fd number truncation in output (#261) + +4.96.5 December 26, 2022 + + [linux] Use correct scanf/printf format for uint64_t (#266) + + + Avoid C89-only constructs in Configure (#265) + + + [freebsd] add for recent changes + +4.97.0 January 17, 2023 + + [decof/du/tru64] Remove support because the os is no longer + updated for more than 10 years + + + [openstep/nextstep] Remove support because the os is no longer + updated for more than 20 years + + + Add experimental build system based on Autotools (#270) + + + Fixed LTsock testing on darwin (#272) + + + Remove NEW and OLD folders (#6) + + + Fix FreeBSD testcases (#271) + + + Rewrite documentation and publish at https://lsof.readthedocs.io/ + +4.98.0 January 22, 2023 + + Fix two potential null pointer access bug when gethostbyname2() + returns an empty address list + + + Add support for older automake versions (on e.g. CentOS 7) + + + Migrate testing scripts and programs to autotools + + + Extend CI to build on more Linux distros + + + [linux] Fix handling of empty command name, closing #246. + Add test from #246, where lsof returns stale command name when the + command name is empty. If getting command name failed, return + NULL instead of empty string + + + Add --with/without-libtirpc option to autotools-based build + system and automatically detect libtirpc by default + + + Add -H switch to print human readable size, e.g. 123.4K (#260) + + + [linux] Fix implicit declaration error when HASPTYEPT is undefined + + + Add support for musl libc-based Linux distros + + + Add --enable-security argument to configure to allow only the + root user to list all open files + + + Add --enable-no-sock-security argument to configure to allow + anyone to list anyone else's socket files when combined with + --enable-security + + + [linux] Always enable 64 bit off_t in configure.ac + + + [netbsd] Import patches from pkgsrc and port autotools-based build system to NetBSD + + + [netbsd] Fix lock status reading + +4.99.0 November 10, 2023 + + [netbsd] Get device number of tmpfs instead of reporting zero + + + [openbsd] Rewrite OpenBSD support because OpenBSD disallows + kernel memory access and lsof has to switch to user mode API. + Currently, most features are working, but file path reporting + and lock status are not working for lack of kernel support. + As a consequence, OpenBSD dialect is separated in a new folder. + + + [darwin] Remove /dev/kmem backend because it no longer exists on + current macOS releases. Use libproc backend instead. + + + [linux] Do not hard-code fd numbers in epoll test, fixing tests + on Void Linux + + + [freebsd] Use kf_file_nlink if provided by kernel instead of + stat(). This commit requires kernel with + https://reviews.freebsd.org/D38169. It brings back the ability + to list deleted files via `lsof +L1`. Closes #264. + + + [linux] Add --with-selinux configure option. + + + [solaris] Re-introduce support for recent Solaris & OpenIndiana + releases. + + + [darwin] Display kern ctl info, learned from apple lsof version. + + + [linux] Improve performance by using closefrom(). Closes #281. + + + [aix] Fix compilation on AIX 7.2 and add autotools build system + support for AIX. + + [aix] Suppress warnings properly on AIX version greater than + 5.0. Closes #187. + + Introduce alpha version of liblsof which allows users to use + lsof functionality via C functions instead of spawning a + subprocess and parsing the output. This version may contain BUGs + and memory leaks, and the API may change before it stablizes. + +4.99.1 December 16, 2023 + + Fix compilation error when HASIPv6 is not defined. (@chenrui333) + + Add configure option --disable-liblsof to disable installation + of liblsof. (@subnut, #300) + + [freebsd] fix segfault from fs info (FreeBSD bug 267760) + +4.99.2 December 16, 2023 + + fix version file + +4.99.3 December 16, 2023 + + fix 00DIST file -> tabs + +4.99.4 November 18, 2024 + + fix version parser for clang (lsof-org#305) (#306) + + In lsof manapge: mention /etc/services for -P option (#309) + + [freebsd] don't use kf_sock_inpcb on modern versions. In + FreeBSD 14 and after the generic internet protocol control + block and protocol specific (TCP) control block are the same + pointer. The latter embeds the former. The kf_sock_inpcb is + planned for removal in FreeBSD 15. + + [freebsd] Recognize FreeBSD 15 + + Fix typos in docs (#314) + + [linux] Do not embed kernel version in CFLAGS (#314) + + [linux] Linux 6.9 changed the pidfs appearence in procfs. Try + to maintain original output in lsof (#317) + + [linux] closefrom_shim: Add optimized fallback for platforms + without closefrom or close_range (#316) + + lib/misc.c: fix build against -std=c23 (`void (*)()`) changed + the meaning) (#327) + +4.9?.? ????????? ??, ???? + + +Vic Abell +July 14, 2018 + +The lsof-org team at GitHub +December 28, 2022 diff --git a/00FAQ b/00FAQ new file mode 100644 index 0000000..e8d79c1 --- /dev/null +++ b/00FAQ @@ -0,0 +1,7781 @@ + + 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 +October 13, 2014 +______________________________________________________________________ + +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_? +1.2.5 Why won't gpg accept the lsof-signing PGP public key? +1.3 Where can I get more lsof documentation? +1.4 How do I report an lsof bug? +1.5 Where can I get the lsof FAQ? +1.5.1 How timely is the on-line FAQ? +1.6 Is there a test suite? +1.7 Is lsof vulnerable to the standard I/O descriptor attack? +1.8 Can I alter lsof's make(1) behavior? +1.9 Is there an lsof license? +1.10 Language locale support +1.10.1 Does lsof support language locales? How do I use the support? +1.10.2 Does lsof support wide characters in language locales? +1.11 Are any files in the lsof distribution copyrighted? +1.12 Are there other lsof-related resources? +1.13 What does the "WARNING: unsupported dialect or version" mean? + +2.0 Lsof Ports +2.1 What ports exist? +2.2 What about a new port? +2.2.1 User-contributed Ports +2.3 Why isn't there an AT&T SVR4 port? +2.4 Why isn't there an SGI IRIX port? +2.5 Why does lsof's Configure script report "WARNING: unsupported + dialect or version"? + +3.0 Lsof Problems +3.1 Configuration Problems +3.1.1 Why can't Configure determine the UNIX dialect version? +3.2 Compilation Problems +3.2.1 Why does the compiler complain about missing header files? +3.2.2 Why does gcc complain about the contents of header files + distributed by the system's vendor? +3.2.3 Other header file problems +3.3 Why doesn't lsof report full path names? +3.3.1 Why do lsof -r reports show different path names? +3.3.2 Why does lsof report the wrong path names? +3.3.3 Why doesn't lsof report path names for unlinked (rm'd) files? +3.3.4 Why doesn't lsof report the "correct" hard linked file path + name? +3.3.5 When will lsof report path names for deleted files? +3.4 Why is lsof so slow? +3.5 Why doesn't lsof's setgid or setuid permission work? +3.6 Does lsof have security problems? +3.7 Will lsof show remote hosts using files via NFS? +3.8 Why doesn't lsof report locks held on NFS files? +3.8.1 Why does lsof report a one byte lock on byte zero as a full + file lock? +3.9 Why does lsof report different values for open files on the + same file system (the automounter phenomenon)? +3.10 Why don't lsof and netstat output match? +3.10.1 Why can't lsof find accesses to some TCP and UDP ports? +3.11 Why does lsof update the device cache file? +3.12 Why doesn't lsof report state for UDP socket files? +3.13 I am editing a file with vi; why doesn't lsof find the file? +3.14 Why doesn't lsof report TCP/TPI window and queue sizes for my + dialect? +3.14.1 Why doesn't lsof report socket options, socket states, and TCP + flags and values for my dialect? +3.14.2 Why doesn't lsof report the partial listen queue connection + count for my dialect? +3.15 What does "no more information" in the NAME column mean? +3.16 Why doesn't lsof find a process that ps finds? +3.17 Why doesn't -V report a search failure? +3.18 Portmap problems +3.18.1 Why isn't a name displayed for the portmap registration? +3.18.2 How can I display only portmap registrations? +3.18.3 Why doesn't lsof report portmap registrations for some ports? +3.18.4 Why doesn't lsof report portmap registrations for some Solaris + versions? +3.19 Why is `lsof | wc` bigger than my system's open file limit? +3.20 Why doesn't lsof report file offset (position)? +3.20.1 What does lsof report for size when the file doesn't really have + one? +3.21 Problems with path name arguments +3.21.1 How do I ask lsof to search a file system? +3.21.2 Why doesn't lsof find all the open files in a file system? +3.21.3 Why does the lsof exit code report it didn't find open files + when some files were listed? +3.21.4 Why won't lsof find all the open files in a directory? +3.21.5 Why are the +D and +d options so slow? +3.21.6 Why do the +D and +d options produce warning messages? +3.22 Why can't my C compiler find the rpcent structure definition? +3.23 Why doesn't lsof report fully on file "foo" on UNIX dialect + "bar?" +3.24 Why do I get a complaint when I execute lsof that some library + file can't be found? +3.25 Why does lsof complain it can't open files? +3.26 Why does lsof warn "compiled for x ... y; this is z."? +3.27 How can I disable the kernel identity check? +3.28 Why don't ps(1) and lsof agree on the owner of a process? +3.29 Why doesn't lsof find an open socket file whose connection + state is past CLOSE_WAIT? +3.30 Why don't machine.h definitions work when the surrounding + comments are removed? +3.31 What do "can't read inpcb at 0x...", "no protocol control + block", "no PCB, CANTSENDMORE, CANTRCVMORE", etc. mean? +3.32 What do the "unknown file system type" warnings mean? +3.33 Installation +3.33.1 How do I install lsof? +3.33.2 How do I install a common lsof when I have machines that + need differently constructed lsof binaries? +3.34 Why do lsof 4.53 and above reject device cache files built + by earlier lsof revisions? +3.35 What do "like block special" and "like character special" mean + in the NAME column? +3.36 Why does an lsof make fail because of undefined symbols? +3.37 Command Regular Expressions (REs) +3.37.1 What are basic and extended regular expressions? +3.37.2 Why can't I put a slash in a command regular expression? +3.37.3 Why does lsof say my command regular expression wasn't found? +3.38 Why doesn't lsof report on shared memory segments? +3.39 Why does lsof report two instances of itself? +3.40 Why does lsof report '\n' in device cache file error messages? +3.41 Kernel Symbol and Address Problems +3.41.1 What does "lsof: WARNING: name cache hash size length error: 0" + mean? +3.41.2 Why does lsof produce "garbage" output? +3.42 Why does lsof report open files when run as super user that + it doesn't report when run with lesser privileges? +3.43 Test Suite Problems +3.43.1 Errors all tests can report: +3.43.1.1 Why do tests complain "ERROR!!! can't execute ../lsof"? +3.43.1.2 Why do tests complain "ERROR!!! can't find ..." a file? +3.43.1.3 Why do some tests fail to compile? +3.43.1.4 Why do some tests always fail? +3.43.1.5 Why does the test suite say it hasn't been validated on + my dialect? +3.43.1.6 Why do the tests complain they can't stat() or open() + /dev/mem or /dev/kmem? +3.43.2 LTbigf test issues +3.43.2.1 Why does the LTbigf test say that the dialect doesn't + support large files? +3.43.2.2 Why does LTbigf complain about operations on its config.LTbigf* + file? +3.43.2.3 Why does LTbigf warn that lsof doesn't return file offsets? +3.43.3 Why does the LTbasic test complain "ERROR!!! lsof this ..." + and "ERROR!!! lsof that ..."? +3.43.4 LTnfs test issues +3.43.4.1 Why does the LTnfs test complain "couldn't find NFS file ..."? +3.43.5 LTnlink test issues +3.43.5.1 Why does the LTnlink test complain that its test file is on + an NFS file system? +3.43.5.2 Why does LTnlink delay and report "waiting for link count + update: ..."? +3.43.5.3 Why does LTnlink fail because of an unlink error? +3.43.6 LTdnlc test issues +3.43.6.1 Why won't the LTdnlc test run? +3.43.6.2 What does the LTdnlc test mean by "... found: 100.00%"? +3.43.6.3 Why does the DNLC test fail? +3.43.7 Why hasn't the test suite been qualified for 64 bit HP-UX + 11 when lsof is compiled with gcc? +3.43.8 LTszoff test issues +3.43.8.1 Why does LTszoff warn that lsof doesn't return file offsets? +3.43.9 LTlock test issues +3.44 File descriptor list (the ``-d'' option) problems +3.44.1 Why does lsof reject a ``-d'' FD list? +3.44.2 Why are file descriptors other than those in my FD list + reported? +3.45 How can I supply device numbers for inaccessible NFS file + systems? +3.46 Why won't lsof find open files on over-mounted file systems? +3.47 What can be done when lsof reports no more space? +3.48 What if the lsof build encounters ar and ld problems? +3.49 Why does lsof -i report an open socket file for a process, but + lsof -p on that process' ID report nothing? + +4.0 AIX Problems +4.1 What is the Stale Segment ID bug and why is -X needed? +4.1.1 Stale Segment ID APAR +4.2 Gcc Work-around for AIX 4.1x +4.3 Gcc and AIX 4.2 +4.4 Why won't lsof's Configure allow the use of gcc for AIX + below 4.1? +4.5 What is an AIX SMT file type? +4.6 Why does AIX lsof start so slowly? +4.7 Why does exec complain it can't find libc.a[shr.o]? +4.8 What does lsof mean when it says, "TCP no PCB, CANTSENDMORE, + CANTRCVMORE" in a socket file's NAME column? +4.9 When the -X option is used on AIX 4.3.3, why does lsof disable + it, saying "WARNING: user struct mismatch; -X option disabled?" +4.10 Why doesn't the -X option work on my AIX 5L or 5.[123] system? +4.11 Why doesn't /usr/bin/oslevel report the correct AIX version? +4.11.1 Why doesn't /usr/bin/oslevel report the correct AIX version + on AIX 5.1? +4.12 Why does lsof for AIX 5.1 or above Power architecture + complain about kernel bit size? +4.13 What can't gcc be used to compile lsof on the ia64 architecture + for AIX 5 and above? +4.14 Why does lsof get a segmentation fault when compiled with gcc + for a 64 bit Power architecture AIX 5.1 kernel? +4.15 Why does lsof ignore AFS on my AIX system? +4.16 Why does lsof report "system paging space is low" and exit? +4.17 Why does lsof have compilation and execution problems on AIX + 5.3 above maintenance level 1? + +5.0 Apple Darwin Problems +5.1 What do /dev/kmem-based and libproc-based mean? +5.2 /dev/kmem-based Apple Darwin Questions +5.2.1 Why does Configure ask for a path to the Darwin XNU kernel + header files? +5.2.1.1 Why does Configure complain that Darwin XNU kernel header + files are missing? +5.2.2 Why doesn't Apple Darwin lsof report text file information? +5.2.3 Why doesn't Apple Darwin lsof support IPv6? +5.2.4 Why does lsof complain about a mismatch between the release + for which lsof was compiled and the booted Mac OS X release? +5.2.5 Why does lsof for Apple Darwin 8 and higher report + "stat(...): ..." in the NAME column? +5.2.6 What are the limitations of Apple Darwin lsof link count + reporting? +5.2.7 Why does Apple Darwin report process group IDs incorrectly?"ayy +5.3 Libproc-based Apple Darwin Questions + +6.0 BSD/OS BSDI Problems +6.0.5 Statement of deprecation + +8.0 FreeBSD Problems +8.1 Why doesn't lsof report on open kernfs files? +8.2 Why doesn't lsof work on my FreeBSD system? +8.3 Why doesn't lsof work on the RELEASE version of CURRENT? +8.4 Why can't kvm_open() can't find some file? +8.5 FreeBSD ZFS Problems +8.5.1 Why does FreeBSD lsof report "WARNING: no ZFS support has been +8.6 Why can't Configure create lsof_owner.h for FreeBSD 6 and above? +8.6.1 Why are there lockf structure compiler errors for FreeBSD 6.0 + and higher lsof? +8.6.2 Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h + match? +8.7 FreeBSD and clang +8.7.1 Why does clang complain about VOP_FSYNC? + +9.0 HP-UX Problems +9.1 What do /dev/kmem-based and PSTAT-based mean? +9.2 /dev/kmem-based HP-UX lsof Questions +9.2.1 Why doesn't a /dev/kmem-based HP-UX lsof compilation use -O? +9.2.2 Why doesn't the /dev/kmem-based CCITT support work under 10.x? +9.2.3 Why can't /dev/kmem-based lsof be compiled with `cc -Aa` or + `gcc -ansi` under HP-UX 10.x? +9.2.4 Why does /dev/kmem-based lsof complain about no C compiler? +9.2.5 Why does Configure complain about q4 for /dev/kmem-based lsof + for HP-UX 11? +9.2.6 When compiling /dev/kmem-based lsof for HP-UX 11 what do the + "aCC runtime: ERROR..." messages mean? +9.2.7 Why doesn't /dev/kmem-based lsof for HP-UX 11 report VxFS file + link counts, node numbers, and sizes correctly? +9.2.8 Why can't /dev/kmem-based lsof be built with gcc for 64 bit + HP-UX 11? +9.2.8.1 How can I acquire a gcc for building lsof for 64 bit HP-UX 11? +9.2.9 Why does /dev/kmem-based lsof for HP-UX 11 report "unknown file + system type" for VxFS files? +9.2.10 Why does the ANSI-C compiler complain about comments in HP-UX + 11 header files? +9.2.11 Why does dnode1.c cause the HP-UX 11 compiler to complain that + 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? + +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 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 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//sys/machparam.h? +17.7 Why does Solaris lsof say ``can't read proc table''? +17.8 Why does Solaris lsof complain about a bad cached clone device? +17.9 Why doesn't Solaris make generate .o files? +17.10 Why does lsof report some Solaris 2.3 and 2.4 lock types as `N'? +17.11 Why does lsof Configure say "WARNING: no cc in ..."? +17.12 Solaris 7, 8 and 9 Problems +17.12.1 Why does lsof say the compiler isn't adequate for Solaris + 7, 8 or 9? +17.12.2 Why does Solaris 7, 8 or 9 lsof say "FATAL: lsof was compiled + for..."? +17.12.3 How do I build lsof for a 64 bit Solaris kernel under a 32 + bit Solaris kernel? +17.12.4 How do I install lsof for Solaris 7, 8 or 9? +17.12.5 Why does my Solaris 7, 8 or 9 system say it cannot execute + lsof? +17.12.6 What gcc will produce 64 bit Solaris 7, 8 and 9 executables? +17.12.7 Why does lsof on my Solaris 7, 8 or 9 system say, "can't + read namelist from /dev/ksyms?" +17.13 Solaris and COMMON +17.13.1 What does COMMON mean in the NAME column for a Solaris VCHR + file? +17.13.2 Why does a COMMON Solaris VCHR file sometimes seem to have an + incorrect minor device number? +17.14 Why don't lsof and Solaris pfiles reports always match? +17.15 Why does lsof say, "kvm_open(namelist=default, core=default): + Permission denied?" +17.16 Why is lsof slow on my busy Solaris UFS file system? +17.17 Why is lsof so slow on my Solaris 8 or 9 system? +17.18 Solaris and VxFS +17.18.1 Why doesn't lsof support VxFS 3.4 on Solaris 2.6, and above? +17.18.2 Why does lsof report "vx_inode: vxfsu_get_ioffsets error" + for open Solaris 2.6 and above VxFS 3.4 and above files? +17.18.3 Why does Solaris Configure claim there is no VxFS library? +17.18.4 Why doesn't Solaris lsof report VxFS path name components? +17.18.5 Why does Solaris 10 lsof report scrambled VxFS paths? +17.19 Large file problems +17.19.1 Why does lsof complain it can't stat(2) a Solaris 2.5.1 + large file? +17.20 Why does lsof get a segmentation fault on 64 bit Solaris + 8 using NIS+? +17.21 Will lsof crash the Solaris kernel? +17.22 Why does lsof on Solaris 7, 8, or 9 report a kvm_open() + failure? +17.23 Solaris and SAM-FS +17.23.1 Why does Solaris lsof report "(limited SAM-FS info)"? +17.23.2 Why can't lsof locate named SAM-FS files? +17.24 Lsof and Solaris 10 zones +17.24.1 How can I make lsof list the Solaris zone? +17.24.2 Why doesn't lsof work in a Solaris 10 zone? +17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file + systems? +17.25 Solaris 10 problems +17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name? +17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on + directory and device? +17.25.3 What does "(deleted)" mean in the NAME column of a Solaris 10 + open file? +17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open + file? +17.26 Solaris contract file problems +17.26.1 Why doesn't lsof report size, link count and node number for + Solaris 10 contract files? +17.26.2 Why can't lsof locate a Solaris 10 contract file by path name? +17.27 Solaris 10 and above ZFS problems +17.27.1 Why does Configure warn that ZFS support is not enabled? +17.28 Problems with Solaris 9 and above +17.28.1 Why does the compiler complain about lgrp_root on Solaris 9 + and above? + +18.0 Lsof Features +18.1 Why doesn't lsof doesn't report on /proc entries on my + system? +18.2 How do I disable the device cache file feature or alter + its 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 March 21, 2013 these sites appeared to have the latest + lsof revision: + + ftp://ftp.fu-berlin.de/pub/unix/tools/lsof + ftp://sunsite.ualberta.ca/pub/Mirror/lsof + http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/ + ftp://ftp.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/ + rsync://rsync.mirrorservice.org/lsof.itap.purdue.edu/pub/tools/unix/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_ + 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_ 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_? + + The "Security" section of the README.lsof_ 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_, 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 to + https://github.com/lsof-org/lsof. Do NOT report lsof bugs to the UNIX + dialect vendor. + + Before you send 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 . 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 + $ (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.[234], 9.0, 10.0 and 11.0 for AMD64-based systems + Linux 2.1.72 and above for x86-based systems + Solaris 9, 10 and 11 + + In the above list the only UNIX dialects present are ones for + which I test the current lsof revision. Lsof may still support + unlisted dialect versions -- e.g., HP-UX 10.20, Solaris 7, etc. + -- but I don't have access to systems where I could test lsof + on them, so I can't claim lsof works on them. If your dialect + isn't in the list, you should try building lsof on it anyway. + + Lsof version 4 predecessors, versions 2 and 3, may support older + version of some dialects. Contact me via e-mail at + 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 encountered 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 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 presence 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 . + 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 + OpenBSD + 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 -inum -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 '' option to limit lsof to that + process. (The ``-p'' option may also be followed with a list + of Process-IDs.) + + If you're interested in including or excluding certain + commands, try lsof's "-c[^]cmd" option. + + If you're interested in certain Internet TCP and UDP states + (e.g., ESTABLISHED) or in excluding some (e.g., CLOSE_WAIT), + try lsof's "-s p:s" option, available where shown on the lsof + help output, obtained with -h or -?. More information on it + may be found in the answer to the "How are protocol state name + exclusion and inclusion used?" question. + + Your UNIX dialect may not support "-s p:s" and its associated + performance improvements 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 its 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. + 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. + 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. + 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. + OpenUNIX 8 + This dialect is no longer supported, so no attempt + was made to add partial listen queue length support + for it. + SCO OpenServer Release 5.0.6 + No partial listen queue information is available. + Solaris 2.6, 8 and above + Partial listen queue information is available. + Tru64 UNIX 5.0 + This dialect is no longer supported, so no attempt + was made to add partial listen queue length support + for it. + Tru64 UNIX 5.1 + Partial listen queue information is available. + UnixWare 7.1.[134] + Partial listen queue information is available. + + +3.15 What does "no more information" in the NAME column mean? + + When lsof can find no successor structures -- a gnode, + inode, socket, or vnode -- connected to the file structure + of an open descriptor of a process, it reports "no more + information" in the NAME column. The TYPE, DEVICE, SIZE/OFF, + and INODE columns will be blank. + + Because the file structure is supposed to contain a pointer + to the next structure of a file's processing support, if + the pointer is NUL, lsof can go no further. + + Some UNIX dialects have file structures for system processes + -- e.g., the sched process -- that have no successor + structure pointers. The "no more information" NAME will + commonly appear for these processes in lsof output. + + It may also be the case that lsof has read the file structure + while it is being assembled and before a successor structure + pointer value has been set. The "no more information" NAME + will again result. + + Unless lsof output is filled with "no more information" + NAME column messages, the appearance of a few should be no + cause for alarm. + +3.16 Why doesn't lsof find a process that ps finds? + + If lsof fails to display open files for a process that ps + indicates exists, there may be several reasons for the + difference. + + The process may be a "zombie" for which ps displays the + "(defunct)" state. In that case, the process has exited + and has no open file information lsof can display. It does + still have a process structure, sufficient for the needs + of ps. + + Another possible explanation is that kernel tables and + structures may have been changing when lsof looked for the + process, making lsof unable to find all relevant process + structures. Try repeating the lsof request. + +3.17 Why doesn't -V report a search failure? + + The usual reason that -V won't report a search failure is + that lsof located the search item, but was prevented from + listing it by an option that doesn't participate in search + failure reporting. + + For example, this lsof invocation: + + $ lsof -V -i TCP@foobar -a -d 999 + + won't report it can't find the Internet address TCP@foobar, + even if there is an open file connected to that address, + unless the open file also has a file descriptor number of + 999 (the ``-a -d 999'' options). + + Compile-time options can also affect -V results in much the + same way. For example, if HASSECURITY and HASNOSOCKSECURITY + are defined at compile time, this lsof invocation, run by a + non-root user: + + $ lsof -V -c inetd + + won't report that it can't find the inetd command, even if + there is a process running the inetd command, because the + HASSECURITY and HASNOSOCKSECURITY options prevent the + listing of all but the socket files of another user, and + no socket file selector (e.g., "-i") was specified. + + +3.18 Portmap problems + +3.18.1 Why isn't a name displayed for the portmap registration? + + When portmap registration reporting is enabled, any time + there is a registration for a local TCP or UDP port, lsof + displays it in square brackets, following the port number + or service name -- e.g., ``:1234[name]'' or ``:name[100083]''. + + The TCP or UDP port number or service number (what follows + the `:') is displayed under the control of the lsof -P + option. The registration identity is held by the portmapper + and may be a name or a number, depending on how the + registration's owner declared it. Lsof reports what the + port map holds and cannot derive a registration name from + a registration number. + + Lsof can be compiled with registration reporting enabled + or disabled by default, under the control of the HASPMAPENABLED + #define (usually in machine.h). The lsof help panel (`lsof + -h`) will show the default. Lsof is distributed with + reporting disabled by default. + +3.18.2 How can I display only portmap registrations? + + Lsof doesn't have an option that will display only TCP or + UDP ports with portmap registrations. The +M option only + enables the reporting of registration information when + Internet socket files are displayed; +M doesn't select + the displaying of Internet socket files -- the -i option + does that. + + This simple lsof pipe to grep will do the job: + + $ lsof -i +M | grep "\[" + + This works because -i selects Internet socket files, +M + enables portmap registration reporting, and only output + lines with opening square brackets will have registrations. + + When portmap registration reporting is enabled by default, + because the lsof builder constructed it that way, +M is + not necessary. (The lsof help panel, produced with `lsof + -h` will display the default portmapper registration + reporting state.) However, specifying +M when reporting + is already enabled is acceptable, as is specifying -M when + reporting is already disabled. + + Digression: lsof will accept `+' or `-' as a prefix to most + options. (That isn't documented in the man page or help + panel to reduce confusion and complexity.) The -i option + is as acceptable as +i, so the above example could be + written a little more tersely as: + + $ lsof +Mi | grep "\[" + + But be careful to use the ``Mi'' ordering, since ``iM'' + implies M is an address argument to `i'. + +3.18.3 Why doesn't lsof report portmap registrations for some ports? + + Lsof reports portmap registrations for local TCP and UDP + ports only. It identifies local ports this way: + + * The port appears in the local address section of the + kernel structure that contains it. + + * The port appears in the foreign address section of a + kernel structure whose local and foreign Internet + addresses are the same. + + * The port appears in the foreign address section of a + kernel address structure whose Internet address is + INADDR_LOOPBACK (127.0.0.1). + + Following these rules, lsof ignores foreign portmapped + ports. That's done for reasons of efficiency and possible + security prohibitions. Contacting all remote portmappers + could take a long time and be blocked by network difficulties + (i.e., be inefficient). Many firewalls block portmapper + access for security reasons. + + Lsof may occasionally ignore portmap registration information + for a legitimate local port by virtue of its local port + rules. This can happen when a port appears in the foreign + part of its kernel structure and the local and foreign + Internet addresses don't match (perhaps because they're on + different interfaces), and the foreign Internet address + isn't INADDR_LOOPBACK (127.0.0.1). + +3.18.4 Why doesn't lsof report portmap registrations for some Solaris + versions? + + In some versions of Solaris -- 9 and 10 are known to exhibit + this problem -- lsof is unable to display portmap registrations. + + This portmap registration reporting failure occurs when the + Solaris netconfig field (in /etc or etc/inet) has its first two + non-comment lines enabling tcp6 and udp6. When netconfig is + configured in that fashion, lsof's attempt to read the portmap + via an RPC function fails. + + I don't have an explanation for the failure, but this comment + in the netconfig(4) man page appears to have some bearing on + the problem: + + # The following two entries starting with udp6 and tcp6 are + # meant to be used for IPv6. If you have Ipv6 enabled on your + # machine then you can uncomment these two lines to enable + # RPC and NFS to use the Ipv6 stack. + ... + #udp6 tpi_clts v inet6 udp /dev/udp6 - + #tcp6 tpi_cots_ord v inet6 tcp /dev/tcp6 - " + + My interpretation of that comment is that there is a different + RPC interface to the portmap when IPv6 is enabled. However, I + can't find any documentation on it in the RPC man pages. If + anyone has information on it, please send it to me at + and put "lsof Solaris portmap" in the subject + line. + + A work-around may be to move the ucp6 and tcp6 lines after the + udp and tcxp lines in netconfig. I don't know if that change + has any unacceptable consequences, but it works for me on my + Solaris 9 test system, and I have a report that it also works + on Solaris 10. + + +3.19 Why is `lsof | wc` bigger than my system's open file limit? + + There is a strong temptation to count open files by piping + lsof output to wc. If your purpose is to compare the number + you get to some Unix system parameter that defines the + number of open files your system can have, resist the + temptation. + + One reason is that lsof reports a number of "files" that + don't occupy Unix file table space -- current working + directories, root directories, jail directories, text files, + library files, memory mapped files are some. Another reason + is that lsof can report a file shared by more than one + process that itself occupies only one file table slot. + + If you want to know the number of open files that occupy + file table slots, use the +ff option and process the lsof + output's FILE_ADDR column information with standard Unix + tools like cut, grep, sed, and sort. + + You might also consider using use lsof's field output with + +ff, selecting the file struct address with -FF, and + processing the output with an AWK or Perl script. See the + list_fields.awk, list_fields.perl, and shared.perl5 scripts + in the scripts/ subdirectory of the lsof distribution for + hints on file struct post-processing filters. + +3.20 Why doesn't lsof report file offset (position)? + + Lsof won't report a file offset (position) value if the -s + option (without parameters) has been specified, or if the + dialect doesn't support the displaying of file offset + (position). (Note that on selected dialects the help output, + obtained with -h or -?, may show that the -s option can also be + supplied the "p:s" parameters; for more information on that + addition, see the answer to the "How are protocol state name + exclusion and inclusion used?" question.) + + That lsof is reporting only file size is indicated by the + fact that the appropriate column header says SIZE instead + of SIZE/OFF. + + If lsof doesn't support the displaying of file offset + (position) -- e.g., for Linux /proc-based lsof -- the -h + or -? output panel won't list the -o option. + + Sometimes the availability of file offset information + depends on the dialect's kernel. This is particularly true + for socket file offsets. + + Maintenance of offsets for pseudo-terminal devices varies + by UNIX dialect and is related to how the dialect kernel + implements pseudo-terminal support. Kernels like AIX, for + example, that short-circuit the transfer of data between + socket and pseudo devices to reduce TCP/IP daemon interrupt + rates won't advance offsets in the TCP/IP daemon socket + files. Instead they will advance offsets in the open + standard I/O files of the shell child precess where the + pseudo-terminal devices are used. + + When in doubt about the behavior of lsof in reporting file + offset information, do some carefully measured experiments, + consult the lsof sources, or contact me at + 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 ` starts with a `b/), + you can specify its 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 either specify the individual path names + of those files, their common mount point, or use the lsof +D + and +d options. + + For example, if you wanted to check the files open in your /lsof + folder then the following might be the quickest way to get + the answer you are looking for: + + lsof / | grep /lsof | grep -v DIR + + 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, , with the rpcent + structure definition, and there is a Solaris C pre-processor + test that can tell when the BIND is in place and + hence 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 and any other header files BIND might + have replaced. (I think BIND replaces , + , -- 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 + 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 : 2 sections + ... + lsof: WARNING: created device cache file: + + 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 " + or "like character special ". + + The value for 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 . 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 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 '' 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 '' 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 + $ 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 ... : + 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: + + + + 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 . 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 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() 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 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 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/ + + where is a unique name in /tmp of your choosing. To + be safe, create a subdirectory in /tmp, named by your login: + + $ rm -f /tmp/ + $ mkdir /tmp/ + $ ./LTnlink -p /tmp// + +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 "... 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 + + If lsof has to get the device number from the supplement, it + will issue an informative warning message. The warning can be + suppressed with lsof's -w option. + + Caution! Since the mount table supplement file is static, it + is its supplier's responsibility to update it as file system + mounts change. + + For more information, consult the lsof man page. The + "ALTERNATE DEVICE NUMBERS" section has useful information on + how lsof acquires device numbers when stat(2) or lstat(2) + fail. + +3.46 Why won't lsof find open files on over-mounted file systems? + + When a file system, /xyz for example, is mounted on the same + mount point as another file system, /abc for example, running + lsof with an argument of the path of the first file system's + mount point -- the over-mounted one, /abc -- probably will not + reveal any files open on /abc. + + That's because lsof looks for open files on a file system by + looking for files with the file system's device number. The + two file systems usually have different device numbers and lsof + determines the device number search key from the supplied name + of the second file system. + + A general work-around exists only for Linux. On that UNIX + dialect, when you know the over-mounted file system's mount + point path, you can ask lsof to report on all open files and + grep that output for the path of the over-mounted file system + mount point. + +3.47 What can be done when lsof reports no more space? + + Many lsof methods cache information in memory, using the + dialects malloc() library function. When malloc() can't + allocate the requested amount of memory, lsof exits with + warning messages similar to this AIX message: + + lsof: no more dev-ch space at pid 2257750: 0x82a8e600 + + Lsof then exits immediately and produces no more output. + + A possible work-around is to increase the memory foot print + of the shell that runs lsof. That is often done with the + ulimit(1) shell command. + +3.48 What if the lsof build encounters ar and ld problems? + + The lsof main and library Makefiles use the library archiver, + ar, and the system loader, ld, applications. Improperly + located, installed or configured versions of them may cause the + lsof build to encounter errors with them. + + The application producing the error should identify itself in + its error messages. + + The first thing to check the path of the application that is + being used. Try `which ar` or `which ld` to see if perhaps the + PATH used during the build might be causing the wrong archiver + or loader to be used. + + If the problem is with the use of the wrong archiver, and it's + not possible to correct the PATH to it, try using the LSOF_AR + environment variable to specify the path to and arguments for + the correct archiver. See 00XCONFIG for more information and + note that LSOF_AR must specify the path to the archive + application and the arguments for it, less the terminating + library and module name arguments. + + If the problem is with the loader, there is no lsof work- + around. That's because lsof calls the loader via the C + compiler, so the problem must be fixed at the compiler (system) + level. + +3.49 Why does lsof -i report an open socket file for a process, but + lsof -p on that process' ID report nothing? + + The lsof in use was probably built with the HASSECURITY and + HASNOSOCKSECURITY options and the process in question does not + belong to the user of lsof. + + The HASSECURITY option limits lsof output to processes owned + by the user invoking lsof and the HASNOSOCKSECURITY option + weakens that slightly to allow output of open socket file + information for all processes. + + For example, if process PID 12345 is owned by some user other + than the one invoking lsof, and lsof has been compiled with the + HASSECURITY and HASNOSOCKSECURITY options, the following lsof + command will display the open socket files of process 12345: + + $ lsof -p 12345 -a -i + + This security restriction is described in the lsof(8) manual + page. + + +4.0 AIX Problems + +4.1 What is the Stale Segment ID bug and why is -X needed? + + Kevin Ruderman reports that he has been informed by IBM + that processes using the AIX 3.2.x, 4.1[.12345]], 4.2[.1], + and 4.3.x kernel's readx() function can cause other AIX + processes to hang because of what appears to be file system + corruption. + + This failure, known as the Stale Segment ID bug, is caused + by an error in the AIX kernel's journaled segment memory + handler that causes the kernel's dir_search() function + erroneously to believe directory entries contain zeroes. + The process using the readx() call need not be doing anything + wrong. Usually the system must be under such heavy load + that the segment ID being used in the readx() call has been + freed and then reallocated to another process since it was + obtained from kernel memory. + + Lsof uses the readx() function to access library entry + structures, based on the segment ID it finds in the proc + structure of a process. Since IBM probably will never fix + the kernel bug, I've added an AIX-specific option to lsof + that controls its use of the readx() function. + + By default lsof readx() use is disabled; specifying the + ``-X'' option enables readx() use. + + If you want to change the default readx() behavior of AIX + lsof, change the HASXOPT, HASXOPT_ROOT, and HASXOPT_VALUE + definitions in dialects/aix/machine.h. You can also use + these definitions to enable or disable readx() -- consult + the comments in machine.h. You may want to disable readx() + use permanently if you plan to make lsof publicly executable. + + When HASXOPT_ROOT is defined, lsof will restrict use of + the -X option to processes whose real UID is root; if + HASXOPT_ROOT isn't defined, any user may specify the -X + option. The Customize script offers the option to change + HASXOPT_ROOT when HASXOPT is defined and HASXOPT_ROOT is + named in any dialect's machine.h header file. + + I have never seen lsof cause a problem with its use of + readx(), but I believe there is some chance it could, given + the right circumstances. + +4.1.1 Stale Segment ID APAR + + Here are the details of the Stale Segment ID bug and IBM's + response, provided by Kevin Ruderman. + + AIX V3 + APAR=ix49183 + user process hangs forever in kernel due to file + system corruption + STAT=closed prs TID=tx2527 ISEV=2 SEV=2 + (A "closed prs" is one closed with a Permanent + ReStriction.) + RCOMP=575603001 aix v3 for rs/6 RREL=r320 + + AIX V4 (internal defect, no apar #) + prefix p + name 175671 + abstract KERMP: loop for ever in dir_search() + + Problem description: + + 1. Some user application -- e.g., lsof -- gets the segment + ID (SID) for the process private segment of a target + process from the process table. + + 2. The target process exits, deleting the process private + segment. + + 3. The SID is reallocated for use as a persistent segment. + + 4. The user application runs again and tries to read the + user area structure from /dev/mem, using the SID it read + from the process table. + + 5. The loads done by the driver for /dev/mem cause faults + in the directory; new blocks are allocated; the size + changed; and zero pages created. + + 6. The next application that looks for a file in the affected + directory hangs in the kernel's dir_search() function + because of the zero pages. This occurs because the + kernel's dir_search() function loops through the variable + length entries one at a time, moving from one to the + next by adding the length of the current entry to its + address to get the address of the next entry. This + process should end when the current pointer passes the + end of the known directory length. + + However, while the directory length has increased, the + entry length data has not, so when dir_search() reaches + the zero pages, it loops forever, adding a length of + zero to the current pointer, never passing the end of + the directory length. The application process is hung; + it can't be killed or stopped. + + IBM closed the problem with a PRS code (Permanent ReStriction) + under AIX Version 3 and had targeted a fix for AIX 4.2. They + have recently (I became aware of it September 10, 1996) + cancelled the defect report altogether and have indicated they + are not going to fix the defect. + +4.2 Gcc Work-around for AIX 4.1x + + When gcc is used to compile lsof for AIX 4.1x, it doesn't + align one element of the user structure correctly. Xlc + sees the U_irss element as a type "long long" and aligns + it on an 8 byte boundary. That's because the default mode + of xlc is -qlonglong; when -qlonglong is enabled, the + _LONG_LONG symbol is also defined. + + Gcc sees U_irss as a two element array of type long, because + _LONG_LONG isn't defined. Hence gcc aligns the U_irss + element array on a 4 byte boundary, rather than an 8 byte + one, making the gcc incantation of the user structure 4 + bytes shorter than xlc's. + + When the length of gcc's user structure is supplied as + argument 4 to the undocumented getuser() function of the + AIX kernel, getuser() rejects it as an incorrect size and + returns EINVAL. + + Lsof has a work-around for this problem. It involves a + special test in the Configure script when the "aixgcc" + Configure abbreviation is used -- e.g., + + $ Configure -n aixgcc + + The test is to compile a small program with gcc and check + the alignment of U_irss. If it's not aligned on an 8 byte + boundary, the Configure script makes a special copy of + in ./dialects/aix/aix 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 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 . + + 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 that was compiled into the lsof executable. + + On AIX 4.3.3 there are two different user structure + definitions in two separate 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 , 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 + will 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 for help. + Make sure "lsof" appears in the "Subject:" line so my e-mail + filter won't classify your letter as Spam. + +5.2.2 Why doesn't Apple Darwin lsof report text file information? + + At the first port of lsof to Apple Darwin, revision 4.53, + insufficient information was available -- logic and header + files -- to permit the installation of VM space scanning + for text files. As of lsof 4.70 it is sill not available. + + Text file support will be added to Apple Darwin lsof after + the necessary information becomes available. + +5.2.3 Why doesn't Apple Darwin lsof support IPv6? + + At the first port of lsof to Apple Darwin, revision 4.53, + Apple Darwin lacked IPv6 support. IPv6 became available + in Apple Darwin version 1.5 and support for it was added + to lsof then. + +5.2.4 Why does lsof complain about a mismatch between the release + for which lsof was compiled and the booted Mac OS X release? + + When lsof is started on the "Gold Master" Darwin release + (aka Mac OS X), it complains: + + lsof: compiled for 1.0 release; this is 1.3.2. + + This happens because the lsof binary released with Mac OS + X was built on a system whose release number (1.0) doesn't + match that of the released system -- usually 1.3.x Lsof + makes this check because UNIX dialect OS changes are often + accompanied by header file changes that affect lsof. + + In this specific case, this error can be ignored. If you + don't want to do that, get the lsof distribution and build + lsof so its built-on and running-on Mac OS X release numbers + match. + +5.2.5 Why does lsof for Apple Darwin 8 and higher report + "stat(...): ..." in the NAME column? + + Lsof for Apple Darwin 8 may report messages like these in the + NAME column: + + stat(/private/var/run/asl_prune): No such file or directory + or + stat(/private/var/db/netinfo/local.nidb/Config): Permission denied + + Those messages indicate that lsof was unable to collect open + file information for the paths enclosed in "stat(...)" with the + stat(2) function, because the function encountered the reported + error. + + A work-around for the "Permission denied" error is to run lsof + with elevated privileges -- e.g., when logged on as the super + user. + + If the stat(2) error message is "No such file or directory", + the file probably has been unlinked (removed) and there is no + lsof work-around. + +5.2.6 What are the limitations of Apple Darwin lsof link count + reporting? + + Lsof for Apple Darwin cannot report link count information + reliably. + + For Apple Darwin below 8 link count information is not always + available in the kernel node structures available to lsof. + When link count information is available, however, it includes + link counts of zero. Thus, using lsof's +L1 option may result + in the finding of some files whose link counts are zero. + + Lsof can report only some link count information for Apple + Darwin 8 and above. Link count information is only available + for files where lsof can assemble the full file path and has + permission to apply stat(2) to it. (See the answer to the "Why + does lsof for Apple Darwin 8 and higher report "stat(...): ..." + in the NAME column?" question for more information on stat(2) + failures.) + + Apple Darwin 8 and above files that have been unlinked and thus + have a link count of zero cannot be found by stat(2) -- i.e., + stat(2) returns a "No such file or directory" error. As a + result lsof never displays link counts of zero and the use of + lsof's +L1 option to find them always fails. + +5.2.7 Why does Apple Darwin report process group IDs incorrectly?" + + The kmem version of lsof for Apple Darwin does not report + process group IDs correctly when requested to do so with its + ``-g'' option. This is a bug that surfaced after the libproc + version was released and access to kmem test systems has + prevented patching the bug. + + If you are using the kmem version and would like a fix for this + problem, please send e-mail to me . Make sure + "lsof" appears in the "Subject:" line so my e-mail filter won't + classify your letter as Spam. + +5.3 Libproc-based Apple Darwin Questions + + +6.0 BSD/OS BSDI Problems + +6.0.5 Statement of deprecation + + As of lsof revision 4.76 support for BSDI BSD/OS has been + dropped. The 4.76 distribution of lsof for BSDI BSD/OS may be + found on lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src. + +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 . + 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 0 + # chmod 440 /dev/mem + # chgrp kmem /dev/mem + + For 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 and introduce a new structure, + lockf_entry, to that header file. When Configure detects the + presence of the lockf_entry definition in , 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 doesn't + contain the lockf_owner structure definition referenced in its + own lockf structure. Lsof needs to access elements of that + lockf_owner structure to determine if a lock belongs to the + process that has a file open. + + The missing lockf_owner structure definition is in the kernel + source file, typically /usr/src/sys/kern/kern_lockf.c. + Configure tries to extract the lockf_owner structure definition + from kern_lockf.c into lsof's local header file, ./lockf_owner.h. + If Configure can't do that, it reports: + + FATAL ERROR: ./lockf_owner.h creation failed + + If Configure can't even read kern_lockf.c, it first reports: + + FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c + + The work-around for this problem is to update the FreeBSD + kernel /usr/src tree (e.g., do a CVSup or csup) on the system + where lsof is to be built and then do a "make buildworld" + followed by a "make installworld". + +8.6.1 Why are there lockf structure compiler errors for FreeBSD 6.0 + and higher lsof? + + If, when compiling lsof, the compiler complains with error + messages like: + + dnode.c: In function 'get_lock_state': + dnode.c:113: error: 'struct lockf' has no member named 'lf_flags' + dnode.c:115: error: 'struct lockf' has no member named 'lf_id' + ... + + Then lsof is being built on a system that has new kernel file + locking code and lsof's Configure script failed to build a + local lockf_owner.h header file with a structure definition + lsof needs. + + See the "Why can't Configure create lsof_owner.h for FreeBSD 6 + and above?" section for more information and a work-around. + +8.6.2 Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h + match? + + This mismatch can cause the errors explained in the answer to + the "Why are there lockf structure compiler errors for FreeBSD + 6.0 and higher lsof?" question. + + If /usr/src/sys/sys/lockf.h has been updated with a CVSup or + csup, the new lockf.h won't be propagated to /usr/include/sys + until the "make buildworld" and "make installworld" steps have + been completed. + +8.7 FreeBSD and clang + + As of lsof revision 4.87, lsof may be compiled with clang. + +8.7.1 Why does clang complain about VOP_FSYNC? + + There is an error in the Solaris ZFS compatibility vnode.h + header file with use of VOP_FSYNC before it is defined. No + work-around is possible that will eliminate the clang + compile-time warning message about the invalid declaration of + the VOP_FSYNC function. + + +9.0 HP-UX Problems + +9.1 What do /dev/kmem-based and PSTAT-based mean? + + Lsof for HP-UX 11.0 and below uses /dev/kmem to read kernel + data structures from which it gathers and reports open file + information. That version of lsof is called /dev/kmem-based + lsof. + + Starting with HP-UX 10.10, finding definitions for the + necessary kernel structures became more difficult as HP no + longer distributed header files in /usr/include that defined + all kernel structures. So I started "inventing" structure + definitions by using Q4 to display them. + + By HP-UX 11, the process of invention became extremely + intensive to support. Following a patch to the ipc_s + structure in early 1999, my invented definition of that + structure became incorrect. Although I was able to devise + a work-around test for the patch with Q4, it was clear that + my inventions were bound to cause more problems. + + Discussion with HP about the patch led to my proposing that + an lsof API in the HP-UX kernel was the proper solution. + Much to my surprise, HP agreed. I believe Carl Davidson + was the prime mover behind that decision, but I know others + participated, among them Louis Huemiller, Rich Rauenzahn, + and Sailu Yallapragada. I am indebted to these folks and + HP for their willingness to do this work. + + The API was added to the PSTAT interface in a project named + PEGL, Pstat Enhancements for Glance and Lsof. Louis and + Sailu did the bulk of the design and implementation work + and testing began in March, 2000 + + HP-UX 11.11 is the first version that provides PSTAT support + for lsof. HP-UX versions in between 11.0 and 11.11 -- all + Beta versions as far as I can determine -- have no lsof + support. + + See the "PSTAT-based HP-UX lsof Questions" section for + questions and answers specific to PSTAT-based HP-UX lsof. + The next section, "Why doesn't a /dev/kmem-based HP-UX lsof + compilation use -O?" covers /dev/kmem-based HP-UX lsof. + + The /dev/kmem-based lsof sources may be found in the kmem + subdirectory of the dialects/hpux branch of the lsof source + tree. The PSTAT-based lsof sources may be found in + .../dialects/hpux/pstat. + +9.2 /dev/kmem-based HP-UX lsof Questions + + The sources for /dev/kmem-based lsof for HP-UX may be found + in lsof_/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 . 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 + 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 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., + + : 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 + 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 header file. + Sometimes it is missing from /usr/include/sys/fs. + + is a header file that must be obtained from + Veritas. If that proves impossible, please contact me via + e-mail at . 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_/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 bytes of pst_static + lsof: FATAL: pst_static doesn't contain _size + lsof: FATAL: _size should be + + These messages indicate that lsof's tests for the proper + level of PSTAT support have failed. The structure names, + given in , and sizes, given in , 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: / + + 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 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 . + + 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 ( 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//fd entry to the node numbers found in + selected files of the /proc/net sub-directory. Currently + /proc-based lsof examines these protocol files: + + /proc/net/ax25 (untested) + /proc/net/icmp + /proc/net/ipx (needs kernel patch) + /proc/net/netlink + /proc/net/packet + /proc/net/raw + /proc/net/raw6 + /proc/net/sctp/assocs + /proc/net/sctp/eps + /proc/net/sockstat + /proc/net/sockstat6 + /proc/net/tcp + /proc/net/tcp6 + /proc/net/udp + /proc/net/udp6 + /proc/net/udplite + /proc/net/udplite6 + /proc/net/unix + + If /proc-based lsof says it can't identify the protocol + for an open socket file, you may be able to identify the + protocol yourself by using grep to look for the specific + node number in the files of /proc/net -- e.g., + + $ grep /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 + . 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/ + + if the header line of the indicated 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 . + 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//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//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 /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//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//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 (or ) + 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//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//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/ directory, it reports a + single file of the type ``NOFD'' (for no file descriptors). + + Lsof reports the /proc//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/'' entry -- + e.g., it can't convert the entry to a full and more meaningful + path name, or it can't access the /proc//fd subdirectory + with opendir() -- it will report the /proc/ 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 + + The 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. + + +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 + 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 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 uses NBPG from + 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/openbsd/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 + #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 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 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 + , , , , + o, and 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 member of the comma-separated list -- a hexadecimal + integer. When "+fG" is specified (instead of "+fg"), lsof + will list all flag values as two hexadecimal integers, + separated by a semicolon. + + When "-FG" is specified to get the flags in an output field, + the format defaults to hexadecimal. You can get names + instead by following "-FG" with "+fg" -- e.g., + + $ lsof -FG +fg ... + + However, when you precede "-FG" with "+fg" -- e.g., + + $ lsof +fg -FG + + the format will be hexadecimal; order is important. + +14.3.1 Why doesn't lsof display FILE_FLAG values for my dialect? + + All versions of lsof except the /proc-based Linux lsof + report FILE-FLAG values. Lsof can't obtain FILE-FLAG + information from the Linux /proc interface. + +14.4 Network Addresses + +14.4.1 Why does lsof's -n option cause IPv4 addresses, mapped to + IPv6, to be displayed in IPv6 notation? + + When you use the -n option to tell lsof to display numeric + network addresses, and an IPv4 address has been mapped to + IPv6, lsof displays the address in IPv6 format and puts + "ipv4" in the TYPE column. That combination indicates the + IPv4 address has been mapped to IPv6. + + For example, the IPv4 address 1.2.3.4, when mapped to an + IPv6 address, will be displayed by lsof as: + + [::ffff:1.2.3.4] + + The enclosing brackets are lsof's signal that this is an + IPv6 address. Inside the brackets is a standard IPv6 + address, reported by inet_ntop(). The first two colons, + signifying zeroes in the first 64 bits of the IPv6 address, + and the hexadecimal ffff in the next 32 bits, indicate that + the last 32 bits contains a mapped IPv4 address, which is + then displayed in IPv4 dot notation. + +14.5 Why does lsof output \x, ^x, or \xnn for characters + sometimes? + + Lsof displays only printable ASCII characters. Lsof + considers a character printable if isprint(3) says it + is. If isprint(3) says a character isn't printable, + the lsof may page explains: + + "... Non-printable characters are printed in one of + three forms: the C ``\[bfrnt]'' form; the control + character `^' form (e.g., ``^@''); or hexadecimal + leading ``\x'' form (e.g., ``\xab''). Space is + non-printable in the COMMAND column (``\x20'') and + printable elsewhere." + +14.5.1 Why is space considered a non-printable character in command + names? + + Space is considered an unprintable character in command + names because it is sometimes possible to hide the full + command name from scripts that parse ps(1) output by + embedding a space in the name. + +14.6 Why doesn't lsof print all the characters of a command name? + + By default lsof prints the first nine characters of the + names of commands associated with processes. If more + characters are required, the "w" value of the "+c w" option + may be used to specify a larger width. + + If "w" is zero ('0') lsof will print all characters of all + command names up to the limit of the number of characters + supplied by the particular UNIX dialect. When reporting + command names, lsof replaces non-printable characters as + discussed in the answer to " Why does lsof output \x, ^x, or + \xnn for characters sometimes?" + + See the answer to the "Why is space considered a non-printable + character in command names?" question for an explanation of why + spaces are replaced by the ``\x20'' representation in command + names. + + The number of command name characters supplied to lsof by UNIX + dialects in files and structures varies by dialect. For + example, Linux 2.4.27 supplies lsof the first 15 characters of + command names and Solaris 9 supplies 16. Thus, even if "w" is + zero ('0'), lsof can't report more characters for command names + on those two UNIX dialects than they provide lsof. + +14.7 Why does lsof reject some -c command names, saying their lengths + are "> what system provides (nn)"? + + The command name length that a specific system provides varies + from dialect to dialect. As noted in the answer to the "Why + doesn't lsof print all the characters of a command name?" + question, Linux and Solaris provide a limited number of command + name characters. + + When more characters are specified in the parameter to the -c + option, lsof considers it an error and issues a fatal error + message -- e.g., + + lsof: "-c xxxxyyyy" length (8) > what system provides (7) + + The only work-around is to specify no more characters to -c + that the system provides to lsof. + +14.8 Why does lsof sometimes print TYPE numbers instead of names? + + When lsof can't convert a type number to a name for printing in + the TYPE column, it will report the number as four octets. + +14.9 Marker line format problems + +14.9.1 Why won't lsof accept a marker line format? + + Lsof's Configure script must find the localtime(3) and + strftime(3) functions in the dialect's C library in order to + enable support for marker line formats. + + Check the output of lsof's -v option for the presence of + -DHAS_STRFTIME in the compiler flags. If it isn't there, + Configure didn't find the necessary two C library functions. + + If you think lsof should have found the functions, make a copy + of the C test program in the Configure script that it uses to + find the functions. Then use the copy, or a more informative + modification of it, to learn why Configure can't find the + functions. You can find that program by searching for + strftime. + +14.9.2 Why does lsof reject the NL (%n) marker line format? + + When repeat mode and field output (with -F) have both been + specified, lsof won't allow new line (NL) formats to be + specified with ``%n''. That's because the marker line is + always guaranteed to be a single line. + + There is no work-around to this restriction. + +14.10 How are protocol state name exclusion and inclusion used? + + Protocol state name inclusion and exclusion with the ``-s p:s'' + option and its arguments have some issues to consider. Note: + the ``-s p:s'' option is only available when the help output, + obtained with -h or -?, shows it; it was a recent addition to + lsof and is supported only on dialects where it could be + tested. + + First, there is the problem of determining what state names, if + any, the dialect produces. Try running this lsof command to + find them: + + $ lsof -i + + Knowing the state names of interest, the next problem is to + decide on the lsof options and their parameters that will + produce the desired output. Here some examples are probably + the most useful. + + To list only TCP socket files in LISTEN and CLOSE_WAIT states, + use: + + $ lsof -itcp -stcp:listen,close_wait + or + $ lsof -iTCP -sTCP:LISTEN,CLOSE_WAIT + + Case isn't important to lsof in protocol and state names. + + To exclude TCP socket files in CLOSE_WAIT state, use: + + $ lsof -itcp -stcp:^close_wait + + Note the `^' preceding close_wait; it selects exclusion. You + can mix included and excluded names in a comma separated list, + but you may not include and exclude the same name for the same + protocol. + + To list TCP files in LISTEN state and UDP files in Idle state, + use: + + $ lsof -i -stcp:listen -sudp:idle + + Note: if you don't accompany the ``-s p:s'' list option and + argguments with the -i option, lsof will list all other regular + files, while applying the specified inclusion and exclusion + specifications to network files. Generally, then, you want to + use -i with -s. + +14.10.1 Why doesn't my dialect support state name exclusion and inclusion? + + When state name inclusion and exclusion was added, I had access + to test systems for AIX, Darwin, FreeBSD, Linux, PSTAT-based + HP-UX and Solaris. + + Therefore, I was unable to add and test the support to any other + UNIX dialects. + + If a dialect has the support, then the HASTCPUDPSTATE definition + in its machine.h header file will be active; if not, it will be + absent or commented out. + + If your dialect doesn't have the support and you want it added, + you will have to provide me Internet access to a test host, where + I can compile lsof and have the credentials to test the changes + the support requires. If that's possible for you, please contact + me via e-mail at . 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 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 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 . 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 . + 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(): + + 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 | 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 + + It means that lsof can't find the booted kernel image file + at . 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 " 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: + + + + + + + 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 . 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 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 header file whose NUM_*_VECTORS + definitions don't match the ones in the updated + by Solaris patch 102303-02. + + NUM_*_VECTORS in the kernel of patch 101945-32 are smaller + than the ones in the of patch 102303-02. The + consequence is that when lsof is compiled with the + 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//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 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 + or + mkfs -m + or + vxupgrade + + 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 . Make sure "lsof" appears in the + "Subject:" line so my e-mail filter won't classify your letter + as Spam. + +17.23.2 Why can't lsof locate named SAM-GS files? + + Solaris lsof 4.68 and above can't locate files on SAM-FS + file systems when the files are named as lsof arguments + because lsof doesn't know how to locate open SAM-FS file + device and node number information. (See also 'Why does + Solaris lsof report "(limited SAM-FS info)?') + +17.24 Lsof and Solaris 10 zones + +17.24.1 How can I make lsof list the Solaris zone? + + Use the lsof "-z [z]" option. + +17.24.2 Why doesn't lsof work in a Solaris 10 zone? + + When run from within a Solaris 10 zone, lsof will usually + report: + + lsof: can't stat(/devices): No such file or directory + + That's because a Solaris zone usually has no /devices + subdirectory, a restriction of the zone implementation intended + to limit the ability of zone processes to control global system + resources, including physical devices. + + While a zone may have a /dev subdirectory, that subdirectory + usually lacks the /dev/allkmem, /dev/mem and /dev/kmem devices + lsof and the KVM library it uses require. + + The work-around is to run lsof in the global zone. When it is + run in a global zone lsof will be able to report on processes + running in any zone, including the global zone. + +17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file + systems? + + When run from the global zone on Solaris 10 lsof may complain: + + lsof: WARNING: can't stat() 15 zone file systems; + using dev= options + + The warning message means lsof found the reported number of + file system entries in the mount table for which it didn't have + permission to get stat(2) results, but which had "zone=" and + "dev=" mount table options. + + That is a normal restriction of Solaris 10 zones. Since the + lsof warning message indicates it was able to find "dev=" + options for the file systems, lsof will probably work + correctly. + + One work-around is to relax the restrictions on zone mount + points, so that lsof can stat() them. While that may be + possible by changing directory modes or group ownerships, it is + probably not a good idea, because it weakens the restrictions + zones are intended to provide. + + Another work-around is to suppress the warning message with + lsof's "-w" option. The down side of that is that it causes + the suppression of all warning messages, leading to the + possibility that some non-stat() warning messages will be + suppressed. + +17.25 Solaris 10 problems + +17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name? + + When a path name component is renamed -- e.g., with mv(1) -- + Solaris 10 lsof may report the old component for an open file + that used the component in its path before the rename. That's + because Solaris 10 lsof reports the path name cached in the + open file's vnode and the Solaris 10 kernel doesn't update the + open vnode's cached path name when a component of it is changed. + + When an open file is deleted -- e.g., with rm(1) -- the path + name by which it was opened remains cached in the vnode. Lsof + can be instructed to display that path name with the -X option. + The path name might be incorrect because of the rename problem + described above. See the answer to the 'What does "(deleted)" + mean in the NAME column of a Solaris 10 open file?' question + for more information. + + Lsof is sometimes able to detect that cached path name is + incorrect. In that case lsof may report only the mounted-on + directory and device of the file system or it may report that + the path name is of questionable accuracy by appending a + trailing "(?)" to it in the NAME column. + + See the answer to the "Why does Solaris 10 lsof sometimes + report only the mounted-on directory and device?" and 'What + does "(?)" mean in the NAME column of a Solaris 10 open file?' + questions for more information. + +17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on + directory and device? + + For some regular open files lsof may report only the mounted-on + directory and device of the file system on which the file + resides. That's because lsof was able to determine that the + path name cached in the open file's vnode is incorrect. + + Lsof detects the cached path name is incorrect by applying + stat(2) to it, provided that no error was detected when stat(2) + was applied to the file system mounted-on directory during lsof + setup. If a mounted-on directory stat(2) error was detected + during setup, lsof does no cached path name analysis and simply + reports it. + + When the application of stat(2) to the cached path name returns + a no-entry reply (the ENOENT error number), lsof concludes the + path no longer exists (i.e., has been unlinked) and reports the + mounted-on directory and device of the file system. That + behavior can be modified with the -X option in lsof revisions + 4.77 and above. See the answer to the 'What does "(deleted)" + mean in the NAME column of a Solaris 10 open file?' for more + information. + + When the application of stat(2) to the cached path name returns + a permission error reply (the EACCES or EPERM error numbers), + lsof reports the cached path name and adds a trailing "(?)" to + indicate the reported path name is of questionable accuracy. + See the answer to the question 'What does "(?)" mean in the + NAME column of a Solaris 10 open file?' for more information. + + If the application of stat(2) to the cached path name yields + any other error reply, lsof reports the mounted-on directory + and device of the file system. + + When the application of stat(2) to the cached path name + succeeds, lsof compares the reported device and node numbers to + what it has obtained for the open file from kernel structures. + If they match, lsof reports the cached path name. If they + don't match, lsof instead reports the mounted-on directory and + device of the file system. + + A work-around that allows lsof to apply stat(2) successfully to + cached path names is to give lsof sufficient permission to do + it -- i.e., run lsof as the root user. + +17.25.3 What does "(deleted)" mean in the NAME column of a Solaris 10 + open file? + + When the -X option is specified to Solaris 10 lsof, it will + report in its NAME column the path name cached for a deleted + file in its vnode. The path name will be followed by + "(deleted)". + + Note that the path name cached in a file's vnode is the path + name by which the file was opened. It is not updated by the + Solaris kernel when any path name component is changed. Hence, + it may not represent the final path name the open file had. + + See the answer to the "Why does Solaris 10 lsof sometimes + report the wrong path name?" question for more information on + how changing a path name component affects the correctness of a + what lsof reports. + +17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open + file? + + When lsof encounters a path name cached in the open file's + vnode that stat(2) reports lsof lacks permission to access, + lsof adds "(?)" to the path name reported in the NAME column to + indicate the path name is of questionable accuracy. + + See the answers to the "Why does Solaris 10 lsof sometimes + report the wrong path name?" and "Why does Solaris 10 lsof + sometimes report only the mounted-on directory and device?" + questions for more information on why lsof may report a path + name of questionable accuracy. + + A work-around that allows lsof to apply stat(2) successfully to + cached path names is to give lsof sufficient permission to do + it -- i.e., run lsof as the root user. + +17.26 Solaris contract file problems + +17.26.1 Why doesn't lsof report size, link count and node number for + Solaris 10 contract files? + + Lsof doesn't report size, link count or node number for Solaris + 10 contract files because I don't know how to obtain them from + contract file kernel structures. + +17.26.2 Why can't lsof locate a Solaris 10 contract file by path name? + + Because lsof can't find the node number of Solaris contract + files, it can't match the device and node numbers it gets from + applying stat(2) to the contract file path name with what it + finds in kernel data. + +17.27 Solaris 10 and above ZFS problems + +17.27.1 Why does Configure warn that ZFS support is not enabled? + + To provide ZFS support it is necessary that lsof have access to + the definitions of ZFS structures used by the kernel. Those + definitions are made available to lsof when it runs by the + libctl library. + + If lsof's Configure script finds that ZFS is indicated by the + presence of the header file, but the libctl + library is not indicated via the header file, the + script concludes that ZFS support is not possible and issues + the following warning: + + WARNING: ZFS support not enabled; libctf.h missing. + + Install libctf support to remedy this problem. + + +17.28 Problems with Solaris 9 and above + +17.28.1 Why does the compiler complain about lgrp_root on Solaris 9 + and above? + + When compiling lsof 4.84 on later Solaris 9 and 10 systems, the + compiler may report the following error: + + /usr/include/sys/lgrp.h", line ...: identifier redeclared: lgrp_root + + This error results from a conflict between usage of lgrp_root + in both and when _KMEMUSER or + _KERNEL is #define'd before 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 + its behavior? + + To disable the device cache file feature for a dialect, + remove the HASDCACHE definition from the machine.h file of + the dialect's machine.h header file. You can also use + HASDCACHE to change the default prefix (``.lsof'') of the + device cache file. + + Be sure you consider disabling the device cache file feature + carefully. Having a device cache file significantly reduces + lsof startup overhead by eliminating a full scan of /dev + (or /devices) once the device cache file has been created. + That full scan also overloads the kernel's name cache with + the names of the /dev (or /devices) nodes, reducing the + opportunity for lsof to find path name components of open + files. + + If you're worried about the presence of mode 0600 device + cache files in the home directories of the real user IDs + that execute lsof, consider these checks that lsof makes + on the file before using it: + + 1. To read the device cache file, lsof must gain + permission from access(2). + + 2. The device cache file's modes must be 0600 (0644 + if lsof is reading a system-wide device cache file) + and its size non-zero. + + 3. There must be a correctly formatted section count + line at the beginning of the file. + + 4. Each section must have a header line with a count + that properly numbers the lines in the section. + Legal sections are device, clone, pseudo-device, + and CRC. + + 5. The lines of a section must have the proper format. + + 6. All lines are included in a 16 bit CRC, and it is + recorded in a non-checksummed section line at the + end of the file. + + 7. The checksum computed when the file is read must + match the checksum recorded when the file was + written. + + 8. The checksum section line must be followed by + end-of-information. + + 9. Lsof must be able to get matching results from + stat(2) on a randomly chosen entry of the device + section. + + For more information on the device cache file, read the + 00DCACHE file of the lsof distribution. + +18.2.1 What's the risk with a perverted device cache file? + + Even with the checks that lsof makes on the device cache + file, it's conceivable that an intruder could modify it so + it would pass lsof's tests. + + The only serious consequence I know of this change is the + removal of a file whose major device number identifies a + socket from some user ID's device cache file. When such + a device has been removed from the device cache file, and + when lsof doesn't detect the removal, lsof may not be able + to identify socket files when executed by the affected user + ID. Only certain dialects are at risk to this attack -- + e.g., SCO OpenServer and Solaris 2.x, 7, 8, and 9. + + If you're tracking a network intruder with lsof, that could + be important to you. If you suspect that someone has + corrupted the device cache file you're using, I recommend + you use lsof's -Di option to tell it to ignore it and use + the contents of /dev (or /devices) instead; or remove the + device cache file (usually .lsof_hostname, where hostname + is the first component of the host's name returned by + gethostname(2)) from the user ID's home directory and let + lsof create a new one for you. + +18.2.2 How do I put the full host name in a personal device cache file + path? + + Lsof constructs the personal device cache file path name + from a format specified in the HASPERSDC #define in the + dialect's machine.h header file. As distributed HASPERSDC + declares the path to be ``.lsof_'' plus the first component + of the host name with the format ``.lsof_%L''. + + If you want to change the way lsof constructs the personal + device cache file path name, you can change the HASPERSDC + #define and recompile lsof. If, for example, you #define + HASPERSDC to be ``.lsof_%l'' (note the lower case `l'), + Configure and remake lsof, then the personal device cache + file path will be ``.lsof_'' plus the host name returned + by gethostname(2). + + See the 00DCACHE file of the lsof distribution for more + information on the formation of the personal device cache + file path and the use of the HASPERSDC #define. + +18.2.3 How do I put the personal device cache file in /tmp? + + Change the HASPERSDC definition in your dialect's machine.h + header file. + + When you redefine HASPERSDC, make sure you put at least + one user identification conversion in it to keep separate + the device cache files for each user of lsof. Also give + some thought to including the ``%0'' conversion to define + an alternate path for setuid-root and root processes. + + Here's a definition that puts a personal device cache file + in /tmp with the name ``.lsof_login_hostname_pers''. + + #define HASPERSDC "/tmp/.lsof_%u_%l_pers" + + Thus the /tmp personal device cache file path for login + "abe" on host "lsof.itap.purdue.edu" would be: + + /tmp/.lsof_abe_lsof.itap.purdue.edu_pers + + You can add the User ID (UID) with the "%U" conversion and + the first host name component with the ``%L'' conversion. + + CAUTION: be careful using absolute paths like /tmp lest + lsof processes that are setuid-root or whose real UID is + root be used to exploit some security weakness via /tmp. + Elect instead to add an alternate path for those processes + with the ``%0'' conversion. Here's an extension of the + previous HASPERSDC format for /tmp that declares an alternate + path: + + #define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L" + + When the lsof process is setuid-root or its real UID is + root, presuming root's home directory is `/' and the host's + name is ``lsof.itap.purdue.edu'', the extended format yields: + + /.lsof_vic + +18.3 Why doesn't lsof know about AFS files on my favorite dialect? + + Lsof currently supports AFS for these dialects: + + AIX 4.1.4 (AFS 3.4a) + Linux 1.2.13 (AFS 3.3) + Solaris 2.[56] (AFS 3.4a) + + It may recognize AFS files on other versions of these + dialects, but I have no way to test that. Lsof may report + correct information for AFS files on other dialects, but + I can't test that either. + + AFS support must be custom crafted for each UNIX dialect + and then tested. If lsof supports your favorite dialect, + but doesn't recognize its AFS files, probably I don't have + access to a test system. If you want AFS support badly + for your dialect, consider helping me do the development + and testing. + +18.3.1 Why doesn't lsof report node numbers for all AFS volume files, + or how do I reveal dynamic module addresses to lsof? + + When AFS is implemented via dynamic kernel modules -- e.g., + in NEXTSTEP -- lsof can't obtain the addresses of AFS + variables in the kernel that it uses to identify AFS vnodes. + It can guess that a vnode is assigned to an AFS file and + it can obtain other information about AFS files, but it + has trouble computing AFS volume node numbers. + + To determine node numbers for AFS volumes other than the + root volume, /afs, lsof needs access to a hashed volume + structure pointer table. When it can't find the address + of that table, because AFS support is implemented via + dynamic kernel modules, lsof will return blanks in the + INODE column for AFS volume files. Lsof can identify the + root volume's node number (0), and can compute the node + numbers for all other AFS files. + + If you have a name list file that contains the addresses + of the AFS dynamic modules -- e.g., you saved module symbols + when you created a loadable module kernel with modload(8) + by specifying -sym -- lsof may be able to find the kernel + addresses it needs in that file. + + Lsof looks up AFS dynamic kernel addresses for these dialects + at these default paths: + + NEXTSTEP 3.2 /usr/vice/etc/afs_loadable + + A different path to a name list file with AFS dynamic kernel + addresses may be specified with the -A option, when the -A + option description appears in lsof's -h or -? (help) output. + + If any addresses appear in the -A name list file that also + appear in the regular kernel name list file -- e.g., /vmunix + -- they must match, or lsof will silently ignore the -A + addresses on the presumption that they are out of date. diff --git a/00LSOF-L b/00LSOF-L new file mode 100644 index 0000000..4f2603a --- /dev/null +++ b/00LSOF-L @@ -0,0 +1,99 @@ + + The Lsof Mailing List, lsof-l + +Information on lsof is available via a GNU Mailman mailing list, named +lsof-l. The server is located on the host lists.purdue.edu. + + +Subscribing +=========== + +You may subscribe to the lsof-l mailing list by sending e-mail to: + + lsof-l-subscribe@lists.purdue.edu + +The body of your e-mail may be empty. You will receive a confirmation +reply, explaining one further step you must take to complete your +subscription. + +The list manager uses the e-mail address and real name in the "From:" +line of your request to set those values in your subscription. If you +want different values in your subscription, consult the Mailman help +information to learn how to specify them on your subscription request. +(See the next "Get Help" section on how to obtain Mailman help +information.) + + +Get Help +======== + +More information about the lists.purdue.edu GNU Mailman server is +available by sending e-mail to lsof-l-request@lists.purdue.edu with +"help" in the subject line. The body of your e-mail may be empty. + +The other information will be delivered by return e-mail. + +You can also obtain information on the Mailman e-mail commands in +section 3.2 of the GNU Mailman documentation at: + + http://www.gnu.org/software/mailman/mailman-member/mailman-member.html + + +The Web Interface +================= + +There is a web interface at: + + https://lists.purdue.edu/mailman/listinfo/lsof-l + +You can use it to manage your lsof-l list entry. + + +Posting and Moderation +====================== + +Once you have subscribed to lsof-l (and have an e-mail confirmation +that your subscription was accepted), you may post messages to the list +by sending e-mail directly to: + + lsof-l@lists.purdue.edu + +I moderate the lsof-l mailing list and try to keep its traffic low, +mainly limiting it to announcements of new revisions, patches and +security issues. Postings don't appear until I've approved them. + + +Send Bug Reports to lsof-l, too +=============================== + +Since I am no longer actively supporting lsof -- 4.91 is probably the +last revision I will distribute -- bug reports should be sent to +lsof-l. There are readers of lsof-l who may be able to help you. + + +Unsubscribing +============= + +You can unsubscribe from lsof-l by sending e-mail to: + + lsof-l-unsubscribe@lists.purdue.edu + +The body of your e-mail may be empty. You will receive a confirmation +reply, explaining one further step you must take to complete the +removal of your subscription. + + +Archive +======= + +There is an archive; use the link: + + https://lists.purdue.edu/mailman/private/lsof-l + +The archive link is the first one on the web page. You will need the +password you received or set when you subscribed, or later set via +lsof-l-request or the web interface. + + +Vic Abell +March ??? 2018 diff --git a/00MANIFEST b/00MANIFEST new file mode 100644 index 0000000..951b93f --- /dev/null +++ b/00MANIFEST @@ -0,0 +1,343 @@ +.: +00.README.FIRST +00CREDITS +00DCACHE +00DIALECTS +00DIST +00FAQ +00LSOF-L +00MANIFEST +00PORTING +00QUICKSTART +00README +00TEST +00XCONFIG +AFSConfig* +ChangeLog +Configure* +Customize* +Inventory* +arg.c +dialects/ +lib/ +lsof.8 +common.h +lsof.man +lsof_fields.h +main.c +misc.c +node.c +print.c +proc.c +proto.h +scripts/ +store.c +tests/ +usage.c +util.c +version + +./dialects: +aix/ +darwin/ +du/ +freebsd/ +hpux/ +linux/ +netbsd/ +n+os/ +openbsd/ +osr/ +sun/ +uw/ + +./dialects/aix: +Makefile +Mksrc* +aix5/ +ddev.c +dfile.c +dlsof.h +dmnt.c +dnode.c +dnode1.c +dnode2.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/aix/aix5: +README +j2/ + +./dialects/aix/aix5/j2: +j2_lock.h +private_j2_snapshot.h + +./dialects/darwin: +Makefile +Mksrc* +ddev.c +dfile.c +dlsof.h +dmnt.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/du: +Makefile +Mksrc* +ddev.c +dfile.c +dlsof.h +dmnt.c +dnode.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/freebsd: +Makefile +Makefile.zfs +Mksrc* +dlsof.h +dmnt.c +dnode.c +dnode1.c +dnode2.c +dproc.c +dproto.h +dsock.c +dstore.c +dzfs.h +include/ +machine.h + +./dialects/freebsd/include: +procfs/ + +./dialects/freebsd/include/procfs: +pfsnode.h + +./dialects/hpux: +kmem/ +pstat/ + +./dialects/hpux/kmem: +Makefile +Mksrc* +dfile.c +dlsof.h +dmnt.c +dnode.c +dnode1.c +dnode2.c +dproc.c +dproto.h +dsock.c +dstore.c +hpux11/ +machine.h + +./dialects/hpux/kmem/hpux11: +ipc_s.h +kernbits.h +lla.h +nfs_clnt.h +proc.h +rnode.h +sth.h +tcp_s.h +udp_s.h +vnode.h + +./dialects/hpux/pstat: +Makefile +Mksrc* +dfile.c +dlsof.h +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/linux: +Makefile +Mksrc* +dfile.c +dlsof.h +dmnt.c +dnode.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/netbsd: +Makefile +Mksrc* +dlsof.h +dmnt.c +dnode.c +dnode1.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/n+os: +Makefile +Mksrc* +dlsof.h +dnode.c +dnode1.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h + +./dialects/osr: +Makefile +Mksrc* +dfile.c +dlsof.h +dmnt.c +dnode.c +dproc.c +dproto.h +dsock.c +dstore.c +include/ +machine.h + +./dialects/osr/include: +netdb.h +sys/ + +./dialects/osr/include/sys: +cdefs.h + +./dialects/sun: +Makefile +Mksrc* +ddev.c +dfile.c +dlsof.h +dmnt.c +dnode.c +dnode1.c +dnode2.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h +solaris_kaddr_filters + +./dialects/uw: +Makefile +Mksrc* +dfile.c +dlsof.h +dmnt.c +dnode.c +dnode1.c +dnode2.c +dnode3.c +dproc.c +dproto.h +dsock.c +dstore.c +machine.h +uw7/ + +./dialects/uw/uw7: +README +fs/ +sys/ +vm/ + +./dialects/uw/uw7/fs: +nsc_cfs/ +procfs/ + +./dialects/uw/uw7/fs/nsc_cfs: +cnode.h + +./dialects/uw/uw7/fs/procfs: +README +prdata.h + +./dialects/uw/uw7/sys: +fs/ + +./dialects/uw/uw7/sys/fs: +README +fifonode.h +namenode.h + +./dialects/uw/uw7/vm: + +./lib: +Makefile.skel +ckkv.c +cvfs.c +dvch.c +fino.c +isfn.c +lkud.c +pdvn.c +prfp.c +ptti.c +rdev.c +rmnt.c +rnam.c +rnch.c +rnmh.c +snpf.c + +./scripts: +00MANIFEST +00README +big_brother.perl5* +count_pf.perl* +count_pf.perl5* +identd.perl5* +idrlogin.perl* +idrlogin.perl5* +list_NULf.perl5* +list_fields.awk +list_fields.perl* +shared.perl5* +sort_res.perl5* +watch_a_file.perl* +xusers.awk* + +./tests: +00README +Add2TestDB* +CkTestDB* +LTbasic.c +LTbigf.c +LTdnlc.c +LTlib.c +LTlock.c +LTnfs.c +LTnlink.c +LTsock.c +LTszoff.c +LTunix.c +LsofTest.h +Makefile +TestDB diff --git a/00PORTING b/00PORTING new file mode 100644 index 0000000..8563fcf --- /dev/null +++ b/00PORTING @@ -0,0 +1,1793 @@ + + Guide to Porting lsof 4 to Unix OS Dialects + +********************************************************************** +| The latest release of lsof is always available via anonymous ftp | +| from lsof.itap.purdue.edu. Look in pub/lsof.README for its | +| location. | +********************************************************************** + + Contents + + How Lsof Works + /proc-based Linux Lsof -- a Different Approach + General Guidelines + Organization + Source File Naming Conventions + Coding Philosophies + Data Requirements + Dlsof.h and #include's + Definitions That Affect Compilation + Options: Common and Special + Defining Dialect-Specific Symbols and Global Storage + Coding Dialect-specific Functions + Function Prototype Definitions and the _PROTOTYPE Macro + The Makefile + The Mksrc Shell Script + The MkKernOpts Shell Script + Testing and the lsof Test Suite + Where Next? + + +How Lsof Works +-------------- + +Before getting on with porting guidelines, just a word or two about +how lsof works. + +Lsof obtains data about open UNIX dialect files by reading the +kernel's proc structure information, following it to the related +user structure, then reading the open file structures stored +(usually) in the user structure. Typically lsof uses the kernel +memory devices, /dev/kmem, /dev/mem, etc. to read kernel data. + +Lsof stores information from the proc and user structures in an +internal, local proc structure table. It then processes the open +file structures by reading the file system nodes that lie behind +them, extracting and storing relevant data in internal local file +structures that are linked to the internal local process structure. + +Once all data has been gathered, lsof reports it from its internal, +local tables. + +There are a few variants on this subject. Some systems don't have +just proc structures, but have task structures, too, (e.g., NeXTSTEP +and OSF/1 derivatives). For some dialects lsof gets proc structures +or process information (See "/proc-based Linux Lsof -- a Different +Approach) from files of the /proc file system. It's not necessary +for lsof to read user structures on some systems (recent versions +of HP-UX), because the data lsof needs can be found in the task or +proc structures. In the end lsof gathers the same data, just from +slightly different sources. + + +/proc-based Linux Lsof -- a Different Approach +============================================== + +For a completely different approach to lsof construction, take a +look at the /proc-based Linux sources in .../dialects/linux/proc. +(The sources in .../dialects/linux/kmem are for a traditional lsof +that uses /dev/kmem to read information from kernel structures.) + +The /proc-based lsof obtains all its information from the Linux +/proc file system. Consequently, it is relatively immune to changes +in Linux kernel structures and doesn't need to be re-compiled each +time the Linux kernel version changes. + +There are some down-sides to the Linux /proc-based lsof: + + * It must run setuid-root in order to be able to read the + /proc file system branches for all processes. In contrast, + the /dev/kmem-based Linux lsof usually needs only setgid + permission. + + * It depends on the exact character format of /proc files, so + it is sensitive to changes in /proc file composition. + + * It is limited to the information a /proc file system + implementor decides to provide. For example, if a + /proc/net/ file lacks an inode number, the + /proc-based lsof can't connect open socket files to that + protocol. Another deficiency is that the /proc-based may + not be able to report file offset (position) information, + when it isn't available in the /proc//fd/ entry for a + file. + + In contrast the /dev/kmem-based lsof has full access to + kernel structures and "sees" new data as soon as it appears. + Of course, that new data requires that lsof be recompiled + and usually also requires changes to lsof. + +Overall the switch from a /dev/kmem base to a /proc one is an +advantage to Linux lsof. The switch was made at lsof revision 4.23 +for Linux kernel versions 2.1.72 (approximately) and higher. The +reason I'm not certain at which Linux kernel version a /proc-based +lsof becomes possible is that the /proc additions needed to implement +it have been added gradually to Linux 2.1.x in ways that I cannot +measure. + +/proc-based lsof functions in many ways the same as /dev/kmem-based +lsof. It scans the /proc directory, looking for / subdirectories. +Inside each one it collects process-related data from the cwd, exe, +maps, root, and stat information files. + +It collects open file information from the fd/ subdirectory of each +/ subdirectory. The lstat(2), readlink(2), and stat(2) system +calls gather information about the files from the kernel. + +Lock information comes from /proc/locks. It is matched to open +files by inode number. Mount information comes from /proc/mounts. +Per domain protocol information comes from the files of /proc/net; +it's matched to open socket files by inode number. + +The Linux /proc file system implementors have done an amazing job +of providing the information lsof needs. The /proc-based lsof +project has so far generated only two kernel modification: + + * A modification to /usr/src/linux/net/ipx/af_ipx.c adds the + inode number to the entries of /proc/net/ipx. + + Jonathan Sergent did this kernel modification. + + It may be found in the .../dialects/linux/proc/patches + subdirectory of the lsof distribution. + + * An experimental modification to /usr/src/linux/fs/stat.c + allows lstat(2) to return file position information for + /proc//fd/ files. + + Contact me for this modification. + + +One final note about the /proc-based Linux lsof: it doesn't need +any functions from the lsof library in the lib/ subdirectory. + +FreeBSD is now also using a similar approach. Sysctls are used +to retrieve processes, files, socket PCBs etc. Access to kernel +memory is optional and only used as a last resort when data is +not provided by the kernel. + + +General Guidelines +------------------ + +These are the general guidelines for porting lsof 4 to a new Unix +dialect: + + * Understand the organization of the lsof sources and the + philosophies that guide their coding. + + * Understand the data requirements and determine the methods + of locating the necessary data in the new dialect's kernel. + + * Pick a name for the subdirectory in lsof4/dialects for your + dialect. Generally I use a vendor operating system name + abbreviation. + + * Locate the necessary header files and #include them in the + dialect's dlsof.h file. (You may not be able to complete + this step until you have coded all dialect-specific functions.) + + * Determine the optional library functions of lsof to be used + and set their definitions in the dialect's machine.h file. + + * Define the dialect's specific symbols and global storage + in the dialect's dlsof.h and dstore.c files. + + * Code the dialect-specific functions in the appropriate + source files of the dialect's subdirectory. + + Include the necessary prototype definitions of the dialect- + specific functions in the dproto.h file in the dialect's + subdirectory. + + * Define the dialect's Makefile and source construction shell + script, Mksrc. + + * If there are #define's that affect how kernel structures + are organized, and those #define's are needed when compiling + lsof, build a MkKernOpts shell script to locate the #define's + and supply them to the Configure shell script. + + +Organization +------------ + +The code in a dialect-specific version of lsof comes from three +sources: + + 1) functions common to all versions, located in the top level + directory, lsof4; + + 2) functions specific to the dialect, located in the dialect's + subdirectory -- e.g., lsof4/dialects/sun; + + 3) functions that are common to several dialects, although + not to all, organized in a library, liblsof.a. The functions + in the library source can be selected and customized with + definitions in the dialect machine.h header files. + +The tree looks like this: + + lsof4 ----------------------+ 3) library -- + | \ lsof4/lib + 1) fully common functions + \ + e.g., lsof4/main.c + lsof4/dialects/ + / / / / \ + + + + + + + 2) dialect-specific subdirectories -- e.g., lsof4/dialects/sun + +The code for a dialect-specific version is constructed from these +three sources by the Configure shell script in the top level lsof4 +directory and definitions in the dialect machine.h header files. +Configure uses the Mksrc shell script in each dialect's subdirectory, +and may use an optional MkKernOpts shell script in selected dialect +subdirectories. + +Configure calls the Mksrc shell script in each dialect's subdirectory +to assemble the dialect-specific sources in the main lsof directory. +Configure may call MkKernOpts to determine kernel compile-time +options that are needed for compiling kernel structures correctly +for use by lsof. Configure puts the options in a dialect-specific +Makefile it build, using a template in the dialect subdirectory. + +The assembly of dialect-specific sources in the main lsof directory +is usually done by creating symbolic links from the top level to +the dialect's subdirectory. The LSOF_MKC environment variable may +be defined prior to using Configure to change the technique used +to assemble the sources -- most commonly to use cp instead of ln -s. + +The Configure script completes the dialect's Makefile by adding +string definitions, including the necessary kernel compile-time +options, to a dialect skeleton Makefile while copying it from the +dialect subdirectory to the top level lsof4 directory. Optionally +Makefile may call the dialect's MkKernOpts script to add string +definitions. + +When the lsof library, lsof4/lib/liblsof.a, is compiled its +functions are selected and customized by #define's in the dialect +machine.h header file. + + +Source File Naming Conventions +------------------------------ + +With one exception, dialect-specific source files begin with a +lower case `d' character -- ddev.c, dfile.c, dlsof.h. The one +exception is the header file that contains dialect-specific +definitions for the optional features of the common functions. +It's called machine.h for historical reasons. + +Currently all dialects use almost the same source file names. One +exception to the rule happens in dialects where there must be +different source files -- e.g., dnode[123].c -- to eliminate node +header file structure element name conflicts. The source modules +in a few subdirectories are organized that way. + +These are common files in lsof4/: + + Configure the configuration script + + Customize does some customization of the selected lsof + dialect + + Inventory takes an inventory of the files in an lsof + distribution + + version the version number + + dialects/ the dialects subdirectory + +These are the common function source files in lsof4/: + + arg.c common argument processing functions + + common.h common header file that #include's the dialect-specific + header files + + main.c common main function for lsof 4 + + misc.c common miscellaneous functions -- e.g., special versions + of stat() and readlink() + + node.c common node reading functions -- readinode(), readvnode() + + print.c common print support functions + + proc.c common process and file structure functions + + proto.h common prototype definitions, including the definition of + the _PROTOTYPE() macro + + store.c common global storage version.h the current lsof version + number, derived from the file version by the Makefile + + usage.c functions to display lsof usage panel + +These are the dialect-specific files: + + Makefile the Makefile skeleton + + Mksrc a shell script that assists the Configure script + in configuring dialect sources + + MkKernOpts an optional shell script that identifies kernel + compile-time options for selected dialects -- e.g., + Pyramid DC/OSx and Reliant UNIX + + ddev.c device support functions -- readdev() -- may be + eliminated by functions from lsof4/lib/ + + dfile.c file processing functions -- may be eliminated by + functions from lsof4/lib/ + + dlsof.h dialect-specific header file -- contains #include's + for system header files and dialect-specific global + storage declarations + + dmnt.c mount support functions -- may be eliminated by + functions from lsof4/lib/ + + dnode.c node processing functions -- e.g., for gnode or vnode + + dnode?.c additional node processing functions, used when node + header files have duplicate and conflicting element + names. + + dproc.c functions to access, read, examine and cache data about + dialect-specific process structures -- this file contains + the dialect-specific "main" function, gather_proc_info() + + dproto.h dialect-specific prototype declarations + + dsock.c dialect-specific socket processing functions + + dstore.c dialect-specific global storage -- e.g., the nlist() + structure + + machine.h dialect specific definitions of common function options -- + e.g., a HASINODE definition to activate the readinode() + function in lsof4/node.c + + The machine.h header file also selects and customizes + the functions of lsof4/lib/. + +These are the lib/ files. Definitions in the dialect machine.h +header files select and customize the contained functions that are +to be compiled and archived to liblsof.a. + + Makefile.skel is a skeleton Makefile, used by Configure + to construct the Makefile for the lsof + library. + + cvfs.c completevfs() function + + USE_LIB_COMPLETEVFS selects it. + + CVFS_DEVSAVE, CVFS_NLKSAVE, CVFS_SZSAVE, + and HASFSINO customize it. + + dvch.c device cache functions + + HASDCACHE selects them. + + DCACHE_CLONE, DCACHE_CLR, DCACHE_PSEUDO, + DVCH_CHOWN, DVCH_DEVPATH, DVCH_EXPDEV, + HASBLKDEV, HASENVDC, HASSYSDC, HASPERSDC, + HASPERSDCPATH, and NOWARNBLKDEV customize + them. + + fino.c find block and character device inode functions + + HASBLKDEV and USE_LIB_FIND_CH_INO select them. + + isfn.c hashSfile() and is_file_named() functions + + USE_LIB_IS_FILE_NAMED selects it. + + lkud.c device lookup functions + + HASBLKDEV and USE_LIB_LKUPDEV select them. + + pdvn.c print device name functions + + HASBLKDEV and USE_LIB_PRINTDEVNAME select them. + + prfp.c process_file() function + + USE_LIB_PROCESS_FILE selects it. + + FILEPTR, DTYPE_PIPE, HASPIPEFN, DTYPE_GNODE, + DTYPE_INODE, DTYPE_PORT, DTYPE_VNODE, DTYPE_PTS, + HASF_VNODE, HASKQUEUE, HASPRIVFILETYPE, + HASPSXSHM, HASPSXSEM and HASPTSFN customize it. + + ptti.c print_tcptpi() function + + USE_LIB_PRINT_TCPTPI selects it. + + HASSOOPT, HASSBSTATE, HASSOSTATE, AHSTCPOPT, + HASTCPTPIQ and HASTCPTPIW customize it. + + rdev.c readdev() function + + USE_LIB_READDEV selects it. + + DIRTYPE, HASBLKDEV, HASDCACHE, HASDNAMLEN, + RDEV_EXPDEV, RDEV_STATFN, USE_STAT, and + WARNDEVACCESS customize it. + + rmnt.c readmnt() function + + USE_LIB_READMNT selects it. + + HASFSTYPE, MNTSKIP, RMNT_EXPDEV, RMNT_FSTYPE, + and MOUNTS_FSTYPE customize it. + + rnam.c BSD format name cache functions + + HASNCACHE and USE_LIB_RNAM select them. + + HASFSINO, NCACHE, NCACHE_NC_CAST, NCACHE_NM, + NCACHE_NMLEN, NCACHE_NODEADDR, NCACHE_NODEID, + NCACHE_NO_ROOT, NCACHE_NXT, NCACHE_PARADDR, + NCACHE_PARID, NCACHE_SZ_CAST, NCHNAMLEN, + X_NCACHE, and X_NCSIZE, customize them. + + rnch.c Sun format name cache functions + + HASNCACHE and USE_LIB_RNCH select them. + + ADDR_NCACHE, HASDNLCPTR, HASFSINO, NCACHE_DP, + NCACHE_NAME, NCACHE_NAMLEN, NCACHE_NEGVN, + NCACHE_NODEID, NCACHE_NXT, NCACHE_PARID, + NCACHE_VP, X_NCACHE, and X_NCSIZE, customize + them. + + +The comments and the source code in these library files give more +information on customization. + + +Coding Philosophies +------------------- + +A few basic philosophies govern the coding of lsof 4 functions: + + * Use as few #if/#else/#endif constructs as possible, even at + the cost of nearly-duplicate code. + + When #if/#else/#endif constructs are necessary: + + o Use the form + + #if defined(s) + + in preference to + + #ifdef + + to allow easier addition of tests to the #if. + + o Indent them to signify their level -- e.g., + + #if /* level one */ + # if /* level two */ + # endif /* level two */ + #else /* level one */ + #endif /* level one */ + + o Use ANSI standard comments on #else and #endif statements. + + * Document copiously. + + * Aim for ANSI-C compatibility: + + o Use function prototypes for all functions, hiding them + from compilers that cannot handle them with the _PROTOTYPE() + macro. + + o Use the compiler's ANSI conformance checking wherever + possible -- e.g., gcc's -ansi option. + + +Data Requirements +----------------- + +Lsof's strategy in obtaining open file information is to access +the process table via its proc structures, then obtain the associated +user area and open file structures. The open file structures then +lead lsof to file type specific structures -- cdrnodes, fifonodes, +inodes, gnodes, hsfsnodes, pipenodes, pcnodes, rnodes, snodes, +sockets, tmpnodes, and vnodes. + +The specific node structures must yield data about the open files. The +most important items and device number (raw and cooked) and node +number. (Lsof uses them to identify files and file systems named as +arguments.) Link counts and file sizes are important, too, as are the +special characteristics of sockets, pipes, FIFOs, etc. + +This means that to begin an lsof port to a new Unix dialect you +must understand how to obtain these structures from the dialect's +kernel. Look for kernel access functions -- e.g., the AIX readx() +function, Sun and Sun-like kvm_*() functions, or SGI's syssgi() +function. Look for clues in header files -- e.g. external declarations +and macros. + +If you have access to them, look at sources to programs like ps(1), +or the freely available monitor and top programs. They may give +you important clues on reading proc and user area structures. An +appeal to readers of dialect-specific news groups may uncover +correspondents who can help. + +Careful reading of system header files -- e.g., -- +may give hints about how kernel storage is organized. Look for +global variables declared under a KERNEL or _KERNEL #if. Run nm(1) +across the kernel image (/vmunix, /unix, etc.) and look for references +to structures of interest. + +Even if there are support functions for reading structures, like the +kvm_*() functions, you must still understand how to read data from +kernel memory. Typically this requires an understanding of the +nlist() function, and how to use /dev/kmem, /dev/mem, and /dev/swap. + +Don't overlook the possibility that you may have to use the process +file system -- e.g., /proc. I try to avoid using /proc when I can, +since it usually requires that lsof have setuid(root) permission +to read the individual /proc "files". + +Once you can access kernel structures, you must understand how +they're connected. You must answer questions like: + + * How big are kernel addresses? How are they type cast? + + * How are kernel variable names converted to addresses? + Nlist()? + + * How are the proc structures organized? Is it a static + table? Are the proc structures linked? Is there a + kernel pointer to the first proc structure? Is there a + proc structure count? + + * How does one obtain copies of the proc structures? Via + /dev/kmem? Via a vendor API? + + * If this is a Mach derivative, is it necessary to obtain the + task and thread structures? How? + + * How does one obtain the user area (or the utask area in Mach + systems) that corresponds to a process? + + * Where are the file structures located for open file + descriptors and how are they located? Are all file + structures in the user area? Is the file structure space + extensible? + + * Where do the private data pointers in file structures lead? + To gnodes? To inodes? To sockets? To vnodes? Hint: look + in for DTYPE_* instances and further pointers. + + * How are the nodes organized? To what other nodes do they + lead and how? Where are the common bits of information in + nodes -- device, node number, size -- stored? Hint: look + in the header files for nodes for macros that may be used + to obtain the address of one node from another -- e.g., the + VTOI() macro that leads from a vnode to an inode. + + * Are text reference nodes identified and how? Is it + necessary to examine the virtual memory map of a process or + a task to locate text references? Some kernels have text + node pointers in the proc structures; some, in the user + area; Mach kernels may have text information in the task + structure, reached in various ways from the proc, user area, + or user task structure. + + * How is the device table -- e.g., /dev or /devices -- + organized? How is it read? Using direct or dirent structures? + + How are major/minor device numbers represented? How are + device numbers assembled and disassembled? + + Are there clone devices? How are they identified? + + * How is mount information obtained? Getmntinfo()? Getmntent()? + Some special kernel call? + + * How are sockets identified and organized? BSD-style? As + streams? Are there streams? + + * Are there special nodes -- CD-ROM nodes, FIFO nodes, etc.? + + * How is the kernel's name cache organized? Can lsof access + it to get partial name components? + + +Dlsof.h and #include's +---------------------- + +Once you have identified the kernel's data organization and know +what structures it provides, you must add #include's to dlsof.h to +access their definitions. Sometimes it is difficult to locate the +header files -- you may need to introduce -I specifications in the +Makefile via the DINC shell variable in the Configure script. + +Sometimes it is necessary to define special symbols -- e.g., KERNEL, +_KERNEL, _KMEMUSER -- to induce system header files to yield kernel +structure definitions. Sometimes making those symbol definitions +cause other header file and definition conflicts. There's no good +general rule on how to proceed when conflicts occur. + +Rarely it may be necessary to extract structure definitions from +system header files and move them to dlsof.h, create special versions +of system header files, or obtain special copies of system header +files from "friendly" (e.g., vendor) sources. The dlsof.h header +file in lsof4/dialects/sun shows examples of the first case; the +second, no examples; the third, the irix5hdr subdirectory in +lsof4/dialects/irix (a mixture of the first and third). + +Building up the necessary #includes in dlsof.h is an iterative +process that requires attention as you build the dialect-specific +functions that references kernel structures. Be prepared to revisit +dlsof.h frequently. + + +Definitions That Affect Compilation +----------------------------------- + +The source files at the top level and in the lib/ subdirectory +contain optional functions that may be activated with definitions +in a dialect's machine.h header file. Some are functions for +reading node structures that may not apply to all dialects -- e.g. +CD-ROM nodes (cdrnode), or `G' nodes (gnode) -- and others are +common functions that may occasionally be replaced by dialect-specific +ones. Once you understand your kernel's data organization, you'll +be able to decide the optional common node functions to activate. + +Definitions in machine.h and dlsof.h also enable or disable other +optional common features. The following is an attempt to list all +the definitions that affect lsof code, but CAUTION, it is only +attempt and may be incomplete. Always check lsof4 source code in +lib/ and dialects/, and dialect machine.h header files for other +possibilities + + AFS_VICE See 00XCONFIG. + + AIX_KERNBITS specifies the kernel bit size, 32 or 64, of the Power + architecture AIX 5.x kernel for which lsof was built. + + CAN_USE_CLNT_CREATE is defined for dialects where the more modern + RPC function clnt_create() can be used in + place of the deprecated clnttcp_create(). + + CLONEMAJ defines the name of the variable that + contains the clone major device number. + (Also see HAS_STD_CLONE and HAVECLONEMAJ.) + + DEVDEV_PATH defines the path to the directory where device + nodes are stored, usually /dev. Solaris 10 + uses /devices. + + DIALECT_WARNING may be defined by a dialect to provide a + warning message that will be displayed with + help (-h) and version (-v) output. + + FSV_DEFAULT defines the default file structure values to + list. It may be composed of or'd FSV_* + (See common.h) values. The default is none (0). + + GET_MAJ_DEV is a macro to get major portion from device + number instead of via the standard major() + macro. + + GET_MIN_DEV is a macro to get minor portion from device + number instead of via the standard minor() + macro. + + GET_MAX_FD the name of the function that returns an + int for the maximum open file descriptor + plus one. If not defined, defaults to + getdtablesize. + + HAS9660FS enables CD9660 file system support in a + BSD dialect. + + HAS_ADVLOCK_ARGS is defined for NetBSD and OpenBSD dialects + whose references vop_advlock_args. + + HAS_AFS enables AFS support code for the dialect. + + HAS_AIO_REQ_STRUCT is defined for Solaris 10 and above systems that + have the aio_req structure definition. + + HASAOPT indicates the dialect supports the AFS -A + option when HAS_AFS is also defined. + + HASBLKDEV indicates the dialect has block device support. + + HASBUFQ_H indicates the *NSD dialect has the + header file. + + HASCACHEFS enables cache file system support for the + dialect. + + HASCDRNODE enables/disables readcdrnode() in node.c. + + HAS_CLOSEFROM is defined when the FreeBSD C library contains the + closefrom() function. + + HAS_CONN_NEW indicates the Solaris version has the new form + of the conn_s structure, introduced in b134 of + Solaris 11. This will always accompany the + HAS_IPCLASSIFIER_H definition. + + HAS_CONST indicates that the compiler supports the + const keyword. + + HASCPUMASK_T indicates the FreeBSD 5.2 or higher dialect + has cpumask_t typedef's. + + HAS_CRED_IMPL_H indicates the Solaris 10 dialect has the + header file available. + + HASCWDINFO indicates the cwdinfo structure is defined + in the NetBSD . + + HASDCACHE enables device file cache file support. + The device cache file contains information + about the names, device numbers and inode + numbers of entries in the /dev (or /device) + node subtree that lsof saves from call to + call. See the 00DCACHE file of the lsof + distribution for more information on this + feature. + + HAS_DINODE_U indicates the OpenBSD version has a dinode_u + union in its inode structure. + + HASDNLCPTR is defined when the name cache entry of + has a name character pointer + rather than a name character array. + + HAS_DUP2 is defined when the FreeBSD C library contains the + dup2() function. + + HASEFFNLINK indicates the *BSD system has the i_effnlink + member in the inode structure. + + HASENVDC enables the use of an environment-defined + device cache file path and defines the name + of the environment variable from which lsof + may take it. (See the 00DCACHE file of + the lsof distribution for information on + when HASENVDC is used or ignored.) + + HASEOPT indicates the dialect supports the -e option to + eliminate kernel blocks on a named file system. + + HASEPTOPTS indicates the dialect supports the +|-E end point + options. + + HASEXT2FS is defined for BSD dialects for which ext2fs + file system support can be provided. A value + of 1 indicates that the i_e2din member does not + exist; 2, it exists. + + HASF_VNODE indicates the dialect's file structure has an + f_vnode member in it. + + HAS_FILEDESCENT indicates the FreeBSD system has the filedescent + definition in the header file. + + HASFDESCFS enables file descriptor file system support + for the dialect. A value of 1 indicates + has a Fctty definition; 2, + it does not. + + HASFDLINK indicates the file descriptor file system + node has the fd_link member. + + HASFIFONODE enables/disables readfifonode() in node.c. + + HAS_F_OPEN indicates the UnixWare 7.x dialect has the + f_open member in its file struct. + + HASFSINO enables the inclusion of the fs_ino element + in the lfile structure definition in common.h. + This contains the file system's inode number + and may be needed when searching the kernel + name cache. See dialects/osr/dproc.c for + an example. + + HASFSTRUCT indicates the dialect has a file structure + the listing of whose element values can be + enabled with +f[cfn]. FSV_DEFAULT defines + the default listing values. + + HASFSTYPE enables/disables the use of the file system's + stat(2) st_fstype member. + + If the HASFSTYPE value is 1, st_fstype is + treated as a character array; 2, it is + treated as an integer. + + See also the RMNT_EXPDEV and RMNT_FSTYPE + documentation in lib/rmnt.c + + HASGETBOOTFILE indicates the NetBSD or OpenBSD dialect has + a getbootfile() function. + + HASGNODE enables/disables readgnode() in node.c. + + HASHSNODE enables/disables readhsnode() in node.c. + + HASI_E2FS_PTR indicates the BSD dialect has a pointer in + its inode to the EXTFS dinode. + + HASI_FFS indicates the BSD dialect has i_ffs_size + in . + + HASI_FFS1 indicates the BSD dialect supports the fast + UFS1 and UFS2 file systems. + + HAS_INKERNEL indicates the SCO OSR 6.0.0 or higher, or + UnixWare 7.1.4 or higher system uses the + INKERNEL symbol in or + . + + HASINODE enables/disables readinode() in node.c. + + HASINRIAIPv6 is defined if the dialect has the INRIA IPv6 + support. (HASIPv6 will also be defined.) + + HASINT16TYPE is defined when the dialect has a typedef + for int16 that may conflict with some other + header file's redefinition (e.g., ). + + HASINT32TYPE is defined when the dialect has a typedef + for int32 that may conflict with some other + header file's redefinition (e.g., ). + + HASINTSIGNAL is defined when signal() returns an int. + + HAS_IPCLASSIFIER_H is defined for Solaris dialects that have the + header file. + + HAS_IPC_S_PATCH is defined when the HP-UX 11 dialect has the + ipc_s patch installed. It has a value of + 1 if the ipc_s structure has an ipc_ipis + member, but the ipis_s structure lacks the + ipis_msgsqueued member; 2, if ipc_s has + ipc_ipis, but ipis_s lacks ipis_msgsqueued. + + HASIPv6 indicates the dialect supports the IPv6 + Internet address family. + + HAS_JFS2 The AIX >= 5.0 dialect has jfs2 support. + + HASKERNFS is defined for BSD dialects for which + /kern file system support can be provided. + + HASKERNFS_KFS_KT indicates *kfs_kt is in the BSD dialect's + . + + HASKOPT enables/disables the ability to read the + kernel's name list from a file -- e.g., from + a crash dump file. + + HASKQUEUE indicates the dialect supports the kqueue + file type. + + HASKVMGETPROC2 The *BSD dialect has the kvm_gettproc2() + function. + + HAS_KVM_VNODE indicates the FreeBSD 5.3 or higher dialect has + "defined(_KVM_VNODE)" in . + + HASLFILEADD defines additional, dialect-specific elements + + SETLFILEADD in the lfile structure (defined in common.h). + HASLFILEADD is a macro. The accompanying SETFILEADD + macro is used in the alloc_lfile() function of + proc.c to preset the additional elements. + + HAS_LF_LWP is defined for BSD dialects where the lockf + structure has an lf_lwp member. + + HASLFS indicates the *BSD dialect has log-structured + file system support. + + HAS_LGRP_ROOT_CONFLICT + indicates the Solaris 9 or Solaris 10 system has + a conflict over the lgrp_root symbol in the + and header files. + + HAS_LIBCTF indicates the Solaris 10 and above system has + the CTF library. + + HAS_LOCKF_ENTRY indicates the FreeBSD version has a lockf_entry + structure in its header file. + + HAS_LWP_H is defined for BSD dialects that have the + header file. + + HASMOPT enables/disables the ability to read kernel + memory from a file -- e.g., from a crash + dump file. + + HASMSDOSFS enables MS-DOS file system support in a + BSD dialect. + + HASMNTSTAT indicates the dialect has a stat(2) status + element in its mounts structure. + + HASMNTSUP indicates the dialect supports the mount supplement + option. + + HASNAMECACHE indicates the FreeBSD dialect has a namecache + structure definition in . + + HASNCACHE enables the probing of the kernel's name cache + to obtain path name components. A value + of 1 directs printname() to prefix the + cache value with the file system directory + name; 2, avoid the prefix. + + HASNCVPID The *BSD dialect namecache struct has an + nc_vpid member. + + HAS_NFS enables NFS support for the dialect. + + HASNFSPROTO indicates the NetBSD or OpenBSD version + has the nfsproto.h header file. + + HASNFSVATTRP indicates the n_vattr member of the nfsnode of + the *BSD dialect is a pointer. + + HASNLIST enables/disables nlist() function support. + (See NLIST_TYPE.) + + HASNOFSADDR is defined if the dialect has no file structure + addresses. (HASFSTRUCT must be defined.) + + HASNOFSCOUNT is defined if the dialect has no file structure counts. + (HASFSTRUCT must be defined.) + + HASNOFSFLAGS is defined if the dialect has no file structure flags. + (HASFSTRUCT must be defined.) + + HASNOFSNADDR is defined if the dialect has no file structure node + addresses. (HASFSTRUCT must be defined.) + + HAS_NO_6PORT is defined if the FreeBSD in_pcb.h has no in6p_.port + definitions. + + HAS_NO_6PPCB is defined if the FreeBSD in_pcb.h has no in6p_ppcb + definition. + + HAS_NO_LONG_LONG indicates the dialect has no support for the C + long long type. This definition is used by + the built-in snprintf() support of lib/snpf.c. + + HASNORPC_H indicates the dialect has no /usr/include/rpc/rpc.h + header file. + + HASNOSOCKSECURITY enables the listing of open socket files, + even when HASSECURITY restricts listing of + open files to the UID of the user who is + running lsof, provided socket file listing + is selected with the "-i" option. This + definition is only effective when HASSECURITY + is also defined. + + HASNULLFS indicates the dialect (usually *BSD) has a + null file system. + + HASOBJFS indicates the Pyramid version has OBJFS + support. + + HASONLINEJFS indicates the HP-UX 11 dialect has the optional + OnlineJFS package installed. + + HAS_PC_DIRENTPERSEC + indicates the Solaris 10 system's + header file has the pc_direntpersec() macro. + + HAS_PAD_MUTEX indicates the Solaris 11 system has the pad_mutex_t + typedef in its header file. + + HASPERSDC enables the use of a personal device cache + file path and specifies a format by which + it is constructed. See the 00DCACHE file + of the lsof distribution for more information + on the format. + + HASPERSDCPATH enables the use of a modified personal + device cache file path and specifies the + name of the environment variable from which + its component may be taken. See the 00DCACHE + file of the lsof distribution for more + information on the modified personal device + cache file path. + + HASPINODEN declares that the inode number of a /proc file + should be stored in its procfsid structure. + + HASPIPEFN defines the function that processes DTYPE_PIPE + file structures. It's used in the prfp.c + library source file. See the FreeBSD + dialect source for an example. + + HASPIPENODE enables/disables readpipenode() in node.c. + + HASPMAPENABLED enables the automatic reporting of portmapper + registration information for TCP and UDP + ports that have been registered. + + HASPPID indicates the dialect has parent PID support. + + HASPR_LDT indicates the Solaris dialect has a pr_ldt + member in the pronodetype enum. + + HASPR_GWINDOWS indicates the Solaris dialect has a pr_windows + member in the pronodetype enum. + + HASPRINTDEV this value defines a private function for + printing the dialect's device number. Used + by print.c/print_file(). Takes one argument: + + char *HASPRINTDEV(struct lfile *) + + HASPRINTINO this value names a private function for + printing the dialect's inode number. Used + by print.c/print_file(). Takes one argument: + + char *HASPRINTINO(struct lfile *) + + HASPRINTNM this value names a private function for + printing the dialect's file name. Used by + print.c/print_file(). Takes one argument: + + void HASPRINTNM(struct lfile *) + + HASPRIVFILETYPE enables processing of the private file + type, whose number (from f_type of the file + struct) is defined by PRIVFILETYPE. + HASPRIVFILETYPE defines the function that + processes the file struct's f_data member. + Processing is initiated from the process_file() + function of the prfp.c library source file + or from the dialect's own process_file() + function. + + HASPRIVNMCACHE enables printing of a file path from a + private name cache. HASPRIVNMCACHE defines + the name of the printing function. The + function takes one argument, a struct lfile + pointer to the file, and returns non-zero + if it prints a cached name to stdout. + + HASPRIVPRIPP is defined for dialects that have a private + function for printing the IP protocol name. + When this is not defined, the function to + do that defaults to printiproto(). + + HASPROCFS defines the name (if any) of the process file + system -- e.g., /proc. + + HASPROCFS_PFSROOT indicates PFSroot is in the BSD dialect's + . + + HASPSEUDOFS indicates the FreeBSD dialect has pseudofs + file system support. + + HASPSXSEM indicates the dialect has support for the POSIX + semaphore file type. + + HASPSXSHM indicates the dialect has support for the POSIX + shared memory file type. + + HASPTSFN indicates the dialect has a DNODE_PTS file descriptor + type and defines the function that processes it. + + HASPTYEPT indicates the Linux dialect has support for the + pseudoterminal endpoint option. + + HASPTYFS indicates the *BSD dialect has a ptyfs file system. + + HASRNODE enables/disables readrnode() in node.c. + + HASRNODE3 indicates the HPUX 10.20 or lower dialect has NFS3 + support with a modified rnode structure. + + HASRPCV2H The FreeBSD dialect has . + + HAS_SANFS indicates the AIX system has SANFS file system + support. + + HAS_SB_CC indicates the FreeBSD system's sockbuf structure has + the sb_ccc member, rather than the sb_cc member. + + HASSBSTATE indicates the dialect has socket buffer state + information (e.g., SBS_* symbols) available. + + HASSECURITY enables/disables restricting open file + information access. (Also see HASNOSOCKSECURITY.) + + HASSELINUX indicates the Linux dialect has SELinux security + context support available. + + HASSETLOCALE is defined if the dialect has and + setlocale(). + + HAS_SI_PRIV indicates the FreeBSD 6.0 and higher cdev + structure has an si_priv member. + + HAS_SOCKET_PROTO_H indicates the Solaris 10 system has the header file + . + + HASSOUXSOUA indicates that the Solaris has + soua_* members in its so_ux_addr structure. + + HASSPECDEVD indicates the dialect has a special device + directory and defines the name of a function + that processes the results of a successful + stat(2) of a file in that directory. + + HASSNODE indicates the dialect has snode support. + + HASSOOPT indicates the dialect has socket option + information (e.g., SO_* symbols) available. + + HASSOSTATE indicates the dialect has socket state + information (e.g., SS_* symbols) available. + + HASSTATVFS indicates the NetBSD dialect has a statvfs + struct definition. + + HASSTAT64 indicates the dialect's contains + stat64. + + HAS_STD_CLONE indicates the dialect uses a standard clone + device structure that can be used in common + library function clone processing. If the + value is 1, the clone table will be built + by readdev() and cached when HASDCACHE is + defined; if the value is 2, it is assumed + the clone table is built independently. + (Also see CLONEMAJ and HAVECLONEMAJ.) + + HASSTREAMS enables/disables streams. CAUTION, requires + specific support code in the dialect sources. + + HAS_STRFTIME indicates the dialect has the gmtime() and + strftime() C library functions that support + the -r marker format option. Configure tests + for the functions and defines this symbol. + + HASSYSDC enables the use of a system-wide device + cache file and defines its path. See the + 00DCACHE file of the lsof distribution for + more information on the system-wide device + cache file path option. + + HAS_SYS_PIPEH indicates the dialect has a + header file. + + HAS_SYS_SX_H indicates the FreeBSD 7.0 and higher system has + a header file. + + HAS_TMPFS indicates the FreeBSD system has the + header file. + + HASTMPNODE enables/disables readtnode() in node.c. + + HASTCPOPT indicates the dialect has TCP option + information (i.e., from TF_* symbols) + available. + + HASTCPTPIQ is defined when the dialect can duplicate + the receive and send queue sizes reported + by netstat. + + HASTCPTPIW is defined when the dialect can duplicate + the receive and send window sizes reported + by netstat. + + HASTCPUDPSTATE is defined when the dialect has support for + TCP and UDP state, including the "-s p:s" + option and associated speed enhancements. + + HASTFS indicates that the Pyramid dialect has TFS + file system support. + + HAS_UFS1_2 indicates the FreeBSD 6 and higher system has + UFS1 and UFS2 members in its inode structure. + + HAS_UM_UFS indicates the OpenBSD version has UM_UFS[12] + definitions. + + HASUINT16TYPE is defined when the dialect has a typedef + for u_int16 that may conflict with some other + header file's redefinition (e.g., ). + + HASUXSOCKEPT indicates the Linux version has support for the + UNIX socket endpoint option. + + HASUTMPX indicates the dialect has a header + file. + + HAS_UVM_INCL indicates the NetBSD or OpenBSD dialect has + a include directory. + + HAS_UW_CFS indicates the UnixWare 7.1.1 or above dialect + has CFS file system support. + + HAS_UW_NSC indicates the UnixWare 7.1.1 or above dialect + has a NonStop Cluster (NSC) kernel. + + HAS_V_LOCKF indicates the FreeBSD version has a v_lockf + member in the vode structure, defined in + . + + HAS_VM_MEMATTR_T indicates the FreeBSD uses the + vm_memattr_t typedef. + + HASVMLOCKH indicates the FreeBSD dialect has . + + HASVNODE enables/disables readvnode() function in node.c. + + HAS_V_PATH indicates the dialect's vnode structure has a + v_path member. + + HAS_VSOCK indicates that the Solaris version has a VSOCK + member in the vtype enum + + HASVXFS enables Veritas VxFS file system support for + the dialect. CAUTION, the dialect sources + must have the necessary support code. + + HASVXFSDNLC indicates the VxFS file system has its own + name cache. + + HASVXFS_FS_H indicates exists. + + HASVXFS_MACHDEP_H indicates exists. + + HASVXFS_OFF64_T indicates exists and + has an off64_t typedef. + + HASXVFSRNL indicates the dialect has VxFS Reverse Name + Lookup (RNL) support. + + HASVXFS_SOL_H indicates exists. + + HASVXFS_SOLARIS_H indicates exists. + + HASVXFS_U64_T if HASVXFS_SOLARIS_H is defined, this + variable indicates that + has a vx_u64_t typedef. + + HASVXFSUTIL indicates the Solaris dialect has VxFS 3.4 + or higher and has the utility libraries, + libvxfsutil.a (32 bit) and libvxfsutil64.a + (64 bit). + + HASVXFS_VX_INODE indicates that contains + a vx_inode structure. + + HASWCTYPE_H indicates the FreeBSD version has wide-character + support and the header file. Note: + the HASWIDECHAR #define will also be set. + + HASWIDECHAR indicates the dialect has the wide-character + support functions iswprint(), mblen() and mbtowc(). + + HASXNAMNODE indicates the OSR dialect has . + + HASXOPT defines help text for dialect-specific X option + and enables X option processing in usage.c and + main.c. + + HASXOPT_ROOT when defined, restricts the dialect-specific + X option to processes whose real user ID + is root. + + HASXOPT_VALUE defines the default binary value for the X option + in store.c. + + HAS_XTCPCB_TMAXSEG indicates that in this FreeBSD + version exists and its struct xtcpcb has a + t_magseg field. + + HAS_ZFS indicates the dialect has support for the ZFS file + system. + + HASZONES the Solaris dialect has zones. + + HAVECLONEMAJ defines the name of the status variable + that indicates a clone major device number + is available in CLONEMAJ. (Also see CLONEMAJ + and HAS_STD_CLONE.) + + HPUX_KERNBITS defines the number of bits in the HP-UX 10.30 + and above kernel "basic" word: 32 or 64. + + KA_T defines the type cast required to assign + space to kernel pointers. When not defined + by a dialect header file, KA_T defaults to + unsigned long. + + KA_T_FMT_X defines the printf format for printing a + KA_T -- the default is "%#lx" for the + default unsigned long KA_T cast. + + LSOF_ARCH See 00XCONFIG. + + LSOF_BLDCMT See 00XCONFIG. + + LSOF_CC See 00XCONFIG. + + LSOF_CCV See 00XCONFIG. + + LSOF_HOST See 00XCONFIG. + + LSOF_INCLUDE See 00XCONFIG. + + LSOF_LOGNAME See 00XCONFIG. + + LSOF_MKC See the "The Mksrc Shell Script" section of + this file. + + LSOF_SYSINFO See 00XCONFIG. + + LSOF_USER See 00XCONFIG. + + LSOF_VERS See 00XCONFIG. + + LSOF_VSTR See 00XCONFIG. + + MACH defines a MACH system. + + N_UNIXV defines an alternate value for the N_UNIV symbol. + + NCACHELDPFX defines C code to be executed before calling + ncache_load(). + + NCACHELDSFX defines C code to be executed after calling + ncache_load(). + + NEEDS_BOOL_TYPEDEF indicates the FreeBSD 10 system, being built on an + i386 architecture systemn, needs typdef bool. + + NEEDS_BOOLEAN_T indicates the FreeBSD 9 and above system needs a + boolean_t definition for . + + NEEDS_DEVICE_T indicates the FreeBSD header file + needs the device_t typedef. + + NEEDS_MACH_PORT_T is defined for Darwin versions that need the inclusion + of the header file . + + NEEDS_NETINET_TCPH is defined when the Linux version needs to #include + in place of in order to + have access to the TCP_* definitions. + + NEVER_HASDCACHE keeps the Customize script from offering to + change HASDCACHE by its presence anywhere + in a dialect's machine.h header file -- + e.g., in a comment. See the Customize + script or machine.h in dialects/linux/proc. + + NEVER_WARNDEVACCESS keeps the Customize script from offering to + change WARNDEVACCESS by its presence anywhere + in a dialect's machine.h header file -- + including in a comment. See the Customize + script or machine.h in dialects/linux/proc. + + NLIST_TYPE is the type of the nlist table, Nl[], if it is + not nlist. HASNLIST must be set for this + definition to be effective. + + NOWARNBLKDEV specifies that no warning is to be issued + when no block devices are found. This + definition is used only when HASBLKDEV is + also defined. + + OFFDECDIG specifies how many decimal digits will be + printed for the file offset in a 0t form + before switching to a 0x form. The count + includes the "0t". A count of zero means + the size is unlimited. + + PRIVFILETYPE is the number of a private file type, found + in the f_type member of the file struct, to + be processed by the HASPRIVFILETYPE function. + See the AIX dialect sources for an example. + + _PSTAT_STREAM_GET_XPORT + indicates the HP-UX PSTAT header files require + this symbol to be defined for proper handling of + stream export data. + + SAVE_MP_IN_SFILE indicates the dialect needs to have the mounts + structure pointer for a file system search argument + recorded in the dialect's sfile structure. This + definition is made in the dialect's dlsof.h header + file within the sfile structure. + + TIMEVAL_LSOF defines the name of the timeval structure. + The default is timeval. /dev/kmem-based + Linux lsof redefines timeval with this + symbol to avoid conflicts between glibc + and kernel definitions. + + TYPELOGSECSHIFT defines the type of the cdfs_LogSecShift + member of the cdfs structure for UnixWare + 7 and higher. + + UID_ARG_T defines the cast on a User ID when passed + as a function argument. + + USE_LIB_COMPLETEVFS + selects the use of the completevfs() function + in lsof4/lib/cvfs.c. + + USE_LIB_FIND_CH_INO + selects the use of the find_ch_ino() inode + function in lsof4/lib/fino.c. + + Note: HASBLKDEV selects the has_bl_ino() + function. + + USE_LIB_IS_FILE_NAMED + selects the use of the is_file_named() function + in lsof4/lib/isfn.c. + + USE_LIB_LKUPDEV selects the use of the lkupdev() function + in lsof4/lib/lkud.c. + + Note: HASBLKDEV selects the lkupbdev() function. + + USE_LIB_PRINTDEVNAME + selects the use of the printdevname() function + in lsof4/lib/pdvn.c. + + Note: HASBLKDEV selects the printbdevname() + function. + + USE_LIB_PRINT_TCPTPI + selects the use of the print_tcptpi() function + in lsof4/lib/ptti.c. + + USE_LIB_PROCESS_FILE + selects the use of the process_file() function + in lsof4/lib/prfp.c. + + USE_LIB_READDEV selects the use of the readdev() and stkdir() + functions in lsof4/lib/rdev.c. + + USE_LIB_READMNT selects the use of the readmnt() function + in lsof4/lib/rmnt.c. + + USE_LIB_RNAM selects the use of the device cache functions + in lsof4/lib/rnam.c. + + Note: HASNCACHE must also be defined. + + USE_LIB_RNCH selects the use of the device cache functions + in lsof4/lib/rnch.c. + + Note: HASNCACHE must also be defined. + + USE_STAT is defined for those dialects that must + use the stat(2) function instead of lstat(2) + to scan /dev -- i.e., in the readdev() + function. + + VNODE_VFLAG is an alternate name for the vnode structure's + v_flag member. + + WARNDEVACCESS enables the issuing of a warning message when + lsof is unable to access /dev (or /device) + or one of its subdirectories, or stat(2) + a file in them. Some dialects (e.g., HP-UX) + have many inaccessible subdirectories and + it is appropriate to inhibit the warning + for them with WARNDEVACCESS. The -w option + will also inhibit these warnings. + + WARNINGSTATE when defined, disables the default issuing + of warning messages. WARNINGSTATE is + undefined by default for all dialects in + the lsof distribution. + + WIDECHARINCL defines the header file to be included (if any) + when wide-character support is enabled with + HASWIDECHAR. + + zeromem() defines a macro to zero memory -- e.g., using + bzero() or memset(). + +Any dialect's machine.h file and Configure stanza can serve as a +template for building your own. All machine.h files usually have +all definitions, disabling some (with comment prefix and suffix) +and enabling others. + + +Options: Common and Special +--------------------------- + +All but one lsof option is common; the specific option is ``-X''. +If a dialect does not support a common option, the related #define +in machine.h -- e.g., HASCOPT -- should be deselected. + +The specific option, ``-X'', may be used by any dialect for its +own purpose. Right now (May 30, 1995) the ``-X'' option is binary +(i.e., it's not allowed arguments of its own, and its value must +be 0 or 1) but that could be changed should the need arise. The +option is enabled with the HASXOPT definition in machine.h; its +default value is defined by HASXOPT_VALUE. + +The value of HASXOPT should be the text displayed for ``-X'' by +the usage() function in usage.c. HASXOPT_VALUE should be the +default value, 0 or 1. + +AIX for the IBM RICS System/6000 defines the ``-X'' option to +control readx() usage, since there is a bug in AIX kernels that +readx() can expose for other processes. + + +Defining Dialect-Specific Symbols and Global Storage +---------------------------------------------------- + +A dialect's dlsof.h and dstore.c files contain dialect-specific +symbol and global storage definitions. There are symbol definitions, +for example, for function and data casts, and for file paths. +Dslof.h defines lookup names the nlist() table -- X_* symbols -- +when nlist() is being used. + +Global storage definitions include such things as structures for +local Virtual File System (vfs) information; mount information; +search file information; and kernel memory file descriptors -- +e.g., Kmem for /dev/kmem, Mem for /dev/mem, Swap for /dev/drum. + + +Coding Dialect-specific Functions +--------------------------------- + +Each supported dialect must have some basic functions that the +common functions of the top level may call. Some of them may be +obtained from the library in lsof4/lib, selected and customized by +#define's in the dialect machine.h header file. Others may have +to be coded specifically for the dialect. + +Each supported dialect usually has private functions, too. Those +are wholly determined by the needs of the dialect's data organization +and access. + +These are some of the basic functions that each dialect must supply +-- they're all defined in proto.h: + + initialize() function to initialize the dialect + + is_file_named() function to check if a file was named + by an optional file name argument + (lsof4/lib/isfn.c) + + gather_proc_info() function to gather process table + and related information and cache it + + printchdevname() function to locate and optionally + print the name of a character device + (lsof4/lib/pdvn.c) + + print_tcptpistate() function to print the TCP or TPI + state for a TCP or UDP socket file, + if the one in lib/ptti.c isn't + suitable (define USE_LIB_PRINT_TCPTPI + to activate lib/ptti.c) + + process_file() function to process an open file + structure (lsof4/lib/prfp.c) + + process_node() function to process a primary node + + process_socket() function to process a socket + + readdev() and stkdir() functions to read and cache device + information (lsof4/lib/rdev.c) + + readmnt() function to read mount table information + (lsof4/lib/rmnt.c) + +Other common functions may be needed, and might be obtained from +lsof4/lib, depending on the needs of the dialect's node and socket +file processing functions. + +Check the functions in lsof4/lib and specific lsof4/dialects/* +files for examples. + +As you build these functions you will probably have to add #include's +to dlsof.h. + + +Function Prototype Definitions and the _PROTOTYPE Macro +------------------------------------------------------- + +Once you've defined your dialect-specific definitions, you should +define their prototypes in dproto.h or locally in the file where +they occur and are used. Do this even if your compiler is not ANSI +compliant -- the _PROTOTYPE macro knows how to cope with that and +will avoid creating prototypes that will confuse your compiler. + + +The Makefile +------------ + +Here are some general rules for constructing the dialect Makefile. + + * Use an existing dialect's Makefile as a template. + + * Make sure the echo actions of the install rule are appropriate. + + * Use the DEBUG string to set debugging options, like ``-g''. + You may also need to use the -O option when forking and + SIGCHLD signals defeat your debugger. + + * Don't put ``\"'' in a compiler flags -D= + clause in your Makefile. Leave off the ``\"'' even though + you want to be a string literal and instead adapt + the N_UNIX* macros you'll find in Makefiles for FreeBSD + and Linux. That will allow the Makefile's version.h rule + to put CFLAGS into version.h without having to worry about + the ``\"'' sequences. + + * Finally, remember that strings can be passed from the top + level's Configure shell script. That's an appropriate way + to handle options, especially if there are multiple versions + of the Unix dialect to which you are porting lsof 4. + + +The Mksrc Shell Script +---------------------- + +Pattern your Mksrc shell script after an existing one from another +dialect. Change the D shell variable to the name of your dialect's +subdirectory in lsof4/dialects. Adjust any other shell variable +to your local conditions. (Probably that won't be necessary.) + +Note that, if using symbolic links from the top level to your +dialect subdirectory is impossible or impractical, you can set the +LSOF_MKC shell variable in Configure to something other than +"ln -s" -- e.g., "cp," and Configure will pass it to the Mksrc +shell script in the M environment variable. + + +The MkKernOpts Shell Script +--------------------------- + +The MkKernOptrs shell script is used by some dialects -- e.g., +Pyramid DC/OSx and Reliant UNIX -- to determine the compile-time +options used to build the current kernel that affect kernel structure +definitions, so those same options can be used to build lsof. +Configure calls MkKernOpts for the selected dialects. + +If your kernel is built with options that affect structure definitions. +-- most commonly affected are the proc structure from +and the user structure from -- check the MkKernOpts +in lsof4/dialects/irix for a comprehensive example. + + +Testing and the Lsof Test Suite +------------------------------- + +Once you have managed to create a port, here are some tips for +testing it. + +* First look at the test suite in the tests/ sub-directory of the + lsof distribution. While it will need to be customized to be + usable with a new port, it should provide ideas on things to + test. Look for more information about the test suite in the + 00TEST file. + +* Pick a simple process whose open files you are likely to + know and see if the lsof output agrees with what you know. + (Hint: select the process with `lsof -p `.) + + Are the device numbers and device names correct? + + Are the file system names and mount points correct? + + Are inode numbers and sizes correct? + + Are command names, file descriptor numbers, UIDs, PIDs, PGIDs, + and PPIDs correct? + + A simple tool that does a stat(2) of the files being examined + and reports the stat struct contents can provide a reference for + some values; so can `ls -l /dev/`. + +* Let lsof list information about all open files and ask the + same questions. Look also for error messages about not being + able to read a node or structure. + +* Pick a file that you know is open -- open it and hold it + that way with a C program (not vi), if you must. Ask lsof to + find the file's open instance by specifying its path to lsof. + +* Create a C program that opens a large number of files and holds + them open. Background the test process and ask lsof to list + its files. + +* Generate some locks -- you may need to write a C program to + do this, hold the locked file open, and see if lsof can identify + the lock properly. You may need to write several C programs + if your dialect supports different lock functions -- fnctl(), + flock(), lockf(), locking(). + +* Identify a process with known Internet file usage -- inetd + is a good one -- and ask lsof to list its open files. See if + protocols and service names are listed properly. + + See if your lsof identifies Internet socket files properly for + rlogind or telnetd processes. + +* Create a UNIX domain socket file, if your dialect allows it, + hold it open by backgrounding the process, and see if lsof can + identify the open UNIX domain socket file properly. + +* Create a FIFO file and see what lsof says about it. + +* Watch an open pipe -- `lsof -u | less` is a + good way to do this. + +* See if lsof can identify NFS files and their devices properly. + Open and hold open an NFS file and see if lsof can find the open + instance by path. + +* If your test system has CD-ROM and floppy disk devices, open + files on them and see if lsof reports their information correctly. + Such devices often have special kernel structures associated + with them and need special attention from lsof for their + identification. Pay particular attention to the inode numbers + lsof reports for CD-ROM and floppy disk files -- often they are + calculated dynamically, rather than stored in a kernel node + structure. + +* If your implementation can probe the kernel name cache, look + at some processes with open files whose paths you know to see + if lsof identifies any name components. If it doesn't, make + sure the name components are in the name cache by accessing + the files yourself with ls or a similar tool. + +* If your dialect supports the /proc file system, use a C program + to open files there, background a test process, and ask lsof to + report its open files. + +* If your dialect supports fattach(), create a small test program + to use it, background a test process, and ask lsof to report + its open files. + +I can supply some quick-and-dirty tools for reporting stat buffer +contents, holding files open, creating UNIX domain files, creating +FIFOs, etc., if you need them. + + +Where Next? +----------- + +Is this document complete? Certainly not! One might wish that it +were accompanied by man pages for all lsof functions, by free beer +or chocolates, by ... (You get the idea.) + +But those things are not likely to happen as long as lsof is a +privately supported, one man operation. + +So, if you need more information on how lsof is constructed or +works in order to do a port of your own, you'll have to read the +lsof source code. You can also ask me questions via email, but +keep in mind the private, one-man nature of current lsof support. + + +Vic Abell +July 14, 2018 diff --git a/00QUICKSTART b/00QUICKSTART new file mode 100644 index 0000000..0df967c --- /dev/null +++ b/00QUICKSTART @@ -0,0 +1 @@ +This documentation has been replaced by docs/tutorial.md, docs/faq.md and docs/options.md. Please refer to the new files or read them online. \ No newline at end of file diff --git a/00README b/00README new file mode 100644 index 0000000..2b1e6ea --- /dev/null +++ b/00README @@ -0,0 +1,1470 @@ + + Making and Installing lsof 4 + +******************************************************************** +| The latest release of lsof is always available via anonymous ftp | +| from lsof.itap.purdue.edu. Look in pub/tools/unix/lsof. | +******************************************************************** + + Contents + + Pre-built Lsof Binaries + Making Lsof + Other Configure Script Options + Environment Variables + Security + Run-time Warnings + Device Access Warnings + NFS Blocks + Caches -- Name and Device + Raw Sockets + Other Compile-time Definitions + The AFSConfig Script + The Inventory Script + The Customize Script + Cautions + Warranty + License + Bug Reports + The 00FAQ File + The lsof-l Mailing List + Field Output Example Scripts + Field Output C Library + Testing Lsof + Dialect Notes + AFS + AIX + Apple Darwin + Auspex LFS (no longer maintained) + BSDI BSD/OS + FreeBSD + HP-UX + IPv6 + Linux + NetBSD + OpenBSD + Pyramid DC/OSx and Reliant UNIX (no longer available) + Caldera OpenUNIX + SCO OpenServer + SCO|Caldera UnixWare + Solaris 2.x, 7, 8, 9 and 10 + Ultrix (no longer available) + Veritas VxFS and VxVM + User-contributed Dialect Support + Dialects No Longer Supported + Installing Lsof + Setuid-root Lsof Dialects + Setgid Lsof Dialects + Porting lsof 4 to a New UNIX Dialect + Quick Start to Using lsof + Cross-configuring Lsof + Environment Variables Affecting the Configure Script + + +======================= +Pre-built Lsof Binaries +======================= + +Avoid using pre-built lsof binaries if you can; build your own +instead. + +I do not support lsof binaries built and packaged by third parties nor +lsof binaries built from anything but the latest lsof revision. (See +the Bug Reports section for more information on the details of lsof +support.) + +One important reasone for those support restrictions is that when lsof +is built its Configure script tunes lsof to the features available on +the building system, often embodied in supporting header files and +libraries. If the building system doesn't have support for a +particular feature, lsof won't be built to support the feature on any +system. + +The Veritas VxFS file system is a good example of a feature that +requires build-time support. + +UNIX dialect version differences -- Solaris 8 versus 9, AIX 4.3.3 +vesus 5.2, etc. -- can also render a pre-built lsof binary useless +on a different version. So can kernel bit size. + +There are so many potential pitfalls to using an lsof binary +improperly that I strongly recommend lsof be used only where it is +built. + + +=========== +Making Lsof +=========== + + $ cd + $ ./Configure + $ make + +(Consult the 00FAQ and 00XCONFIG files of the lsof distribution +for information about using make command invocations and environment +variables to override lsof default Makefile strings.) + +This lsof distribution can be used with many UNIX dialects. However, +it must be configured specifically for each dialect. Configuration +is done in three ways: 1) by changing definitions in the machine.h +header file of the UNIX dialect of interest; 2) by defining +environment variable values prior to calling Configure (see the +00XCONFIG file, the Environment Variabls and Environment Variables +Affecting the Configure Script sections of this file); and 3) by +running the Configure shell script found in the top level of the +distribution directory. + +You may not need to change any machine.h definitions, but you might +want to look at them anyway. Pay particular attention to the +definitions that are discussed in the Security section of this +file. Please read that section. + +The Configure script calls three other scripts in the lsof +distribution: AFSConfig; Inventory; and Customize. The AFSConfig +script is called for selected dialects (AIX, HP-UX, NEXTSTEP, and +Solaris) to locate AFS header files and determine the AFS version. +See The AFSConfig Script section of this file for more information. + +The Inventory script checks the completeness of the lsof distribution. +Configure calls Inventory after it has accepted the dialect +abbreviation, but before it configures the top-level directory for +the dialect. See The Inventory Script section of this file for +more information. + +Configure calls the Customize script after it has configured the +top-level lsof directory for the declared dialect. Customize helps +you modify some of the important compile-time definitions of +machine.h. See the The Customize Script section. + +You should also think about where you will install lsof and its +man page, and whom you will let execute lsof. Please read the +Installing Lsof section of this file for information on installation +considerations. + +Once you have inspected the machine.h file for the dialect for +which you want to build lsof, and made any changes you need, run +the Configure script, supplying it with the abbreviation for the +dialect. (See the following table.) Configure selects the +appropriate options for the dialect and runs the Mksrc shell script +in the dialect sub-directory to construct the appropriate source +files in the top-level distribution directory. + +Configure may also run the MkKernOpts script in the dialect +sub-directory to propagate kernel build options to the dialect +Makefile. This is done for only a few dialects -- e.g., DC/OSx, +and Reliant UNIX. + +Configure creates a dialect-specific Makefile. You may want to +inspect or edit this Makefile to make it conform to local conventions. +If you want the Makefile to install lsof and its man page, you will +have to create an appropriate install rule. + +Lsof may be configured using UNIX dialect abbreviations from the +following table. Alternative abbreviations are indicated by a +separating `|'. For example, for SCO OpenServer you can use either +the ``osr'' or the ``sco'' abbreviation: + + $ Configure osr + or + $ Configure sco + + Abbreviations UNIX Dialect + ------------- ------------ + + aix IBM AIX 5.[23] and 5.3-ML1 using IBM's C Compiler + aixgcc IBM AIX 5.[12] and 5.3-ML1 using gcc + darwin Apple Darwin 7.x and 8.x for Power Macintosh systems + freebsd FreeBSD 4.x, 4.1x, 5.x and [67].x + hpux HP-UX 11.00, 11.11 and 11.23, using HP's C + Compiler, both /dev/kmem-based and PSTAT-based + hpuxgcc HP-UX 11.00, 11.11 and 11.23, using gcc, both + /dev/kmem-based and PSTAT-based + linux Linux 2.1.72 and above for x86-based systems + netbsd NetBSD 1.[456], 2.x and 3.x + openbsd OpenBSD 2.[89] and 3.[0-9] + osr SCO OpenServer Release 5.0.6, using the C compiler + from the SCO developer's kit + osrgcc SCO OpenServer Release 5.0.6, using gcc + osr6 SCO Openserver 6.0.0, using the SCO C compiler + sco SCO OpenServer Release 5.0.6, using the C compiler + from the SCO developer's kit + scogcc SCO OpenServer Release 5.0.6, using gcc + solaris Solaris 2.x, 7, 8, 9 and 10 using gcc + solariscc Solaris 2.x, 7, 8, 9 and 10 using Sun's cc + unixware SCO|Caldera UnixWare 7.1.4 + uw SCO|Caldera UnixWare 7.1.4 + +If you have an earlier version of a dialect not named in the above +list, lsof may still work on your system. I have no way of testing +that myself. Try configuring for the named dialect -- e.g., if +you're using Solaris 2.1, try configuring for Solaris 2.5.1. + +After you have configured lsof for your UNIX dialect and have +selected options via the Customize script (See the The Customize +Script section.) , use the make command to build lsof -- e.g., + + $ make + + +Other Configure Script Options +============================== + +There are three other useful options to the Configure script besides +the dialect abbreviation: + + -clean may be specified to remove all traces of + a dialect configuration, including the + Makefile, symbolic links, and library files. + + -h may be specified to obtain a list of + -help Configure options, including dialect + abbreviations. + + -n may be specified to stop the Configure + script from calling the Customize and + Inventory scripts. + + Caution: -n also suppresses the AFSConfig + step. + + + +Environment Variables +===================== + +Lsof configuration, building, and execution may be affected by +environment variable settings. See the Definitions That Affect +Compilation section in the 00PORTING file, the General Environment +Variables section in the 00XCONFIG file, the Dialect-Specific +Environment Variables section in the 00XCONFIG file, and the +Environment Variables Affecting the Configure Script section of +this file for more information. + +Note in the General Environment Variables section of the 00XCONFIG +file that there are five environment variables that can be used to +pre-define values in lsof's -v output: LSOF_BLDCMT, LSOF_HOST, +LSOF_LOGNAME, LSOF_SYSINFO, and LSOF_USER. + + +Security +======== + +If the symbol HASSECURITY is defined, a security mode is enabled, +and lsof will allow only the root user to list all open files. +Non-root users may list only open files whose processes have the +same user ID as the real user ID of the lsof process (the one that +its user logged on with). + +However, if HASNOSOCKSECURITY is also defined, anyone may list +anyone else's open socket files, provided their listing is enabled +with the "-i" option. + +Lsof is distributed with the security mode disabled -- HASSECURITY +is not defined. (When HASSECURITY is not defined, the definition +of HASNOSOCKSECURITY has no meaning.) You can enable the security +mode by defining HASSECURITY in the Makefile or in the machine.h +header file for the specific dialect you're using -- e.g. +dialects/aix/machine.h. + +The Customize script, run by Configure when it has finished its +work, gives you the opportunity to define HASSECURITY and +HASNOSOCKSECURITY. (See the The Customize Script section.) + +The lsof -h output indicates the state HASSECURITY and HASNOSOCKSECURITY +had when lsof was built, reporting: + + "Only root can list all files;" + if HASSECURITY was defined and HASNOSOCKSECURITY wasn't + defined; + + "Only root can list all files, but anyone can list socket files." + if HASSECURITY and HASNOSOCKSECURITY were both defined; + + "Anyone can list all files;" + if HASSECURITY wasn't defined. (The definition of + HASNOSOCKSECURITY doesn't matter when HASSECURITY isn't + defined.) + +You should carefully consider the implications of using the default +security mode. When lsof is compiled in the absence of the +HASSECURITY definition, anyone who can execute lsof may be able to +see the presence of all open files. This may allow the lsof user +to observe open files -- e.g., log files used to track intrusions +-- whose presence you would rather not disclose. + +As distributed, lsof writes a user-readable and user-writable device +cache file in the home directory of the real user ID executing +lsof. There are other options for constructing the device cache file +path, and they each have security implications. + +The 00DCACHE file in the lsof distribution discusses device cache +file path construction in great detail. It tells how to disable +the various device cache file path options, or how to disable the +entire device cache file feature by removing the HASDCACHE definition +from the dialect's machine.h file. There is also information on +the device cache file feature in the 00FAQ file. (The 00DCACHE +and 00FAQ files are part of the lsof distribution package.) + +The Customize script, run by Configure after it has finished its +work, gives you the opportunity to change the compile-time options +related to the device cache file. (See The Customize Script +section.) + +Since lsof may need setgid or setuid-root permission (See the Setgid +Lsof Dialects and Setuid-root Lsof Dialects sections.), its security +should always be viewed with skepticism. Lest the setgid and +setuid-root permissions allow lsof to read kernel name list or +memory files, declared with the -k and -m options, that the lsof +user can't normally access, lsof uses access(2) to establish its +real user's authority to read such files when it can't surrender +its power before opening them. This change was added at the +suggestion of Tim Ramsey. + +Lsof surrenders setgid permission on most dialects when it has +gained access to the kernel's memory devices. There are exceptions +to this rule, and some lsof implementations need to run setuid-root. +(The Setgid Lsof Dialects and Setuid-root Lsof Dialects sections +contains a list of lsof implementations and the permissions +recommended in the distribution's Makefiles.) + +The surrendering of setgid permission is controlled by the WILLDROPGID +definition in the dialect machine.h header files. + +In the end you must judge for yourself and your installation the +risks that lsof presents and restrict access to it according to +your circumstances and judgement. + + +Run-time Warnings +================= + +Lsof can issue warning messages when it runs -- e.g., about the +state of the device cache file, about an inability to access an +NFS file system, etc. Issuance of warnings are enabled by default +in the lsof distribution. + +Issuance or warnings may be disabled by default by defining +WARNINGSTATE in the dialect's machine.h. The Customize script may +also be used to change the default warning message issuance state. +(See The Customize Script section.) + +The ``-w'' option description of the ``-h'' option (help) output +will indicate the default warning issuance state. Whatever the +state may be, it can be reversed with ``-w''. + + +Device Access Warnings +====================== + +When lsof encounters a /dev (or /devices) directory, one of its +sub-directories, or one of their files that it cannot access with +opendir(3) or stat(2), it issues a warning message and continues. +Lsof will be more likely to issue such a warning when it has been +installed with setgid() permission; it won't have +trouble if it has been installed with setuid(root) permission or +is being run under the root login. + +The lsof caller can inhibit or enable the warning with the -w +option, depending on the issuance state of run-time warnings. (See +the Run-time Warnings section.) + +The warning messages do not appear when lsof obtains device +information from a device cache file that it has built and believes +to be current or when warning message issuance is disabled by +default. (See the "Caches -- Name and Device" section for more +information on the device cache file.) + +The lsof builder can inhibit the warning by disabling the definition +of WARNDEVACCESS in the dialect's machine.h or disable all warnings +by defining WARNINGSTATE. WARNDEVACCESS is defined by default for +most dialects. However, some dialects have some device directory +elements that are private -- e.g., HP-UX -- and it is more convenient +for the lsof user if warning messages about them are inhibited. + +Output from lsof's -h option indicates the status of WARNDEVACCESS. +If it was defined when lsof was compiled, this message will appear: + + /dev warnings = enabled + +If WARNDEVACCESS was not defined when lsof was compiled, this +message will appear instead: + + /dev warnings = disabled + +The Customize script, run by Configure after it has finished its +work, gives you the opportunity to change the WARNDEVACCESS +definition. (See The Customize Script section.) + + +NFS Blocks +========== + +Lsof is susceptible to NFS blocks when it tries to lstat() mounted +file systems and when it does further processing -- lstat() and +readlink() -- on its optional file and file system arguments. + +Lsof tries to avoid being stopped completely by NFS blocks by doing +the lstat() and readlink() functions in a child process, which +returns the function response via a pipe. The lsof parent limits +the wait for data to arrive in the pipe with a SIGALRM, and, if +the alarm trips, terminates the child process with a SIGINT and a +SIGKILL. + +This is as reliable and portable a method for breaking NFS deadlocks +as I have found, although it still fails under some combinations +of NFS version, UNIX dialect, and NFS file system mount options. +It generally succeeds when the "intr" or "soft" mount options are +used; it generally fails when the "hard" mount option is used. + +When lsof cannot kill the child process, a second timeout causes +it to stop waiting for the killed child to complete. While the +second timeout allows lsof to complete, it may leave behind a hung +child process. Unless warnings are inhibited by default or with +the -w option, lsof reports the possible hung child. + +NFS block handling was updated with suggestions made by Andreas +Stolcke. Andreas suggested using the alternate device numbers that +appear in the mount tables of some dialects when it is not possible +to stat(2) the mount points. + +The -b option was added to direct lsof to avoid the stat(2) and +readlink(2) calls that might block on NFS mount points and always +use the alternate device numbers. If warning message issuance is +enabled and you don't want warning messages about what lsof is +doing, use the -w option, too. + +The -O option directs lsof to avoid doing the potentially blocking +operations in child processes. Instead, when -O is specified, lsof +does them directly. While this consumes far less system overhead, +it can cause lsof to hang, so I advise you to use -O sparingly. + + +Caches -- Name and Device +========================== + +Robert Ehrlich suggested that lsof obtain path name components for +open files from the kernel's name cache. Where possible, lsof +dialect implementations do that. The -C option inhibits kernel +name cache examination. + +Since AFS apparently does not use the kernel's name cache, where +lsof supports AFS it is unable to identify AFS files with path name +components. + +Robert also suggested that lsof cache the information it obtains +via stat(2) for nodes in /dev (or /devices) to reduce subsequent +running time. Lsof does that, too. + +In the default distribution the device cache file is stored in +.lsof_hostname, mode 0600, in the home directory of the login of +the user ID that executes lsof. The suffix, hostname, is the first +component of the host's name returned by gethostname(2). If lsof +is executed by a user ID whose home directory is NFS-mounted from +several hosts, the user ID's home directory may collect several +device cache files, one for each host from which it was executed. + +Lsof senses accidental or malicious damage to the device cache file +with extensive integrity checks, including the use of a 16 bit CRC. +It also tries to sense changes in /dev (or /devices) that indicate +the device cache file is out of date. + +There are other options for forming the device cache file path. +Methods the lsof builder can use to control and employ them are +documented in the separate 00DCACHE file of the lsof distribution. + + +Raw Sockets +=========== + +On many UNIX systems raw sockets use a separate network control +block structure. Display of files for applications using raw +sockets -- ping, using ICMP, for example -- need special support +for displaying their information. This support is so dialect-specific +and information to provide it so difficult to find that not all +dialect revisions of lsof handle raw sockets completely. + + +Other Compile-time Definitions +============================== + +The machine.h and dlsof.h header files for each dialect contains +definitions that affect the compilation of lsof. Check the +Definitions That Affect Compilation section of the 00PORTING file +of the lsof distribution for their descriptions. (Also see The +Customize Script section.) + + +The AFSConfig Script +==================== + +Lsof supports AFS on some combinations of UNIX dialect and AFS +version. See the AFS section of this document for a list of +supported combinations. + +When configuring for dialects where AFS is supported, the Configure +script calls the AFSConfig script to determine the location of AFS +header files and the AFS version. Configure will not call AFSConfig, +even for the selected dialects, unless the file /usr/vice/etc/ThisCell +exists. + +The AFS header file location is recorded in the AFSHeaders file; +version, AFSVersion. Once these values have been recorded, Configure +can be told to skip the calling of AFSConfig by specifying its +(Configure's) -n option. + + +The Inventory Script +==================== + +The lsof distribution contains a script, called Inventory, that +checks the distribution for completeness. It uses the file 00MANIFEST +in the distribution as a reference point. + +After the Configure script has accepted the dialect abbreviation, +it normally calls the Inventory script to make sure the distribution +is complete. + +After Inventory has run, it creates the file ".ck00MAN" in the +top-level directory to record for itself the fact that the inventory +has been check. Should Inventory be called again, it senses this +file and asks the caller if another check is in order, or if the +check should be skipped. + +The -n option may be supplied to Configure to make it bypass the +calling of the Inventory script. (The option also causes Configure +to avoid calling the Customize script.) + +The lsof power user may want to define (touch) the file ".neverInv". +Configure avoids calling the Inventory script when ".neverInv" +exists. + + +The Customize Script +==================== + +Normally when the Configure script has finished its work, it calls +another shell script in the lsof distribution called Customize. +(You can tell Configure to bypass Customize with its -n option.) + +Customize leads you through the specification of these important +compile-time definitions for the dialect's machine.h header file: + + HASDCACHE device cache file control + HASENVDC device cache file environment + variable name + HASPERSDC personal device cache file path + format + HASPERSDCPATH name of environment variable that + provides an additional component + of the personal device cache file + path + HASSYSDC system-wide device cache file path + HASKERNIDCK the build-time to run-time kernel + identity check + HASSECURITY the security option + HASNOSOCKSECURITY the open socket listing option when + HASSECURITY is defined + WARNDEVACCESS /dev (or /devices) warning message + control + WARNINGSTATE warning message issuance state + +The Customize script accompanies its prompting for entry of new +values for these definitions with brief descriptions of each of +them. More information on these definitions may be found in this +file or in the 00DCACHE and 00FAQ files of the lsof distribution. + +You don't need to run Customize after Configure. You can run it +later or you can edit machine.h directly. + +The -n option may be supplied to Configure to make it bypass the +calling of the Customize script. (The option also causes Configure +to avoid calling the Inventory script.) + +The lsof power user may want to define (touch) the file ".neverCust". +Configure avoids calling the Customize script when ".neverCust" +exists. + +Customize CAUTION: the Customize script works best when it is +applied to a newly configured lsof source base -- i.e., the machine.h +header file has not been previously modified by the Customize +script. If you have previously configured lsof, and want to rerun +the Customize script, I recommend you clean out the previous +configuration and create a new one: + + $ Configure -clean + $ Configure + ... + Customize in response to the Customize script prompts. + + +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, and even within a version as vendor patches are applied. + +DON'T TRY TO USE AN LSOF BINARY, COMPILED FOR ONE UNIX OS VERSION, +ON ANOTHER. VENDOR PATCHES INFLUENCE THE VERSION IDENTITY. + +On some UNIX dialects lsof versions may be even more restricted by +architecture type. + +The bottom line is use lsof where you built it. If you intend to +use a common lsof binary on multiple systems, make sure all systems +run exactly the same OS version and have exactly the same patches. + + +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. + + +License +======= + +Lsof has no license. Its use and distribution are subject to these +terms and conditions, found in each 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. + */ + + +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 BUG REPORTS ABOUT LSOF TO THE UNIX DIALECT OR DIALECT +OPTION VENDOR. + +At worst such bug reports will confuse the vendor; at best, the vendor +will forward the bug report to me. + +PLEASE DON'T SEND BUG REPORTS ABOUT LSOF BINARIES BUILT OR DISTRIBUTED +BY SOMEONE ELSE, BECAUSE I CAN'T SUPPORT THEM. + +Before you send me a bug report, please do these things: + + * Make sure you try the latest lsof revision. + + + Download the latest revision from: + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof + + + Verify the signatures of what you have downloaded; + + + While connected to lsof.itap.purdue.edu, check for patches: + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/patches + + + If patches exist, install them in the latest revision + you just downloaded. Then build the latest revision and + see if it fixes your bug. + + * If you're having trouble compiling lsof with gcc, try the + UNIX dialect vendor's compiler. I don't have access to gcc on + all test systems, so my support for it is hit-and-miss, and so + is my ability to respond to gcc compilation problem reports. + + * Check the lsof frequently asked questions file, 00FAQ, + to see if there's a question and answer relevant to your + problem. + + * Make sure you're running the lsof you think you are by + checking the path to it with which(1). When in doubt, use an + absolute path to lsof. Make sure that lsof binary has + sufficient permissions to do what you ask, including internal + permissions given it (e.g., restrictions on what files lsof may + report for whom) during its build. + +When you send a bug report, make sure you include output from your +running of lsof's Configure script. If you were able to compile a +running lsof, please also include: + + * Output from which(1) that shows the absolute path to the + lsof binary in question; + + * Output from running lsof with its -h and -v options at + lsof's absolute path; + + * Output from "ls -l" directed to lsof's absolute path. + +If you weren't able to compile a running lsof, please send me: the +compiler error output; identification of the lsof revision you're using +(contents of the lsof version.c file); identification of your system +(full uname output or output from whatever other tool identifies the +system); and compiler identification (e.g., gcc -v output). + +Either set of output will help me understand how lsof was configured +and what UNIX dialect and lsof revision is involved. + +Please send all bug reports, requests, etc. to me via e-mail at +. Make sure "lsof" appears in the "Subject:" line so +my e-mail filter won't classify your letter as Spam. + + +The 00FAQ File +============== + +The lsof distribution contains an extensive frequently asked +questions file on lsof features and problems. I recommend you +consult it before sending me e-mail. Use your favorite editor or +pager to search 00FAQ -- e.g., supplying as a search argument some +fixed text from an lsof error message. + + +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. + + +Field Output Example Scripts +============================ + +Example AWK and Perl 4 or 5 scripts for post-processing lsof field +output are locate in the scripts sub-directory of the lsof distribution. +The scripts sub-directory contains a 00README file with information +about the scripts. + + +Field Output C Library +====================== + +The lsof test suite (See "Testing Lsof."), checks basic lsof +operations using field output. The test suite has its own library +of C functions for common test program operations, including +processing of field output. The library or selections of its +functions could be adapted for use by C programs that want to +process lsof field output. See the library in the file LTlib.c +in the tests/ sub-directory + + +Testing Lsof +============ + +Lsof has an automated test suite in the tests/ sub-directory that +can be used to test some basic lsof features -- once lsof has been +configured and made. Tests are arranged in three groups: basic +tests that should run on all dialects; standard tests that should +run on all dialects; and optional tests that may not run on all +dialects or may need special resources to run. See 00TEST for more +information.) + +CAUTION!!! Before you attempt to use the test suite make sure that +the lsof you want to test can access the necessary kernel resources +-- e.g., /dev/mem, /dev/kmem, /proc, etc. Usually you want to test +the lsof you just built, so this is an important check. (See +00TEST.) + +To run the basic and standard tests, using the lsof in the parent +directory of tests/, do this: + + $ cd tests + $ make test + or $ make std + or $ make standard + +The basic and standard tests may be run as silently as possible, +using the lsof in the parent directory of tests/, with: + + $ cd tests + $ make auto + +This is the "automatic" test mode, designed for use by scripts that +build lsof. The caller is expected to test the make exit code to +determine if the tests succeeded. The caller should divert standard +output and standard error to /dev/null to suppress make's error +exit message. + +The optional tests may be run, using the lsof in the parent directory +of tests/, with: + + $ cd tests + $ make opt + or $ make optional + +It's possible to execute individual tests, too. See the 00TEST file +of this distribution for more information on the tests, what they +do, and how to run and possibly customize each test. + +It's possible to run the tests, using an lsof other than the one +in the parent directory of /tests, too. See 00TEST for information +about using the LT_LSOF_PATH environment variable to do that. + + +============= +Dialect Notes +============= + + +AFS +=== + +Lsof recognizes AFS files on the following combinations of UNIX +dialect and AFS versions: + + AIX 4.1.4 (AFS 3.4a) + Linux 1.2.13 (AFS 3.3) + Solaris 2.6 (AFS 3.4a) + Ultrix 4.2 RISC (AFS 3.2b) (no longer available) + +Lsof has not been tested under other combinations -- e.g. HP-UX +10.10 and AFS 3.4a -- and probably won't even compile there. Often +when a UNIX dialect version or AFS version changes, the new header +files come into conflict, causing compiler objections. + + +AIX +=== + +Specify the aix Configure abbreviation for AIX 4.1.[45], 4.2[.1], +4.3[.123], 5L, and 5.[123]. + +Specify aixgcc on AIX above 4.1 to use the gcc compiler. (Gcc can't be +used to compile lsof on AIX 4.1 and below because of kernel structure +alignment differences between it and xlc.) Gcc results sometimes +depend on the version of the gcc compiler that is used. + +Compilation of lsof with gcc on AIX 4.3[.123], 5L, and 5.[123] has been +sparsely tested with varying degrees of success: it has been reported +to succeed on AIX 4.3.3 and 32 bit Power AIX 5.1; to fail on ia64 AIX +5.1 and 64 bit Power AIX 5.1; and to succeed on 32 and 64 bit Power AIX +5.2. Lsof compilation with gcc hasn't been tested on AIX 5.3. + +At revision 4.61 and above lsof is configured and built to match the +bit size of the kernel of Power architecture AIX 5.1 systems. Lsof +binaries built for 32 and 64 bit kernels are not interchangeable. See +00FAQ for more information. + +The Configure script uses /usr/bin/oslevel to determine the AIX version +for AIX less than 5 and ``uname -rv'' for AIX 5 and higher. If +/usr/bin/oslevel isn't executable on AIX less than 5, the Configure +script issues a warning message and uses ``uname -rv'' to determine the +AIX version. + +When Configure must use ``uname -rv'' on AIX less than 5 to determine +the AIX version, the result will lack a correct third component -- +e.g., the `4' of ``4.1.4''. If your AIX less than 5 system lacks lacks +an executable oslevel, I suggest you edit the Configure-produced +Makefile and complete the _AIXV definition in the CFGF string. + +By default lsof avoids using the kernel's readx() function, causing +it to be unable to report information on some text and library file +references. The ``-X'' option allows the lsof user to ask for the +information readx() supplies. + +Lsof avoids readx() to avoid the possibility of triggering a kernel +problem, known as the Stale Segment ID kernel bug. Kevin Ruderman +reported this bug to me. The bug shows up when the kernel's +dir_search() function hangs, hanging the application process that +called it so completely that the application process can neither +be killed nor stopped. The hang is the consequence of another +process (perhaps lsof) making legitimate use of the kernel's readx() +function to access the kernel memory that dir_search() is examining. +IBM has indicated they have no plans to fix the bug. + +A fuller discussion of this bug may be found in the 00FAQ file of +the lsof distribution. There you will find a description of the +Stale Segment ID bug, the APAR on it, and a discussion of the +sequence of events that exposes it. + +I added the ``-X'' function so you can tell lsof to use readx(), +but if you use ``-X'', you should be alert to its possibly serious +side effects. Although readx() is normally disabled, its state is +controlled with the HASXOPT, HASXOPT_ROOT, and HASXOPT_VALUE +definitions in dialects/aix/machine.h, and you can change its +default state by changing those definitions. You can also change +HASXOPT_ROOT via the Customize script. + +You can also compile lsof with readx() use permanently enabled or +disabled -- see the comments about the definitions in the +dialects/aix/machine.h header file. You may want to permanently +disable lsof's use of readx() if you plan to make lsof publicly +executable. You can also restrict -X to processes whose real UID +is root by defining HASXOPT_ROOT. + +I have never seen lsof cause the Stale Segment ID bug to occur and +haven't had a report that it has, but I believe there is a possibility +it could. + +AFS support for AIX was added with help help from Bob Cook and Jan +Tax who provided test systems. + +Henry Grebler and David J. Wilson helped with lsof for AIX 4.2. + +Bill Pemberton provided an AIX 4.3 test system. Andrew Kephart +and Tom Weaver provided AIX 4.3 technical assistance. Niklas +Edmundsson did 4.3.1 testing. Doug Crabill provided an AIX 4.3.2 +test system. Jeff W. Stewart provided an AIX 4.3.3 test system. + +The SMT file type for AIX 4.1.[45], 4.2[.1], and 4.3[.12] is my +fabrication. See the 00FAQ file more information on it. + +Loc Le and Nasser Momtaheni of IBM provided test systems for AIX 5L and +5.1. Lsof for AIX 5L and 5.1 needs setuid-root permission to process +the -X option on systems whose architecture type is ia64. + +Dale Talcott of Purdue provided AIX 5.1 and 5.2 test systems. Dale and +John Jackson of Purdue provided an AIX 5.3 test system. + + +Apple Darwin +============ + +The Apple Darwin port was provided by Allan Nathanson for version +1.2. Allan also arranged for access to a test system for maintenance +and regression testing. Dale Talcott provided a test system, too. + +Allan supplied patches for updates to 1.4, 5.x, 6.x, 7.x and 8.x. + + +BSDI BSD/OS +=========== + +As of lsof revision 4.77 support for BSDI BSD/OS has been +discontinued. Lsof revision 4.76 with BSDI BSD/OS support may be found +on lsof.itap.purdue.edu in pub/tools/unix/lsof/src. + + +FreeBSD +======= + +Bill Bormann of Purdue University provided access to several FreeBSD +test systems. Ade Barkah, John Clear, Ralph Forsythe, Michael +Haro, Kurt Jaeger, and William McVey have also provided FreeBSD +test systems. + +The FreeBSD distribution header files are augmented by header files +in the dialects/freebsd/include directory. + +Larry Rosenman maintains the lsof FreeBSD port package. + + +HP-UX +===== + +Lsof has two HP-UX bases: /dev/kmem for HP-UX 11.0 and earlier; +and PSTAT for HP-UX 11.11 and later. The lsof Configure script +will pick the appropriate base. + +To use the CCITT x.25 socket support for HP-UX, you must have the +x.25 header files in /etc/conf/x25 + +Pasi Kaara helped with the HP-UX port, especially with its CCITT +x.25 socket support. + +Richard Allen provided HP-UX 10.x and 11.x test systems, as did +Mark Bixby, and Elias Halldor Agustsson. Marc Winkler helped test +the 10.20 port. Richard J. Rauenzahn provided a 64 bit HP-UX 11 +test system and an HP-UX 11.11 development system. + +AFS support for HP-UX was added thanks to help from Chaskiel Moses +Grundman, who provided a test system. + +The /dev/kmem-based HP-UX 11.00 support is extremely fragile. It +depends on privately developed kernel structure definitions. (See +.../dialects/hpux/hpux11 for the header files making the definitions.) +Those header files and their definitions will not be updated by +HP-UX 11.00 patches, making it likely that any patch changing a +kernel structure critical to lsof will break lsof in some way. + +It's possible to build a 64 bit lsof for 64 bit HP-UX 11.00 with +gcc, but you must have a gcc compiler capable of producing 64 bit +executables. See the 00FAQ file for more information. + +The PSTAT-based lsof for HP-UX 11.11 and later is much more solid. +I am indebted to the vision of HP for providing an lsof kernel API +through the PSTAT implementation. Specifically I appreciate the +help of HP staff members Carl Davidson, Louis Huemiller, Rich +Rauenzahn, and Sailu Yallapragada that made PSTAT-based HP-UX lsof +possible. + + +IPv6 +==== + +Lsof has IPv6 support that has been tested for these UNIX dialects: +AIX 4.3.x; Apple Darwin 5.[12] and 6.0; the INRIA and KAME FreeBSD IPv6 +implementations; PSTAT-based HP-UX; /proc-based Linux; the INRIA and +KAME NetBSD implementations; and Solaris 8 and 9. Lsof has IPv6 +support that hasn't been tested for: OpenBSD (KAME); OpenUNIX 8; Tru64 +Unix 5.[01]; and UnixWare 7.1.[34]. + +Please let me know if your UNIX dialect has IPv6 support and I'll +see if it can be supported by lsof. + + +Linux +===== + +Tim Korb, Steve Logue, Joseph J. Nuspl Jr., and Jonathan Sergent +have provided Linux test systems. + +Michael Shields helped add and test automatic handling of ELF/COFF +form names in /System.map, Marty Leisner and Keith Parks have helped +test many lsof revisions. Marty has provided valuable suggestions, +Linux hints, and code, too. + +The 00FAQ file gives some Linux tips, including information on +coping with system map file problems. + +To determine the state of the Linux 2.1.x C library lseek() function, +the lsof Configure script runs a test program that must have +permission to read /dev/kmem. The test determines if the lseek() +function properly handles kernel offsets, which appear to be negative +because their high order bit is set. If the lseek() test reveals +a faulty lseek(), Configure activates the use of a private lseek() +function for kernel offset positioning. See the Linux problems +section of the 00FAQ file of the lsof distribution for more +information. + + +NetBSD +====== + +Greg Earle and Paul Kranenburg have assisted with the NetBSD ports. +Paul has provided test systems. Ray Phillips provided a NetBSA +Alpha test system. Andrew Brown also provided a test system. + +The NetBSD dialect version of lsof is compiled using the dialect +sources in the netbsd dialect sub-directory. + + +OpenBSD +======= + +David Mazieres has provided OpenBSD test systems. The OpenBSD +dialect version of lsof is compiled using the dialect sources it +shares with NetBSD in the openbsd dialect sub-directory. + +Kenneth Stailey has provided OpenBSD testing and advice. + +John Dzubera (Zube) reports, "lsof 4.33 compiles and runs on OpenBSD +2.3 for the pmax architecture (decstation 3100)." + +I have not tested lsof on OpenBSD 3.8, but David Mazieres reports +revision 4.76 worked on OpenBSD 3.8. + + +Pyramid DC/OSx and Reliant UNIX +=============================== + +As of lsof revision 4.52 support for all Pyramid dialects has been +discontinued. Lsof revision 4.51 with Pyramid support may be +obtained upon request. Send the request to abe@purdue.edu. + +These two UNIX dialects are very similar and share dialect-specific +source files from the pyramid sub-directory. + +The Reliant Unix Pyramid C compiler issues warning messages that +I haven't found a convenient way to suppress. You can ignore +warning messages about casts and conversions that lose bits. The +message "warning: undefining __STDC__" is intentionally caused by +the lsof MkKernOpts configuration script to suppress warning messages +about cast and conversion problems in standard system header files, +such as and . + +Bruce Beare and Kevin Smith provided test systems. + + +Caldera OpenUNIX +================ + +Larry Rosenman provided an OpenUNIX 8 test system. Matthew Thurmaier +provided technical assistance, along with these people from Caldera: +Jack Craig, Robert Lipe, and Bela Lubkin. + +Robert Lipe supplied changes to lsof for OpenUNIX 8.0.1. Those +changes were also incorporated in UnixWare 7.1.3 when it became +the release name for OpenUNIX 8.0.1. + +Support for lsof on OpenUNIX ended at lsof revision 4.74. The last +lsof revision, 4.74, tested on OpenUNIX, may be found at the lsof +"home" ftp site, lsof.itap.purdue.edu, in pub/tools/unix/lsof/OLD/src. + + +SCO OpenServer +============== + +Dion Johnson, Bela Lubkin, and Nathan Peterson of SCO gave me copies +of SCO OpenServer and the SCO OpenServer Development System 3.0 +and provided technical advice for the lsof port. + +Hugh Dickins, Bela Lubkin, Craig B. Olofson, and Nathan Peterson +provided version 5.0 and gave technical advice for porting lsof to +it. Bela provided the 5.0.4 changes. D. Chris Daniels provided +a 5.0.4 test system, Lee Penn provided one for 5.0.5, and John +Dubois for 5.0.6. + +The header file was accidentally omitted from some SCO +OpenServer Development System releases. The Configure script will +sense its absence and substitute an equivalent from the BSD +distribution. The BSD and the header file +it includes are located in the dialects/os/include sub-directory +tree. + +To compile lsof from its distribution sources you must have the +TCP/IP and NSF headers in /usr/include. While those are optional +OpenServer packages, I have access to no system that doesn't have +them, so I'm unable to build lsof for such a configuration. However, +it should be possible to modify the lsof Configure script and +sources so lsof would compile and work without those optional +packages. + +If you have an OpenServer system configured without the TCP/IP and +NFS packages, and want to tackle the job of building lsof for it, +contact me via e-mail at . I'll identify the +Configure script, header file, and source file changes you will +need to make. (Caution: this is not a simple task, or I would have +already done it.) + +The optional osrgcc and scogcc Configure abbreviations construct +Makefiles for compiling lsof with gcc. + +The UnixWare 7.1.4 sources are used for OpenServer Release 6.0.0. +Hence there is a separate Configure abbreviation for it, "osr6". +Richard of SCO provided a test system and technical assistance. + + +SCO|Caldera UnixWare +============ + +D. Chris Daniels, John Hughes, Ken Laing, Andrew Merril, Lee Penn, and +Matthew Thurmaier provided test systems. Bela Lubkin provided +technical assistance. Larry Rosenman provided 7.1.[34] test systems. + + +Solaris 2.x, 7, 8, 9 and 10 +=========================== + +SEE THE CAUTIONS SECTION OF THIS DOCUMENT. + +The latest Solaris revision of lsof 4 might work under Solaris +2.[1-4] and 2.5[.1] and 7 but hasn't been tested there. I have no +test systems for those Solaris versions. + +Lsof will compile with gcc and the Sun C compiler under Solaris. +If you want to use the Sun compiler, use the solariscc Configure +abbreviation. If you use a gcc version less than 2.8 on Solaris, +make sure the gcc-specific includes have been updated for your +version of Solaris -- i.e., run the gcc fixincludes script. + +Solaris 7, 8, 9 and 10 support for 64 bit kernels depends on a Sun +WorkShop or Forte C compiler version that supports the "-xarch=v9" +flag -- usually 5.0 or greater. Gcc versions 2.95 and above *may* +be configured and built for 64 bit support, but it takes some extra +work, the resulting compiler may be fragile, and the gcc developers +discourage it. I've built 64 bit capable gcc compilers for Solaris +7, 8 and 9 from gcc versions 2.95 through 3.0.1 and produced working +lsof executables with them. More information on 64 bit gcc for +Solaris may be found in the 00FAQ file. + +Solaris 10 ZFS support is questionable, because Sun does not distribute +the ZFS kernel structure definition header files. The lsof Configure +script and source code use some risky work-arounds. ZFS file system +support was made possible with help from Horst Scheuermann. + +Dave Curry and Steve Kirsch provided resources for Solaris 2.x +ports. Casper Dik and Gerry Singleton consulted and provided +valuable assistance. + +Henry Katz, Joseph Kowalski, Charles Stephens, Mike Sullivan, and +Mike Tracy provided technical assistance. + +AFS support was added to Solaris lsof with help from Curt Freeland, +Heidi Hornstein, Michael L. Lewis, Terry McCoy, Phillip Moore, and +Sushila R. Subramanian. + +Casper Dik provided valuable assistance for the Solaris 8 support. + +Sun has graciously provided me access to BETA versions of Solaris +2.5, 2.6, 7, 8, and 9. + +John Dzubera provided Solaris 7 and 8 test systems. + +Mike Miscevic provided Solaris 10 test systems. + + +Ultrix +====== + +As of lsof revision 4.52 support for Ultrix is no longer available, +because I no longer have an Ultrix test system. + +Terry Friedrichsen, Dwight McKay, and Jeffrey Mogul helped me with +this port. + +DECnet support was added to Ultrix lsof with the help of John +Beacom, who kindly provided a test system. The Configure script +decides that DECnet support is available if /usr/lib/libdnet.a and +/usr/include/netdnet/dn.h exist and are readable. + + +Veritas VxFS and VxVM +===================== + +Lsof supports some versions of Veritas VxFS and VxVM on some UNIX +dialects. Consult the lsof Configure script for the specific +dialect, and consult the lsof dialect-specific source files for +the UNIX dialect of interest. Veritas support will usually be +found in a source file named dnode[1-9].c. + +Since Veritas rarely has a version number that can be extracted +with shell commands, lsof doesn't use it. Instead, when lsof +supports Veritas, the Configure script will form compile-time +definitions starting with HASVXFS. Check the lsof 00PORTING +documentation file for more information. + +Lsof Veritas support requires that the supporting Veritas header +files be installed -- e.g., in /usr/include/sys/fs. (The location +will depend in the dialect's header file conventions.) + +Some information on lsof support for Veritas extensions may be +found in the lsof 00DIST file. (The ChangeLog file points to +00DIST.) + +Chris Kordish and Andy Thomas have provided Solaris VxFS test +systems. + + +================================ +User-contributed Dialect Support +================================ + +There are some user-contributed dialect versions of lsof; more +information on them can be found at: + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/contrib + +Check the 00INDEX file there for details. + + +============================ +Dialects No Longer Supported +============================ + +Because I don't have access to test systems, these UNIX dialects +are no longer supported by lsof: + + CDC EP/IX + /dev/kmem-based Linux + MIPS RISC/os + Motorola V/88 + Pyramid DC/OSx + Pyramid Reliant UNIX + Sequent DYNIX + SGI IRIX + SunOS 4.x + Ultrix + UnixWare below 7.0 + +Remnants of the support lsof once provided for these dialects may +be found in: + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/dialects + + +=============== +Installing Lsof +=============== + +The distributed Makefiles do not have actions that will install +lsof. I've come to the conclusion there is no standard for installing +lsof or its man page, so I no longer distribute make rules for +installing them. You should adjust the Makefile for your local +preferences. + +The Makefile does have an install rule that will cause lsof to +compile by virtue of its dependency clause. Some Makefiles also +have a dependency that causes the production of a man page that is +ready to install. However, the actions of the install rule will +not cause the lsof executable or its man page to be installed in +any UNIX system-wide directory. + +Instead, after the compilation and optional man page production +are completed, the install rule will produce a brief description +of what actions you might add to the install rule. The description +will suggest the possible modes, ownerships, permissions, and +destinations your install rule might employ to install the lsof +executable and man page. + +As you form your install rule, keep in mind that lsof usually needs +some type of special permission to do its job. That may be permission +to read memory devices such as /dev/kmem, /dev/mem, or /dev/swap, +or it may be authorization to read entries in the /proc file system. + +Memory device access can usually be provided by setting the modes +of the lsof executable so that its effective group identifier when +it runs is the same as the group that has permission to read the +memory devices -- i.e., it is setgid-group. The privileged group +is usually kmem, sys, or system. + +Don't overlook using ACLs -- e.g., on AIX or Solaris 8 -- to give +lsof permission to access memory devices. ACLs, coupled to a +separate group like kmem, can be safer than giving lsof setgid +authorization to a commonly used system group. + +When lsof needs to read /proc file system entries, it must be +installed with modes that make its effective user identifier root +when it runs -- i.e., it must be setuid-root. If lsof must be +installed setuid-root (only the AIX 5L, PSTAT-based HPUX, and +/proc-based Linux, ports need such power.), then access to memory +devices is automatic (or not needed in the case of /proc-based +Linux). + +Your choice of permissions for lsof may also be affected by your +desire to allow anyone to use it or your need to restrict its usage +to specific individuals. You will have to be guided by local policy +and convention in this case. + +The next two sections, Setgid Lsof Dialect Versions and Setuid-root +Lsof Dialect Versions, list recommended install permissions. + +The system directory where you install the lsof executable is also +open to choice. A traditional place for a tool like lsof is +/usr/local/etc, but recent changes in directory structure organization +suggest that somewhere in /opt may be more suitable. + +Bear one other factor in mind when choosing a location for the lsof +executable -- it usually is a shared executable, requiring access +to shared libraries. Thus, locations like /sbin or /usr/sbin are +probably unsuitable. + +Once you've chosen a location for the executable you may find that +the location for the man page follows -- e.g., if the executable +goes in /usr/local/etc, then the man page goes in /usr/local/man. +If the executable location doesn't imply a location for the man +page, you'll have to let local custom guide you. + + +Setuid-root Lsof Dialect Versions +================================= + +These dialect versions should be installed with setuid-root +permission -- i.e., the lsof binary should be owned by root and +its setuid execution bit (04000) should be set. + + AIX 5L and above for full use of the -X option + Apple Darwin 8.x for Power Macintosh systems + PSTAT-based HP-UX 11.11 and 11.23 + /proc-based Linux (generally 2.1.72 and above) + + +Setgid Lsof Dialect Versions +============================ + +These dialect versions should be installed with setgid permission, +owned by the group that can read kernel memory devices such as +/dev/drum, /dev/kmem, /dev/ksyms, /dev/mem, /dev/swap. ACLs may +be another mechanism (e.g., under AIX or Solaris 8) you can use to +grant read permission to the kernel memory devices. + + AIX 4.1.[45], 4.2[.1], and 4.3[.123] + Apple Darwin 7.x for Power Macintosh systems + FreeBSD 2.1.6, 2.2[.x], 3.x, 4.x, 5.x, [6789].x and 1[012].x + NetBSD 1.[456], 2.x and 3.x + OpenBSD 2.[89] and 3.[0-9] + Caldera OpenUNIX 8 + SCO OpenServer 5.0.[46] + SCO UnixWare 7.0 and 7.1.[0134] + Solaris 2.6, 8, 9 and 10 + Ultrix 4.2 (no longer available) + +==================================== +Porting lsof 4 to a New UNIX Dialect +==================================== + +If you're brave enough to consider this, look at the 00PORTING +file. Please contact me before you start. I might be able to help +you or even do the port myself. + +Don't overlook the contrib/ directory in pub/tools/unix/lsof on my +ftp server, lsof.itap.purdue.edu. It contains user-contributed ports +of lsof to dialects I don't distribute, because I can't test new +revisions of lsof on them. + + +========================= +Quick Start to Using lsof +========================= + +For information on how to get started quickly using lsof, consult +the 00QUICKSTART file of the lsof distribution. It cuts past the +formal density of the lsof man page to provide quick examples of +using lsof to solve common open file display problems. + + +====================== +Cross-configuring Lsof +====================== + +Using environment variables it is possible to Configure (and possibly +build) lsof for one UNIX dialect on a different one -- e.g., you +are running Configure on a Linux 2.3 system and you want to Configure +and build lsof for Linux 2.4. + +See the 00XCONFIG file of the lsof distribution for a discussion +of how to do this. + + +==================================================== +Environment Variables Affecting the Configure Script +==================================================== + +Configure script actions can be modified by introducing values to +the script via environment variables. In many cases the environment +variable values take the place of test operations the Configure +script makes. + +For more information on environment variables that can affect +Configure, consult the 00XCONFIG file of the lsof distribution. +See the General Environment Variables sections for descriptions of +ones that affect all dialects. Consult the Dialect-Specific +Environment Variables section for ones that might affect the dialect +you are trying to configure. + + +Vic Abell +February 14, 2018 diff --git a/00TEST b/00TEST new file mode 100644 index 0000000..047145d --- /dev/null +++ b/00TEST @@ -0,0 +1,1032 @@ + + The Lsof Test Suite + + Contents + + A. Introduction + 1. Test Suite Goals + 2. Not a FAQ + 3. Where have the tests been tested? + B. Test Methodology + 1. Test Limitations + 2. Test Data Base and Scripts + 3. The Makefile + 3.1 The CkTestDB Script + 4. The Lsof Executable and LT_LSOF_PATH + 5. Automated Testing + C. Configure Script Participation + 1. config.cc + 2. config.cflags + 2.1 config.cflags Contents + 3. config.ldflags + 4. config.xobj + D. Cleaning -- Quick or Spotless + E. Test Libraries + 1. LTlib.c + F. The Individual Tests + 1. LTbasic, a Basic Lsof Test + 2. LTbigf, Test Sizes and Offsets for Large + (> 32 bit) Files + 3. LTdnlc, Test the Kernel's Dynamic Name Lookup + Cache + 4. LTlock, Lock Tests + 5. LTnfs, NFS Test + 6. LTnlink, Link Count Test + 7. LTsock, Test IPv4 Sockets + 8. LTszoff, Test Sizes and Offsets for Small + (< 32 bit) Files + 9. LTunix, Test UNIX Domain Sockets + Appendix A, Test Files + Appendix B, Test Validations + Appendix C, Test Failures + + +A. Introduction +=============== + +Lsof has an automated test suite whose components are located in +the tests/ sub-directory of the lsof top-level directory. Configuring, +building and testing lsof can be done with these shell commands: + + $ Configure -n + $ make + $ cd tests + $ make + +That's all there is to it! + +But read on for more dirty details. + +A.1. Test Suite Goals +===================== + +The lsof test suite attempts to test basic lsof features. It does +not promise to test every lsof feature for every supported dialect. +(That's a nearly impossible goal.) + +As a result, the test suite cannot promise that every lsof feature +works as documented. At best the test suite gives some assurance +that basic, standard and some optional lsof features work. + +A.2. Not a FAQ +============== + +One caution: this is not a frequently asked questions (FAQ) file +for the lsof test suite. FAQs on the lsof test suite will be found +in the one and only lsof FAQ in file 00FAQ of the lsof distribution, +or on-line at: + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ + +A.3. Where have the tests been tested? +====================================== + +OK, I just said this isn't an FAQ and here comes a question and +answer that looks like an FAQ. Consider it a very frequently asked +question and indulge me -- let me answer it here. + +The lsof test suite hasn't been tested everywhere it might be +possible to build lsof successfully. That "everywhere" includes +dialect versions -- e.g., Solaris < 2.6 -- to which I no longer +have access. On some dialect versions to which I have access, some +tests won't run because the test system lacks support. + +In "Appendix B, Test Validations" I've tried to list where I compiled +and tested the test suite and information on any tests I was unable +to run. In "Appendix C, Test Failures" I list where the test suite +fails and why it failed. + +A.4 Where are the tests? +======================== + +This is another FAQ whose answer is that the tests are in the tests/ +sub-directory of the main lsof source directory. + + +B. Test Methodology +=================== + +The test suite is made up of individual C programs. Test setup is +performed by the lsof Configure script itself, which writes a set +of dialect configuration files in the tests/ subdirectory. (See +"C. Configure Script Participation.") + +Each program or script performs a specialized tests. Those tests +are described below in "F. The Individual Tests". + +Each test measures lsof functionality by putting a specific lsof +command execution at the end of an in-bound (to the test) pipe. +The caller asks lsof to write its results to the pipe in field +output form. (See the -F option in the lsof man page.) + +Using an in-bound lsof pipe allows the tests to measure a great +deal of lsof functionality, including as an interesting side effect, +the performance of field output. Consequently, there's no special +field output test. + +B.1. Test Limitations +===================== + +One limitation of the tests is that they don't measure lsof formatted +output -- i.e., the output normally see when lsof is run. There +are just too many variants of lsof output produced across the range +of dialects where lsof runs, so field output is a more consistent +way to process lsof output. + +But using field output does mean that the test suite doesn't check +for lsof formatting problems, except in the field output itself. + +B.2. Test Data Base and Scripts +=============================== + +The TestDB file contains a simple data base that describes where +the tests have been validated. Entries are formed from a combination +of the lines in the config.cflags file produced by the lsof Configure +script. The entries can be considered "lsof dialect footprints," +hereafter simply called "dialect footprints" or just "footprints." + +Two shell scripts support TestDB. The first, Add2TestDB, will add +a footprint to TestDB. I don't recommend you use this script. +Mostly it's for my use when I find that the test suite has been +validated on a new dialect. + +It's also possible to add a footprint to TestDB by simply editing +TestDB and pasting into it a copy of the footprint reported by a +failed Makefile rule. I don't generally recommend this be done, +either. + +There are Makefile rules that use (and avoid) the CkTestDB script. +(See "B.3 The Makefile".) + +The default (i.e., "all") Makefile rule uses the CkTestDB script +to look for the footprint in TestDB. If no footprint is found, the +script issues a warning, displays the unfound footprint, and asks +if running the test suite should continue. + +The "auto" Makefile rule also uses CkTestDB, but with a special +call that causes CkTestDB to look in TestDB for the footprint, +report it when it can't be found, and then fail. That CkTestDB +failure causes the "auto" rule to fail, too. + +The "silent" Makefile rule doesn't use CkTestDB to look in TestDB +for the footprint. It runs the standard and basic tests as silently +as possible, then returns a failure or success exit code that +signals the result of the running of the tests. (Use the "silent" +rule carefully, because it will skip proving the tests have previously +run on the dialect.) + +B.3. The Makefile +======================= + +The Makefile runs the tests in the test suite. It has these rules. + + all runs the basic test and the standard tests, + interacting with the caller should the footprint + not be found in TestDB. + + (This is the default rule.) + + auto runs the basic test and the standard tests on a + previously validated system as silently as possible. + + The footprint must be found in TestDB for this rule + to succeed. (See the "silent" rule for one that + avoids checking TestDB.) + + This rule is designed for lsof build scripts that + want a quick noiseless test to make sure what they + built works as it previously did. + + This rule calls CkTestDB in a way that inhibits + its normal go-ahead request. (See "B.2.1 The CkTestDB + Script".) If CkTestDB finds the footprint and all + tests succeed, this rule returns a zero exit code + (success). If the footprint isn't found or if any + test fails, a non-zero exit code (failure) is + returned. + + ckDB calls the CkTestDB script to look for a footprint. + If none is found, the way CkTestDB was called (See + "B.3.1 The CkTestDB Script".) causes it to return + a non-zero exit code (failure) to this rule, and + the rule then returns a non-zero exit code (failure) + itself. + + This rule is used by the "auto" rule. If this rule + succeeds (zero exit code), the "auto" rule then + uses the "silent" rule. + + clean removes test and compiler output. (See the "D. + Cleaning -- Quick or Spotless" section.) + + opt runs the optional tests. + optional + + silent runs the lsof basic and standard tests as silently + as possible (as the "auto" rule does), but without + using CkTestDB to look for a footprint. If all + tests succeed, the rule returns a zero exit code + (success). If any test fails, the rule returns a + non-zero exit code (failure). + + Use the "silent" rule carefully, because it will + skip proving the tests have previously run on the + dialect. + + spotless does what the clean rule does and also removes the + config.* files created by ../Configure. (See the + "D. Cleaning -- Quick or Spotless" section.) + + std runs the basic test and the standard tests. + standard + +The Makefile cleaning rules are further described in "D. Cleaning +-- Quick or Spotless." + +B.3.1 The CkTestDB Script +========================= + +Some Makefile rules (e.g., "all" and "auto") use the CkTestDB script +to make sure the tests have been run previously on the dialect. +CkTestDB does that by looking for the dialect's footprint in TestDB. + +If no footprint is found, and if standard input is a TTY, CkTestDB +asks for a go-ahead signal. If standard input isn't a TTY, CkTestDB +aborts the test run. (See "B.2. Test Data Base and Scripts".) + +The Makefile "silent" rule does not call CkTestDB. use the "silent" +rule carefully, because it will skip proving the tests have previously +run on the dialect. + +B.4. The Lsof Executable and LT_LSOF_PATH +========================================= + +Normally the programs in the test suite use the lsof executable in +their parent directory, ../lsof. Usually that lsof has just been +built and testing it is the next logical step. + +Be careful that ../lsof has sufficient permission to access the +necessary kernel resources -- e.g., /dev/kmem, /dev/mem, /proc, +etc. If it doesn't the tests will fail. (The tests do check to +see if they can open /dev/mem and /dev/kmem for read access if +LT_KMEM is defined in config.cflags and if the path to the lsof +executable is ../lsof.) + +Here are two possible ways you can make sure the lsof being tested +has sufficient permission: 1) use chmod and chgrp to enable its +running and put its path in LT_LSOF_PATH, thus disabling the check +in the tests for kernel memory access; or 2) run the tests (and +hence the lsof being tested) under a login that has sufficient +permission -- e.g., is in a group that can read /dev/kmem. + +You can direct the tests to use a different lsof executable by +specifying its path in the LT_LSOF_PATH environment variable. To +test an lsof executable already installed in /usr/local/etc -- +provided that lsof is at revision 4.63 or higher -- do this: + + $ LT_LSOF_PATH=/usr/local/etc/lsof + $ export LT_LSOF_PATH + $ cd .../lsof_/tests + $ make + +When you specify an alternate executable path via LT_LSOF_PATH, +that also prevents the tests from checking to see if they have +kernel memory access. + +B.5 Automated Testing +===================== + +Normally the lsof test suite is wordy and may require interaction. +When you want to avoid those interferences, use the Makefile "auto" +or "silent" rules. (See the description of the "auto" and "silent" +rules in "B.3 The Makefile".) + +The footprint must be present in TestDB in order to use the "auto" +rule. If it is not, the "auto" rule will fail and report the +missing footprint. Footprints in TestDB proclaim that the tests +have previously succeeded on the dialect. + +The footprint need not be present in TestDB in order to use the +"silent" rule. Use the "silent" rule carefully, because it will +skip proving the tests have previously run on the dialect. + + +C. Configure Script Participation +================================= + +An important step in setting up the test suite is performed by the +Configure script in the lsof home directory (the parent to tests/.) + +Configure writes four files in tests/ that describe how the tests +are to be compiled, configured and loaded. The files also describe +options that Configure selected that are important to the test +suite. + +C.1. config.cc +============== + +This file, config.cc, contains the name of or the path to the C +compiler used to compile lsof. The Makefile uses this file in +place of the standard make(1) CC string with a shell in-place +execution statement -- i.e., `cat config.cc`. + +If the LSOF_CC environment variable is supplied to the lsof Configure +script, its value will appear in the config.cc file. + +C.2. config.cflags +================== + +This file, config.cflags, contains C compiler flags that Makefile +uses to compile the C programs in the test suite. As with the +compiler file, config.cc, the make rules incorporate the contents +of this file into C compiler options with `cat config.cflags`. + +This file is also used by the Add2TestDB and CkTestDB shell scripts +to build and match footprints. (See "B.2. Test Data Base and +Scripts.") + +C.2.1 config.cflags Contents +============================ + +The config.cflags file may contain the following C compiler flags. + + + -DLT_AIXA is present if lsof was built for AIX. + It contains the AIX architecture flag. + (See the lsof Configure script or + dialects/aix/dlsof.h for more information + on the AIX architecture flag.) + + -DLT_BIGF is present if lsof was built for a dialect + that has large file (sizes and offsets > + 32 bits). + + -DLT_CC is present if the lsof compiler is cc. + + -DLT_DEV64 is present if the FreeBSD dialect uses a 64 + devite type. + + + -DLT_DIAL_ always ends in (the part) the + "canonical" -- i.e., usually the most + common abbreviation by which the dialect + is known. + + Example: -DLT_DIAL_solaris + + -DLT_GCC is present if the lsof compiler is gcc. + + -DLT_K64 is present if lsof has been built for a + 64 bit kernel + + -DLT_KMEM is present if lsof has been built to + use /dev/kmem to obtain kernel values. + + -DLT_VERS= contains the version number for the + dialect, as used in lsof pre-processor + tests. + + Example for Solaris 10: -DLT_VERS=100000 + + -DLT_VPATH is present if the dialect has the v_path + member in the vnode structure (e.g., some + versions of Solaris 10). + +The config.cflags file may also contain dialect-specific compiler +flags needed to activate a specific feature on the dialect. For +example, for HP-UX config.cflags might contain: + + -D_LARGEFILE64_SOURCE This compiler flag enables the use of + large-file system library functions + --e.g., open64(). + + The lsof Configure script stanzas for + the dialects select these options. + + +C.3. config.ldflags +=================== + +This file, config.ldflags, contains the dialect loader flags -- +i.e., the equivalent to make(1) LFLAGS -- for loading the test +programs. + +Example for Solaris: -lsocket this adds the socket library + to the loading of the lsof + test programs. + +Example for UnixWare: -lsocket -lnsl this adds the socket and + name server libraries to + the loading of the lsof + test programs. + + +C.4. config.xobj +================ + +This file, config.xobj, contains the paths to any extra object +files (.o's) that must be loaded when the test suite C programs +are loaded. Like config.cc and config.cflags, it's incorporated +into the loader statements of the Makefile's rules with `cat +config.xobj`. + +Examples for DEC OSF/1 and NEXTSTEP: + + ../lib/snpf.o this loads the private lsof object file + that contains an snprintf() function. (The + DEC OSF/1 4.0 and NEXTSTEP 3.1 C libraries + don't have snprintf().) + + +D. Cleaning -- Quick or Spotless +================================ + +There are two Makefile rules that clean the tests/ subdirectory -- +"clean" and "spotless". They cause different degrees of cleaning. + + clean a "quick" clean that removes compiled object files, + executables and test files. It does NOT remove + the configuration files that ../Configure and the + config.perl rule wrote. + + spotless cleans out everything clean does -- plus the + configuration files that ../Configure and the + config.perl rule wrote. + + This is the rule used when `./Configure -clean` is + specified. If this rule is used, `../Configure -n + ` and `../make`) must be run again before + the test suite can be used. + + +E. Test Library +=============== + +The lsof test suite provides a C library. + +E.1. LTlib.c +============ + +This is a C library of common functions used by tests. Configured +at compile time by the contents of config.cflags, it uses the single +header file LsofTest.h. LsofTest.h tailors its definitions to the +dialect at compile time, using the LT_DIAL_* definitions in +config.cflags. + +Two particularly useful functions in the library are: ExecLsof(), +which will execute an lsof child process; and RdFromLsof(), which +will read from the in-bound lsof pipe, and decode the fields into +structures that are easy for C programs to process. + +This library is a good model for processing field output in a C +program from an in-bound lsof pipe. + +The source for the library, LTlib.c, contains more documentation. + + +F. The Individual Tests +======================= + +The individual tests are listed in this section. The listings +explain what the tests do, a few errors they might report, and how +to use options and environment variables to customize the tests. + +The test descriptions are listed in this section in alphabetical +order, not in the order they are run by Makefile. + +The Makefile runs the tests in three groups, basic tests, standard +tests, and optional tests. The default make "all" rule runs the +basic and standard tests. (The "standard", "std", and "test" +Makefile rules are synonyms to "all".) If the standard tests succeed, +Makefile suggests running the optional tests with the "opt" (or +"optional") rule. + +The Makefile "auto" and "silent" rules run only the basic and +standard tests. They do not run or suggest you run the optional +tests. + + The basic test: + LTbasic + + Standard tests: + LTnlink + LTsock + LTszoff + LTunix + + Optional tests: + LTbigf + LTdnlc + LTlock + LTnfs + +The basic and standard tests should all succeed on all dialects, +although LTnlink may warn that it can't perform its unlink test on +an NFS file system. + +The optional tests may run, they may be disabled for specific +dialects, or they may fail because of special resource needs -- +e.g., LTbigf will run only on UNIX dialects where it knows how to +handle files whose lengths exceed 32 bits, and LTnfs needs access +to an NFS file system mounted from a remote NFS server. + +Tests that need special resources usually provide a hint about the +resources when they fail. Information about special resource needs +may also be found in the following sections about the individual +tests. + +G.1. LTbasic, a Basic Lsof Test +=============================== + +This is the basic lsof test. If it doesn't run, it's not likely +any other tests will run, either. Hence, if it fails, no Makefile +rule runs any other tests. + +This test uses lsof to locate files in the lsof process, including +current working directory, the lsof executable, and the /dev/kmem +open file. + +Finding the lsof executable may not be possible on AIX if lsof was +compiled without support for its -X option. + +Finding /dev/kmem use by lsof is only possible on dialects where +lsof uses /dev/kmem. The -DLT_KMEM define indicates that. + +Run this test: + + $ ./LTbasic + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.2. LTbigf, Test Sizes and Offsets for Large (> 32 bit) Files +============================================================== + +This is a test in the optional test group. + +This test is effective only when ../Configure has put -DLT_BIGF in +config.cflags. Without that definition this test simply reports +that the dialect doesn't support large files. That report is +accompanied by a successful test exit code, so that the runner of +the test (e.g., the Makefile) won't believe the test failed. + +When a dialect does support large files, the test attempts to create +a file that looks very large -- e.g., has a length as reported by +ls(1) of 0x140000000 bytes. However, the file really has only a +small amount of data in it, the rest of the file consists of a +large standard UNIX file system "hole." + +By default the test file is named config.LTbigf, where PID is +the Process ID of the LTbigf process. + +When that file is not on a file system enabled for large files, or +when the process that runs LTbigf can't create a big file, LTbigf +will report an error. The error will be accompanied by hints that +the -p option may need to be used to define a path where the test +can write a large file, or the process ulimit file block size may +need to be raised -- e.g., to "unlimited." + +LTbigf can't test file offset reporting on Linux kernels below +2.6.22, because the /proc file systems of those kernels don't make +file offsets available to lsof. + +Run this test: + + $ ./LTbigf [-p ] + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.3. LTdnlc, Test the Kernel's Dynamic Name Lookup Cache +======================================================== + +This is a test in the optional test group. + +This test asks lsof to locate the current working directory of its +own process and report the path it has assembled from the components +it found in the kernel's Dynamic Name Lookup Cache (DNLC) or via +other dialect-specific methods. (E.g., Linux, HP-UX 11.11, and +some Tru64 UNIX versions have private name lookup methods.) + +The test checks what lsof reports as the current working directory +path for any missing components and counts the number of full paths +returned. (Symbolic link complications prevent testing for exact +path matches.) The test is repeated. If full paths are returned +at least half the time, the test considers itself successful. + +This test can't be run on AIX, because lsof can't access the DNLC +there. It can't be run on Apple Darwin versions below 8.0, either, +because insufficiently reliable DNLC information is available there. +This test may fail on other dialects when the file system -- e.g., NFS. +/tmp, loopback -- doesn't fully participate in the dialect's DNLC. + +Run this test: + + $ ./LTdnlc + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.4. LTlock, Lock Tests +======================= + +This is a test in the optional test group. + +This test uses flock() and fcntl() to set and clear file locks, +and measures lsof's ability to report them. The choice of system +lock call is based on the dialect. (There are LT_DIAL_* pre-processor +tests in LTlock.c.) + +This test can't be run on an NFS client file system, because NFS +lock information is kept on the server. Lsof on the client can't +see that server kernel data. + +By default the test attempts to create a file named config.LTlock, +where PID is the Process ID of the locking test process. It uses +lsof to determine if the file is on a client NFS file system. If +it is, the test aborts, hinting that the -p option can be used to +specify a non-client-NFS test file path. + +This test can't be run on Darwin, because insufficient file system +lock information is available to lsof there. + +Run this test: + + $ ./LTlock [-p ] + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.6. LTnfs, NFS Test +==================== + +This is a test in the optional test group. + +This test verifies that lsof can locate files mounted on a client +NFS system from an NFS server. + +By default it creates a test file, config.LTnfs, where PID is +the Process ID of the test process. The test then uses lsof to +find the file on an NFS file system. + +If lsof can't find the file the test warns that the test file might +not be on an NFS file system and hints that the -p option may be +used to specify the path of an NFS file, provided the test can have +read access to it there. The test warning also states that the +file at the path specified with -p must be a regular file, not a +directory. + +This test can't be run on Darwin versions below 8.0, because +insufficient NFS file information is available to lsof there. + +Run this test: + + $ ./LTnfs [-p ] + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.7. LTnlink, Link Count Test +============================= + +This is a test in the standard test group. + +The test checks lsof's reporting of link count (nlink in UNIX +argot.) + +It creates a test file in the current working directory named +config.LTnlink, where PID is the Process ID of the test +process. It then uses stat(2) and lsof to measure the link count +of the file. + +If LTnlink creates the test file in the current working directory +and it is on an NFS file system, LTnlink won't be able to perform +one section of its test. In that section the test file is unlinked +so its link count will be zero and lsof is asked to find it among +the set of files whose link counts are zero. + +When an NFS file is unlinked its link count isn't reduced until +the last open instance is closed on either the NFS clients or the +NFS. That's a consequence of NFS statelessness and leads to the +occasional presence of files with names of the form .nfsxxxx. + +Should LTnlink find its test file on an NFS file system, it disables +the unlink section of its tests and issues a warning. It also +issues a hint that the test file path can be named via the -p option +to give a test file location that isn't on an NFS file system. + +This test can't be run on Darwin, because insufficient file system link +count information is available to lsof there. + +Because some UNIX dialects delay the reporting of a link count +update after a file has been unlinked, LTnlink may not get its +expected response from lsof for a while after the test file has +been unlinked. In that cause LTnlink may delay for up to a minute, +calling lsof once every two seconds and displaying a "waiting for +link count update: ..." message. + +Some file systems -- e.g., ZFS on Solaris 11 -- don't allow LTnlink to +unlink its test file, because LTnlink has the file open. LTnlink +explains that failure and suggests that it be run with path of the "-p +path" option set to a file on /tmp. See 00FAQ for more information. + +Run this test: + + $ ./LTnlink [-p ] + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.7. LTsock, Test IPv4 Sockets +============================== + +This is a test in the standard test group. + +This test uses lsof to locate open IPv4 socket files that the test +has created itself. The test opens a server socket, then forks a +child process to connect to that socket. After both are running, +the test uses lsof to find the open socket files at their known +host and port addresses. + +Run this test: + + $ ./LTsock + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.8. LTszoff, Test Sizes and Offsets for Small (< 32 bit) Files +=============================================================== + +This is a test in the standard test group. + +This test checks lsof's reporting of file size and offset for small +(< 32 bits) files. + +It creates a test file in the current working directory named +config.LTszoff. PID is the Process ID of the test process. + +LTszoff can't test file offset reporting on Linux kernels below +2.6.22, because the /proc file systems of those kernels don't make +file offsets available to lsof. + +Run this test: + + $ ./LTszoff [-p ] + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + +G.9. LTunix, Test UNIX Domain Sockets +====================================== + +This is a test in the standard test group. + +This test checks lsof's reporting of UNIX domain sockets. + +The test creates a pair of UNIX domain sockets and uses bind(2) to +associate the file system names config.LT0U (client) and +config.LT1U (server) with them. (PID is the test process ID.) +The test then uses lsof to find the two open UNIX domain socket +files. + +Run this test: + + $ ./LTunix + +Environment variables: LT_LSOF_PATH defines the path to the lsof + executable. (The default is ../lsof.) + + +Appendix A, Test Files +====================== + +These files may be created by suite tests. + + Created + ./tests Name by Test Use + ============ ======= === + + config.LTbifg** LTbigf to test lsof's large file size + and offset reporting + + config.LTlock* LTlock for locking tests + + config.LTnfs* LTnfs for NFS tests + + config.LTnlink* LTnlink for link count tests + + config.LTszoff* LTszoff for small file size and + offset reporting + + config.LT[01]U* LTunix two UNIX domain sockets, used + to determine if lsof can report + their open instances properly + + +Appendix B, Test Validations +============================ + +This appendix lists the UNIX dialects and their versions where I +have validated the test suite. The list indicates the particular +tests I was unable to run, mostly LTnfs because the test systems +I used had no NFS file systems mounted. + +The information in the following table is encoded in a test data +base file, TestDB, as footprints, using the tests compiler options +written to config.cflags by the lsof Configure script. See "B.2. +Test Data Base and Scripts" for more information on the test data +base, footprints, and the scripts that support them. + + UNIX + Dialect Dialect Description Untested Tests + ======= =================== ============== + AIX 4.3.3, Power, cc + 5.1, Power-32, cc + 5.1, Power-32, gcc + 5.1, Power-64, cc + 5.2, Power-32, cc + 5.2, Power-32, gcc + 5.2, Power-64, cc + 5.2, Power-64, gcc + 5.3, Power-64, cc + Darwin 1.4, 5.5, 6.x, 7.x gcc Darwin lsof doesn't + have adequate support + to allow the LTbigf, + Ltdnlc, LTlock, LTnfs, + and LTnlink tests to + run. + 8.0, gcc Darwin lsof doesn't + have adequate support + to allow the LTbigf, + LTlock and LTnlink + tests to run. + 9.0, gcc Darwin lsof doesn't + have adequate support + to allow the LTlock + test to run. + 10.0, gcc Darwin lsof doesn't + have adequate support + to allow the LTlock test + to run. + 11.0, gcc Darwin lsof doesn't + have adequate support + to allow the LTlock test + to run. + FreeBSD 4.5, i386, gcc + 4.6, i386, gcc + 4.7, i386, gcc + 4.8, i386, gcc + 4.9, i386, gcc + 4.10, i386 gcc + 5.0, Alpha, gcc + 5.0, Sparc, gcc + 5.0, i386, gcc + 5.1, Alpha, gcc + 5.1, Amd64, gcc + 5.1, Sparc, gcc + 5.1, i386, gcc + 5.2, i386, gcc + 5.2, Alpha, gcc + 5.2, Amd64, gcc + 5.2, Sparc, gcc + 5.3, Alpha, gcc + 5.4, Alpha, gcc + 5.5, Alpha, gcc + 6.0, Alpha, gcc + 6.0, Amd64, gcc + 6.0, Sparc, gcc + 6.1, i386, gcc + 6.4, i386, gcc + 7.0 Alpha, gcc + 7.0 Amd64, gcc + 7.1 Amd64, gcc + 7.2 Amd64, gcc + 7.3 Amd64, gcc + 7.4 Amd64, gcc + 8.0 Amd64, gcc + 8.2 Amd64, gcc + 8.3 Amd64, gcc + 8.4 Amd64, gcc + 9.0 Amd64, gcc + 10.0 Amd64, gcc + 10.0 Amd64, clang + 11.0 Amd64, clang + 12.0 Amd64, clang + HP-UX 10.20, cc LTbigf + 10.20, gcc (1) LTbigf + 11.00-32, ANSI-C LTbigf, LTnfs + 11.00-64, ANSI-C + 11.11, ANSI-C + 11.23, ANSI-C + Linux 2.4.12-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.18-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.21-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.23-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.24-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.25-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.26-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.27-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.28-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.29-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.4.30-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.6.1-rc2 LTbigf, no offset tests + LTszoff, no offset tests + 2.6.18-686 LTbigf, no offset tests + LTszoff, no offset tests + 2.6.22-686 (Note: this Linux kernel + supplies file offsets to + lsof.) + 2.6.32-686 (Note: this Linux kernel + supplies file offsets to + lsof.) + 2.6.38-686 + 3.10.004 + 3.10.08 + 4.14.14 + 3.10.0-229.1.2.el7 + NetBSD 1.4.1, Alpha, gcc LTnfs + 1.5x, x86, gcc LTnfs + 1.6x, Alpha, gcc LTnfs + 1.6x, x86, gcc LTnfs + 2.0x, alpha, gcc LTnfs + 2.0x, sparc64, gcc LTnfs + 2.0x, x86, gcc LTnfs + 2.99.9, x86, gcc LTnfs + 2.99.10, x86, gcc LTnfs + 2.99.11, x86, gcc LTnfs + 2.99.12, x86, gcc LTnfs + 3.99., x86, gcc LTnfs + OpenBSD 3.0, gcc + 3.1, gcc + 3.2, gcc + 3.3, gcc + 3.4, gcc + 3.5, gcc + 3.6, gcc + 3.7, gcc + 3.9, gcc + OSR 5.04, cc LTnfs + 5.06, cc LTnfs + Solaris 2.6, cc LTnfs + 2.6, gcc LTnfs + 7-32, cc + 7-32, gcc LTnfs + 8-32, cc + 8-32, gcc + 8-64, cc + 8-64, gcc + 9-64, Beta-Refresh, cc + 9-64, Beta-Refresh, gcc + 9-64, FCS, cc + 9-64, FCS, gcc + 10-32, i86pc, gcc + 10-32, i86pc, cc + 10-64, Sparc, cc + 10-64, Sparc, gcc + 11-64, Amd64, cc + UnixWare 7.1.1, NSC, cc LTnfs + 7.1.3, cc + 7.1.4, cc + +If you are able to run the test suite on dialect versions other +than the ones listed above, please send e-mail to , +indicating the dialect version where you were able to run the test +suite. Please send me the footprint formed by CkTestDB, or run +the Add2TestDB script and send me the footprint it reports. + +If you encounter problems compiling the tests or running them on +a dialect version listed above, please send e-mail to , +naming the dialect version and providing the output from the lsof +Configure script and make operation. + +1) John Dzubera did the HP-UX 10.20 gcc testing and provided its + footprint. + + +Appendix C, Test Failures +========================= + +I was unable to make the test suite run on the following dialects. + + UNIX Dialect + and Description Failure + =============== ======= + HP-UX 11-64, gcc 64 bit gcc 3.0 didn't compile the LTsock + test correctly on my 64 bit HP-UX 11 test + system. + + +Vic Abell +February 14, 2018 diff --git a/00XCONFIG b/00XCONFIG new file mode 100644 index 0000000..ea1f0b6 --- /dev/null +++ b/00XCONFIG @@ -0,0 +1,697 @@ + + Cross-configuring Lsof + +Introduction +============ + +Lsof cross-configuration is useful when the target dialect or target +dialect version for which lsof is to be configured and built differs +from the one on which the Configure operation is done. + +Marty Leisner suggested the method +described here for lsof cross-configuration, and he supplied +modifications to the Configure script for cross-configuring Linux +lsof. + +Marty says: + + "I used this to successfully compile (lsof) on the same machine + for (Linux) 2.0.30 and 2.1.42. (I normally don't bring up a + 2.1.42 machine all the time). Also it (the 2.0.30 system) + doesn't have much storage and compiles on it are slow. + + Set LSOF_VERS if it's not the (version of the) current system. + (Actually, you should get the version out of include/linux/version.h.) + + Define LINUX_KERNEL to (the path) where the kernel sources + are (located). (No longer necessary as of lsof revision 4.53.) + + This should work on most systems; they put a kernel in + /usr/src/linux, which is the default. + + Now I can just do: + + LINUX_KERNEL=/some/other/kernel LSOF_VERS=2142 ./Configure linux + + Comments? It's very convenient when running multiple kernels. + (It would be (have been) very handy when the structures changed + between 2.0.2* and 2.0.30 , or whatever.) + + I run multiple OSes at a time (not to mention multiple + architectures. It's very pleasant to cross-build either + operating systems or versions." + +So, the situation is that you have lsof sources on a UNIX dialect +version, and you want to configure them to build lsof for some +other version of the same dialect, or perhaps for some other UNIX +dialect altogether. + + +The Cross-Configure Method +========================== + +The lsof cross-configure method uses environment variables to tell +the lsof Configure script about the target dialect. The environment +variables may specify alternate locations for Configure to examine +when it determines characteristics of the target, or they may +specify the values Configure would discover when it examined the +target's characteristics. + +Consult each environment variable description for the UNIX dialect +in which you're interested to see how it affects the operation of +the Configure script. + +The number and values of the variables differ by dialect. Each +variable begins with an upper case version of the dialect's Configure +abbreviation -- e.g., AIX for aix or aixgcc, LINUX for linux, +UW for uw (UnixWare), etc. + +Of course, the UNIX dialect's version is probably different from +that of the system on which you're doing the cross-configuration, +so you will need to specify the new version, too. For example, to +configure for FreeBSD 3.0 on a 2.1.7 system, where the standard +3.0 header files are in /3.0/usr/include and the 3.0 system sources +are in /3.0/sys, do this: + + LSOF_VERS=300 LSOF_INCLUDE=/3.0/usr/include \ + FREEBSD_SYS=/3.0/sys Configure -n freebsd + + +General Environment Variables +============================= + +There are some environment variables whose names don't begin with +an upper case rendering of a dialect abbreviation. Generally they +apply to all dialects. + +AFS_VICE is for AFS configuration. It need be set only if + lsof supports AFS on your dialect and you want to + specify an alternate path to the VICE files. + + default: /usr/vice + +LSOF_AR is the path to and arguments for the library archive + application that is used to build the lsof library, + liblsof.a. When this value is placed in the library + Makefile as the contents of the AR make string, it is + followed by the path to the library and the relative + paths of the library module + + default: ar cr + +LSOF_ARCH is the architecture type string for the system. + Usually this is the output of `uname -m`. Consult + the Configure script for details. The LSOF_ARCH + value may have to be quoted if it contains spaces. + + default: auto-detection (e.g., from `uname -m`) + +LSOF_BLDCMT may be used to introduce a builder's comment into + lsof's -v output. It defaults to the null string, + causing no builder's comment to appear in -v output. + + default: none + +LSOF_CC is the path to the C compiler. You may need to + specify it if your C compiler is in a non-standard + place, not found by your path. If you specify a + compiler different from the expected default, you + may have to change the compile time flags by + specifying new CFGF, CFGL, and DEBUG strings on + the make command line. + + default: normally cc, but some dialects have other + defaults and some have auto-detection. + + Check the dialect stanza in the lsof Configure + script to see how LSOF_CC is set by default. + +LSOF_CCV is the C compiler version. You should specify it + if you have specified a compiler path in LSOF_CC. + + default: the lsof Configure script knows how to find + the version number of gcc and some other + dialect-specific compilers. + + Check the dialect stanza in the lsof Configure + script to see how lsof_CCV is set by default. + +LSOF_CFGF may be used to specify additional configuration values + that will appear in the CFGF string of the Makefile. + +LSOF_CFGL may be used to specify additional library specifications + that will appear in the CFGL string of the Makefile. + +LSOF_HOST may be used to specify a value in lsof's -v output + other than the name of the host where lsof was + built. A value of "none" inhibits host name display + in -v output. + + default: the dialect's host name application -- e.g., + hostname or uname -n + +LSOF_INCLUDE is the path to a tree of header files that is an exact + image of the standard header file tree for the + target dialect. You may need to specify it if you + want Configure to test header files in a tree different + from /usr/include and compile its test programs with + header files from that tree, then you want to compile + lsof from the header files in that different, duplicate + image tree. + + Note: LSOF_INCLUDE should contain a single path + without any option flags, such as -I. It is always + supplied to the compiler in CFLAGS following the -I + option flag. If you want to specify other include + paths, use LSOF_OPINC. + + ADDITIONAL NOTE: all the header files that lsof's + Configure tests for optional features and uses to + compile test programs must be in LSOF_CONFIGURE. + They can't be scattered in the other include path + that LSOF_OPINC names. + +LSOF_LOGNAME may be used to specify a value in lsof's -v output + other than the one in the LOGNAME environment + variable for the login name of the person who built + lsof. A value of "none" inhibits login name display + in -v output. + + default: the LOGNAME environment variable + +LSOF_MAKE is the path to the make command. + + default: the output of `which make`, if it is not NULL; + otherwise the string "make". + +LSOF_MKC may be used to specify an alternate method of + connecting dialect sources to the top-level lsof + directory. See 00PORTING for more information. + + default: ln -s + +LSOF_OPINC may be used to specify other include file search + paths. Each must be preceded by the compiler's -I + option file and, if there are muliple paths, they + must be separated by spaces and the entire set must + be enclosed in double quote marks -- e.g., + + LSOF_OPINC="-I/path1 -I/path2 ..." + + The optional include paths thus specified will be + appended to LSOF_INCLUDE and whatever special + include paths the lsof Configure script finds + necessary. + +LSOF_RANLIB may be used to specify an alternate command for the + randomizing of the lsof library. + + default: ranlib for most dialects + none for: IBM AIX; HP-UX; SCO OpenServer; Solaris + and SCO|Caldera UnixWare + +LSOF_SYSINFO may be used to specify a value in lsof's -v output + other than the standard system identification -- + e.g., output from uname. A value of "none" inhibits + system information display in -v output. + + default: the dialect's standard system identification + application output -- e.g., uname, sysinfo + +LSOF_USER may be used to specify a value in lsof's -v output + other than the one in the USER environment variable + for the login name of the person who built lsof. + A value of "none" inhibits login name display in + -v output. + + default: the USER environment variable + +LSOF_VERS is the target dialect version number. It must be + stated in the dialect's form -- e.g., FreeBSD 2.0.5 + is given as 205, Solaris 7 as 70000, etc. The + table, "Abbreviations, Variable Prefixes, and + Version Numbers," in this file gives the form for + LSOF_VERS for each dialect lsof supports. + + default: auto-detection (e.g., from `uname -r`) + +LSOF_VSTR is the version string from which LSOF_VERS is + derived. Usually this is the output of `uname -r` + or `uname -v`. Consult the Configure script for + details. The LSOF_VSTR value may have to be quoted + if it contains spaces. + + default: auto-detection (e.g., output from + `hostname`, `uname -r`, or `uname -v) + + +Make Strings +============ + +The CFGF, CFGL, and DEBUG strings can be specified on the make +command line to change default values placed in the top-level and +library Makefiles by Configure. For example, Configure usually +defines the compiler optimization level to be -O, but you can change +that with "DEBUG=-g" on the make command -- e.g., + + $ make DEBUG=-g lsof + +Similarly, the CFGF string contains miscellaneous compile-time +options, and CFGL contains loader options. Consult the Makefiles +generated by Configure for the values it defines by default for +CFGF and CFGL. + +As an example, Configure might define CFGL to be "-L./lib -llsof -w" +for NextStep 3.1; to remove "-w", use this make invocation: + + $ make CFGL="-L./lib -llsof" + + +Abbreviations, Variable Prefixes, and Version Numbers +===================================================== + +The following table describes the relationship between Configure +abbreviations, environment variable prefixes, and lsof UNIX dialect +version numbers. The lsof UNIX dialect version number must be +declared exactly in the listed form when supplied via the LSOF_VERS +environment variable. + + Dialect Lsof Version + Configure Variable Version Number for +Abbreviation* Prefix Number LSOF_VERS + + aix AIX 3.2.5 3250 + aixgcc 4.1.0 4100 + 4.1.4 4140 + 4.1.4 4150 + 4.2.0 4200 + 4.2.1 4210 + 4.3 4300 + 4.3.1 4310 + 4.3.2 4320 + 4.3.3 4330 + 5.0.x 5000 + 5.1.x 5100 + 5.2.x 5200 + 5.3.x 5300 + darwin DARWIN 1.2* 120 + 1.3* 130 + 1.4* 140 + 5.[012] 500 + 5.[3-9] 530 + 6.x 600 + 7.x 700 + 8.x 800 + freebsd FREEBSD 1.x 1000 + 2.x 2000 + 2.0.5 2005 + 2.1.x 2010 + 2.2.x 2020 + 3.x 30x0 + 4.x 40x0 + 4.1x 41x0 + 5.x 50x0 + 6.x 60x0 + 7.x 70x0 + 8.x 80x0 + 9.x 90x0 + hpux HPUX 9.1 901 + hpuxgcc HPUX 9.5 905 + 10.0 1000 + 10.10 1010 + 10.20 1020 + 11.00 1100 + 11.11 1111 + linux LINUX 2.1.x 21xxx + 2.2.x 22xxx + 2.3.x 23xxx + 2.4.x 24xxx + 2.6.x 26xxx + netbsd NETBSD 1.2 1002000 + 1.3 1003000 + 1.4 1004000 + 1.5 1005000 + 1.6 1006000 + 2.0 2000000 + 2.99.9 2099009 + 2.99.10 2099010 + openbsd OPENBSD 1.2 1020 + 2.0 2000 + 2.1 2010 + 2.2 2020 + 2.3 2030 + 2.4 2040 + 2.5 2050 + 2.6 2060 + 2.7 2070 + 2.8 2080 + 2.9 2090 + 3.0 3000 + 3.1 3010 + 3.2 3020 + 3.3 3030 + 3.4 3040 + 3.5 3050 + 3.6 3060 + osr OSR 3.2v2.0 20 + 3.2v2.1 21 + 3.2v4.0 40 + 3.2v4.1 41 + 3.2v4.2 42 + 3.2v5.0.0 500 + 3.2v5.0.2 502 + 3.2v5.0.4 504 + 3.2v5.0.6 506 + ou OU 8.0.0 80000 + solaris SOLARIS 2.3 20300 + solariscc SOLARIS 2.4 20400 + 2.5 20500 + 2.5.1 20501 + 2.6 20600 + 7 70000 + 8 80000 + 9 90000 + 10 100000 + uw UW 7.0 70000 + 7.1.0 70100 + 7.1.1 70101 + 7.1.3 70103 + + + +Dialect-Specific Environment Variables +====================================== + +Here are the dialect-specific environment variables, listed +alphabetically. The first part of any environment variable will +be the dialect abbreviation, as specified to Configure, converted +to upper case characters. See the `Configure -help` output for a +listing of the abbreviations. + +AIX_ARCH specifies the AIX architecture when the AIX version is + 5.0 or higher. A value of "" signifies POWER; "ia64", + 64 bit x86 (Itanium). + + default: none (tested via `uname -a`) + +AIX_HAS_AFS specifies the state of AIX ADS support when the AIX + version is 4.3.3 or lower. (Lsof doesn't support AFS + above AIX 4.3.3.) A value of "" allows the Configure + script to determine the AFS support state; "no", + disables AFS support; and "yes", forces the enabling of + AFS support. + + default: none (tested via presence of AFS files and the + lsof AFSConfig shell script) + +AIX_KERNBITS specifies the kernel bit size, 32 or 64, of the Power + architecture AIX 5.x kernel for which lsof was built. + + default: determined by the Configure script with a test + program that uses macros. + +AIX_USHACK If this environment variable has a value of "Y" or "y", + and if the aixgcc Configure abbreviation is selected, + the AIX 4.1 and greater gcc user structure hack is + activated; any other non-NULL value, it's not set; a + NULL value, it's tested by compilation. + + default: none (tested by compilation) + +DARWIN_XNUDIR If this environment variable has a value, the value is + used as the path to the Darwin XNU kernel source code. + + default: none (entry requested) + +DARWIN_XNU_HEADERS If this environment variable has a value, the value is + used as the path to the Darwin XNU kernel header files. + This path would match the DSTROOT environment variable + used when a "make installhdrs" was executed from the + Darwin XNU kernel source directory. + + default: none + +FREEBSD_KERNEL specifies the path to the FreeBSD kernel for FreeBSD + version less than 2.0. + + default: /386bsd + +FREEBSD_SYS specifies the path to the FreeBSD system source + directory. + + default: /sys + +HPUX_BASE specifies the HP-UX lsof source code base, kmem or + pstat, to be used. + + default: determined by testing for the + /usr/include/sys/pstat subdirectory + +HPUX_BOOTFILE specifies the file in which lsof's Configure script can + find kernel information. This specification may be + useful for defining the path to a copy of /stand/vmunix + that has been processed by pxdb or q4pxdb. + + default: /stand/vmunix + +HPUX_CCDIR1 specifies the first directory where Configure might + find an HP-UX C compiler. This is ignored when + LSOF_CC has been specified. + + default: /bin + +HPUX_CCDIR2 specifies the second directory where Configure might + find an HP-UX C compiler. This is ignored when + LSOF_CC has been specified. + + default: /usr/ccs/bin + +HPUX_HASONLINEJFS If this environment variable has a value of "Y" or "y", + the HASONLINEJFS definition will be enabled in the + Makefile CFLAGS. That will cause dnode1.c to use an + alternate vx_inode.h header file in the hpux11 sub- + directory of dialects/hpux/kmem. + + default: determined using nm and grep + +HPUX_IPC_S_PATCH If this environment variable has a value of "1", the + ipc_s structure of the HP-UX 11 kernel is assumed to + have an ipc_ipis member, but it is assumed the ipis_s + structure lacks the ipis_msgsqueued member; "2", ipc_s + has ipc_ipis, but ipis_s has ipis_msgsqueued; "n" or + "N", ipc_s lacks ipc_ipis; any other non-NULL value is + considered an error; a NULL value, HPUX_IPC_S_PATCH is + determined by testing. + + default: determined with q4 and grep + +HPUX_KERNBITS specifies the number of bits (32 or 64) in the HP-UX + 11 "basic kernel word. + + default: `getconf _SC_KERNEL_BITS` + +HPUX_LIBC1 specifies the first directory that might contain the + HP-UX C library, libc.sl. + + default: /usr/lib + +HPUX_LIBC2 specifies the second directory that might contain the + HP-UX C library, libc.sl. + + default: /lib + +HPUX_RNODE3 If this environment variable has a value of "1", the + Configure script will define HASRNODE3 in the Makefile + CFGF flags. If it is defined, but not "1", Configure + will not define HASRNODE2. + + default: determined using `nm -x /stand/vmunix` and + `grep r_fh3 /usr/include/nfs/rnode.h` + +HPUX_X25DIR specifies path to the HP-UX X25 directory that contains + configuration header files. + + default: /etc/conf + +LINUX_CLIB specifies the definition of the Linux C library: + + default: "" (standard C library) + others: -DGLIBCV=2 (glibc2) + +LINUX_CONF_CC specifies the location of the C compiler to use during + the running of the Configure script: + + default: the value of the LSOF_CC variable, if defined, + or cc + +LINUX_HASSELINUX If this environment variable has a value of "Y" or "y", + Configure unconditionally activates SELinux support. + If it has any other value, Configure unconditionally + inhibits SELinux support. + + Default: assumed to be "Y" if + exists + +LINUX_INCL specifies the path to the header file tree: + + default: /usr/include + +LINUX_LSEEK If this environment variable has a value of "Y" or "y", + Configure uses Makefile.lseek in place of Makefile in + order to enable use of the private lseek() function for + 2.1.x kernels; any other non-NULL value, Makefile.lseek + will isn't used; a NULL value, the alternate lseek() + need is determined by compilation. + + default: determined by test program + +LINUX_VERSION_CODE specifies the value of the LINUX_VERSION_CODE in the + same decimal form as found in the LINUX_VERSION_CODE + #define of /usr/include/linux/version.h: + + default: the value of LINUX_VERSION_CODE in + /usr/include/linux/version.h + +NETBSD_SYS specifies the path to the NetBSD system source + directory. + + default: /usr/include + +NETBSD_UVM If this environment variable has a value of "Y" or "y", + the NetBSD system uses the UVM virtual memory system; + any other non-NULL value, it does not; a NULL value, + it will be determined by the contents of /etc/mk.conf. + + default: tested by grep'ping /etc/mk.conf + +OPENBSD_SYS specifies the path to the OpenBSD system source + directory. + + default: /sys + +OPENBSD_UVM If this environment variable has a value of "Y" or "y", + the OpenBSD system uses the UVM virtual memory system; + any other non-NULL value, it does not; a NULL value, + it will be determined by examining /bsd. + + default: tested by grep'ping `nm /bsd` output + + +OSR_CFGF The value of this environment variable is made the + initial value for the compiler flags the lsof Configure + script constructs for the Makefile CFGF macro. + + default: "" + +OSR_CFGL The value of this environment variable is made the + initial value for the loader flags the lsof Configure + script constructs for the Makefile CFGL macro. + + default: "" + +OSR_STATLSTAT If this environment variable has a value of "Y" or "y", + HAS_STATLSTAT is defined in the Makefile's CFGL string; + any other non-NULL value, it's not defined; a NULL + value, it is determined with nm and grep. + + default: determined with nm and grep + + +SOLARIS_23P101318 If this environment variable has a non-NULL value, the + value is interpreted as the patch level of the Solaris + 2.3 P101318 patch. + + default: pkginfo tested with grep + +SOLARIS_24P101945 If this environment variable has a non-NULL value, the + value is interpreted as the patch level of the Solaris + 2.4 P101945 patch. + + default: pkginfo tested with grep + +SOLARIS_24P102303 If this environment variable has a non-NULL value, the + value is interpreted as the patch level of the Solaris + 2.4 P102303 patch. + + default: pkginfo tested with grep + +SOLARIS_26PR_GWINDOWS If this environment variable has a value of "Y" or "y", + the HASPR_GWINDOWS definition is set in the Solaris 2.6 + and 7 Makefile's CFG string; any other non-NULL value, + it's not set; a NULL value, it's tested by compilation. + + default: tested by compilation + +SOLARIS_26PR_LDT If this environment variable has a value of "Y" or "y", + the HASPR_LDT definition is set in the Solaris 2.6 + Makefile's CFGL string; any other non-NULL value, it's + not set; a NULL value, it's tested by compilation. + + default: tested by compilation + +SOLARIS_CCDIR specifies the path to the Sun C compiler -- i.e., when + `Configure solariscc` is used. This is ignored when + LSOF_CC has been specified. + + default: /opt/SUNWspro/bin + +SOLARIS_INSTR specifies the Sun C compiler target instruction set + when building lsof for a 64 bit kernel -- i.e., when + the Configure abbreviation is "solariscc". Possible + values include amd64 and sparcv9. This is ignored when + the Configure abbreviation is "solaris" -- i.e., the + compiler is gcc. + + default: tested with /bin/isainfo -k + +SOLARIS_KERNBITS specifies the number of bits in the Solaris 7, 8, 9 or + 10 kernel: 32 or 64. + + default: tested with /bin/isainfo -kv + +SOLARIS_VSOCK If this environment variable has a value of "Y" or "y", + the HAS_VSOCK definition is in the Solaris Makefile's + CFGL string; any other non-NULL value, it's not set; a + NULL value, it's tested by compilation. + + default: tested by compilation + +SOLARIS_VXFSINCL This environment variable defines the path to the + header files of the VxFS 3.4 or greater version. If + SOLARIS_VXFSINCL is not set, the default is used. + + default: VxFS < 4.0: + /opt/VRTSvxfs/include + VxFS 4.0 and above: + /opt/VRTSfssdk//include + +SOLARIS_VXFSLIB This environment variable defines the path to the + VxFS 3.4 or greater utility libraries, libvxfsutil.a + (32 bit) and libvxfsutil64.a (64 bit). If + SOLARIS_VXFSLIB is not set, the default is used. + + Note: end SOLARIS_VXFSLIB at the "/lib" component; do + NOT put "/sparcv9" at its end. The lsof + Configure script will add "/sparcv9" if it is + required; hence, if Configure finds that + "/sparcv9" is needed, your SOLARIS_VXFSLIB + directory tree must have a sparcv9 subdirectory. + + default: `dirname $SOLARIS_VXFSINCL`/lib + +SUN_AFSAPATHDEF specifies the path to the AFS library modload file + for either Solaris or SunOS. + + default: /usr/vice/etc/modload/libafs + Verified with ls. + + Note: the SunOS support is no longer maintained. + +UW_HAS_NSC If this environment variable has a value of "Y" or "y", + lsof will be configured for a UnixWare 7.1.1 or above + NonStop Cluster (NSC) system. + + default: tested via /bin/node_self + +Vic Abell +October 13, 2014 diff --git a/AFSConfig b/AFSConfig new file mode 100755 index 0000000..376eeec --- /dev/null +++ b/AFSConfig @@ -0,0 +1,346 @@ +#!/bin/sh +# +# $Id: AFSConfig,v 1.2 99/05/09 14:49:54 abe Exp $ +# +# AFSConfig: configure for AFS + +AFSD=/usr/vice/etc/afsd +AH=AFSHeaders +AV=AFSVersion +STD=/usr/afsws/include + +# Establish trap and stty handling. + +ISIG=":" +trap 'rm -f $AH $AV; $ISIG; exit 1' 1 2 3 15 +stty -a 2>&1 | grep isig > /dev/null +if test $? -eq 0 +then + stty -a 2>&1 | grep -E -e -isig > /dev/null + if test $? -eq 0 + then + ISIG="stty -isig" + stty isig + fi +fi + +# Decide how to use echo. + +ECHO=$(echo -n "") +if test "X$ECHO" = "X-n " +then + EC="\c" + EO="" +else + EC="" + EO="-n" +fi + +# Decide (perhaps for a second time) that AFS is installed. + +CELL="" +if test -r /usr/vice/etc/ThisCell +then + cell=$(awk '{print $1}' /usr/vice/etc/ThisCell) + if test -d /afs/$cell + then + CELL=$cell + else + CELL=$(echo $cell | sed 's/\([^.]*\)\..*/\1/') + if test "X$CELL" != "X" + then + if test ! -d /afs/$CELL + then + CELL="" + fi + fi + fi +fi +if test "X$CELL" = "X" +then + echo "" + echo "This system does not appear to have AFS installed." + exit 1 +fi + +# See if AFS configuration is wanted. + +cat << .CAT_MARK + +AFS appears to be installed on this system; cell name "$CELL". + +Lsof needs to be configured for AFS by identifying: 1) the directory +that includes the AFS header files needed to compile AFS support into +lsof; and 2) the version of AFS that is installed. +.CAT_MARK + +END=0 +while test $END = 0 +do + echo "" + echo $EO "Do you want to configure lsof for AFS (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + exit 1 + fi + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + END=1 + else + echo "" + echo "Please answer y or n." + fi +done + +# See if $AH exists and points to a likely place. + +AHOK="" +echo "" +echo "=====================================================================" +echo "" +if test -r $AH +then + AHP=$(cat $AH) + if test -r $AHP + then + if test -r $AHP/afs/afs.h + then + cat << .CAT_MARK +The location of the AFS header files required by lsof has been +previously identified as "$AHP". + +Since can be found there, that's probably correct. +.CAT_MARK + + END=0 + while test $END = 0 + do + echo "" + echo $EO "Do you want to use $AHP again (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + AHOK="ok" + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + rm -f $AH + AHP="" + END=1 + else + echo "" + echo "Please answer y or n." + fi + fi + done + else + echo "\"$AHP\" has been previously specified as the location of the" + echo "AFS header files, but it lacks an afs/afs.h header file." + rm -f $AH + AHP="" + fi + else + echo "The file ./$AH exists, but has no AFS header file path in it." + rm -f $AH + AHP="" + fi +else + echo "No previous header location has been specified." + rm -f $AH + AHP="" +fi + +# See if the header files are in the "standard" place. + +if test "X$AHOK" != "Xok" +then + if test -r $STD + then + echo "" + echo "=====================================================================" + echo "" + echo "The AFS header files appear to be in the \"standard\" location --" + echo "i.e.: \"$STD\"." + END=0 + while test $END = 0 + do + echo "" + echo $EO "Do you want to let lsof use them (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + echo $STD > $AH + AHOK="ok" + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + echo "" + echo "Please answer y or n." + fi + fi + done + fi +fi + +# Ask for the AFS header file location. + +if test "X$AHOK" != "Xok" +then + echo "" + echo "=====================================================================" + echo "" + echo "Please specify the full path where lsof can find the AFS header" + echo "files. A possible location is: \"/afs/$CELL//include\"." + cat << .CAT_MARK +The component of the path is the AFS system name that +was used to configure and build AFS on this system. It is usually +constructed from a manufacturer or Unix operating system designation, +followed by a version number -- e.g., hp800_ux90, sun4m_54, vax_ul43, +etc. You may have to consult your AFS documentation to determine +what applies to your configuration. +.CAT_MARK + + END=0 + while test $END = 0 + do + echo "" + echo $EO "Do you want to see the contents of /afs/$CELL (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + echo "" + ls -C /afs/$CELL + END=1 + else + echo "" + echo "Please answer y or n." + fi + fi + done + END=0 + while test $END = 0 + do + echo "" + echo $EO "AFS header file path: $EC" + read ANS EXCESS + fc=$(expr "${ANS}X" : '\(.\).*') + if test "X$fc" = "X/" + then + if test -r $ANS/afs/afs.h + then + echo $ANS > $AH + AHOK="ok" + END=1 + else + echo "" + echo "$ANS/afs/afs.h doesn't exist." + echo "Please enter a path whose afs subdirectory contains afs.h" + fi + else + echo "" + echo "Please enter an absolute path name." + fi + done +fi +if test "X$AHOK" != "Xok" +then + echo "AFSConfig: unknown error" + exit 1 +fi + +# Determine AFS version. + +if test -r $AV +then + echo "" + echo "=====================================================================" + echo "" + AVN=$(cat $AV) + cat << .CAT_MARK +The AFS version was previously specified as: $AVN +.CAT_MARK + + END=0 + while test $END = 0 + do + echo "" + echo $EO "Is this the correct version number (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + exit 0 + fi + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + rm -f $AV + END=1 + else + echo "Please answer y or n." + fi + done +fi + +# See if the version number can be determined. + +if test -r $AFSD +then + ANS=$(strings $AFSD | grep "Base configuration afs" | sed 's/^.*ion afs\([^ ]*\) .*/\1/') + TV=$(echo $ANS | sed 's/^\([0-9]*\)\.\([0-9]*\)\(.*\)/\1 \2 \3/' | awk '{printf "%d.%d%s\n",$1,$2,$3}') + if test "X$ANS" = "X$TV" + then + echo "" + echo "=====================================================================" + echo "" + cat << .CAT_MARK +Examining $AFSD the AFS version number appears to be: $TV +.CAT_MARK + + END=0 + while test $END = 0 + do + echo "" + echo $EO "Do you want to use this version number (y/n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + echo $TV > $AV + exit 0 + else + echo "" + echo "Please answer y or n." + fi + fi + done + fi +fi + +# Ask for the version number. + +echo "" +echo "=====================================================================" +END=0 +while test $END = 0 +do + echo "" + echo $EO "Please enter the AFS version number: $EC" + read ANS EXCESS + TV=$(echo $ANS | sed 's/^\([0-9]*\)\.\([0-9]*\)\(.*\)/\1 \2 \3/' | awk '{printf "%d.%d%s\n",$1,$2,$3}') + if test "X$ANS" = "X$TV" + then + echo $TV > $AV + exit 0 + fi +done diff --git a/AUTHORS b/AUTHORS new file mode 100644 index 0000000..e69de29 diff --git a/COPYING b/COPYING new file mode 100644 index 0000000..279721a --- /dev/null +++ b/COPYING @@ -0,0 +1,26 @@ +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. diff --git a/ChangeLog b/ChangeLog new file mode 100644 index 0000000..9c4dd81 --- /dev/null +++ b/ChangeLog @@ -0,0 +1,6 @@ + +For notes about changes to lsof see the 00DIST file. + + +Vic Abell +October 19, 2012 diff --git a/Configure b/Configure new file mode 100755 index 0000000..ec56d4b --- /dev/null +++ b/Configure @@ -0,0 +1,5213 @@ +#!/bin/sh +# +# Configure -- configure lsof +# +# See the LSOF_HLP here document for usage. +# +# See the lsof distribution file 00XCONFIG for information on setting +# environment variables for cross-configuring lsof -- e.g., for configuring +# for Linux 2.3 on a machine running 2.4. Marty Leisner suggested this +# support and provided the Linux Configure stanza modifications. +# +# When configuring for a particular dialect, , this script +# requires that the subdirectory ./dialects/ contain a +# shell script, named $LSOF_MK, that places its source modules in this +# directory. +# +# $Id: Configure,v 1.166 2018/07/14 12:13:52 abe Exp $ + +# LSOF_CFLAGS_OVERRIDE=1 may be introduced through the environment to cause +# the library Makefile's CFLAGS definition to override any in the +# environment. + +# LSOF_DISTRIBKVM may be introduced through the environment to specify the +# Sun4 kernel virtual memory type of distrib.cf + +LSOF_F="ddev.c dfile.c dlsof.h dmnt.c dnode*.c dproc.c dproto.h dsock.c dstore.c dzfs.h kernelbase.h machine.h machine.h.old new_machine.h __lseek.s" +LSOF_HLP_BASE=./cfghlp. +LSOF_HLP=${LSOF_HLP_BASE}$$ + +# LSOF_LOCALSUFFIX may be introduced through the environment to select a local +# version of a Makefile. It is used as a suffix to $LSOF_MKF. + +# LSOF_MAKE may be introduced through the environment to specify a path to the +# make command. It defaults to `which make`, if that is non-NULL; +# otherwise to the string "make". + +if test "X$LSOF_MAKE" = "X" # { +then + LSOF_MAKE=`which make` + if test "X$LSOF_MAKE" = "X" # { + then + LSOF_MAKE=make + fi # } +fi # } + +LSOF_MK=Mksrc + +# LSOF_MKC is the dialect's Mksrc create command -- default "ln -s". + +# LSOF_MKFC may be introduced though the environment to change the name +# used for the created make file. + +if test "X$LSOF_MKFC" = "X" # { +then + LSOF_MKFC=Makefile +fi # } + +LSOF_LIB=lib +LSOF_MKF=Makefile +LSOF_LIBMKF=Makefile +LSOF_LIBMKFSKEL=Makefile.skel + +LSOF_VF=version + +# Make sure no other variable important to Makefile construction is +# already set in the environment. +# +# $AFS_VICE locatiion of AFS VICE directory +# (default = /usr/vice) +# $LSOF_AFS AFS temporary +# $LSOF_AFS_NQ AFS-not-qualified flag +# $LSOF_AFSV AFS version +# $LSOF_AR archive command and its arguments for making the +# lsof library +# $LSOF_ARCH Unix dialect architecture as a string (may be +# supplied externally) +# $LSOF_CC C compiler name (may be supplied externally) +# $LSOF_CCV C compiler version (may be supplied externally) +# $LSOF_CDIR configuration directory +# $LSOF_CFGD depend options +# $LSOF_CFGDN depend file name +# $LSOF_CFGF C flags -- e.g., -D's +# $LSOF_CFGL last lsof library loader flags -- e.g., -l's +# $LSOF_CINFO Configure information for LSOF_CINFO in version.h +# $LSOF_CTFH Solaris 10 and above libctf.h status +# $LSOF_CTFL Solaris 10 and above -lctf status +# $LSOF_DEBUG Makefile's DEBUG string +# $LSOF_DINC include flags -- -I's +# $LSOF_DINC_ADD include flags status +# $LSOF_DOC special document (man page) directory path +# $LSOF_ERR internal error flag +# $LSOF_FCFGL first lsof library loader flags -- e.g., -l's +# that must precede $LSOF_LIB +# $LSOF_FBSD_ZFS FreeBSD $LSOF_FBSD_ZFS_MKF status +# $LSOF_FBSD_ZFS_CFGF FreeBSD ZFS configure flags +# $LSOF_FBSD_ZFS_MKF FreeBSD ZFS Makefile name +# $LSOF_FBSD_ZFS_SYS FreeBSD ZFS system sources location +# $LSOF_HOST host name (e.g., from uname -n) +# $LSOF_INCLUDE directory where header files are found +# (default = /usr/include) +# $LSOF_LD loader name if not $LSOF_CC +# $LSOF_LIB_NO if "N" don't configure the lsof library +# $LSOF_LOCALSUFFIX local suffix for Makefile +# $LSOF_NBSD_BUFQH NetBSD copy status +# $LSOF_NBSD_PTYFS NetBSD ${NETBSD_SYS}/sys/fs/ptyfs/ copy status +# $LSOF_N_UNIXV *BSD system's kernel file +# $LSOF_OPINC supplies additional -I/path arguments for the +# Makefile's CFLAGS. +# $LSOF_PL patch level +# $LSOF_RANLIB randomizing command for the lsof library +# $LSOF_RANLIB_SUP if non-NULL $LSOF_RANLIB was supplied +# $LSOF_SCRIPT_CALL Customize and Inventory scripts call status +# $LSOF_SPMKF Special Makefile name +# $LSOF_TGT canonical target abbreviation (shortest) +# $LSOF_TMP internal temporary +# $LSOF_TMP1 internal temporary +# $LSOF_TMP2 internal temporary +# $LSOF_TMP3 internal temporary +# $LSOF_TMP4 internal temporary +# $LSOF_TMP5 internal temporary +# $LSOF_TMP6 internal temporary +# $LSOF_TMPC_BASE base name for $LSOF_TMPC +# $LSOF_TMPC temporary C source file base name +# $LSOF_TSTBIGF big file capability (for $LSOF_TSTCFLG) +# $LSOF_TSTCC tests CC file +# $LSOF_TSTCFLG tests CFLAGS file +# $LSOF_TSTDFLG dialect-specific values for $LSOF_TSTCFLG +# $LSOF_TSTK64 status of 64 bit kernel (for $LSOF_TSTCFLG) +# $LSOF_TSTKMEM /dev/kmem usage status (for $LSOF_TSTCFLG) +# $LSOF_TSTLFF tests LDFLAGS file +# $LSOF_TSTLFLG tests LDFLAGS values +# $LSOF_TSTSUBD test subdirectory +# $LSOF_TSTVPATH test v_path state (for $LSOF_TSTCFLG) +# $LSOF_TSTXO test extra objects (for $LSOF_TSTXOC) +# $LSOF_TSTXOC test extra objects file +# $LSOF_UNSUP Lsof is unsupported on this dialect +# $LSOF_UNSUP2 Second message about lack of support +# $LSOF_VERS Unix dialect version as a decimal number (may +# be supplied externally) +# $LSOF_VSTR Unix dialect version as a string -- may be supplied +# externally + +if test "X$AFS_VICE" = "X" # { +then + AFS_VICE="/usr/vice" +fi # } +LSOF_AFS="" +LSOF_AFS_NQ="" +LSOF_AFSV="" +if test "X$LSOF_ARCH" = "X" # { +then + LSOF_ARCH="" +fi # } +LSOF_CDIR="" +LSOF_CFGD="" +LSOF_CFGDN="" +LSOF_CINFO="" +LSOF_CTFH=0 +LSOF_CTFL=0 +LSOF_DEBUG="" +LSOF_DOC="" +LSOF_ERR="" +LSOF_FCFGL="" +LSOF_FBSD_ZFS=0 +LSOF_FBSD_ZFS_CFGF="" +LSOF_FBSD_ZFS_MKF="Makefile.zfs" +LSOF_FBSD_ZFS_SYS="" +LSOF_HOST="" +if test "X$LSOF_INCLUDE" = "X" # { +then + LSOF_DINC="" + LSOF_INCLUDE="/usr/include" +else + LSOF_DINC="-I$LSOF_INCLUDE" +fi # } +LSOF_LD="" +LSOF_LIB_NO="" +LSOF_PL="" +if test "X$LSOF_RANLIB" = "X" # { +then + LSOF_RANLIB="ranlib" + LSOF_RANLIB_SUP="" +else + LSOF_RANLIB_SUP="Y" +fi # } +LSOF_SCRIPT_CALL="yes" +LSOF_SPMKF="" +LSOF_TMP1="" +LSOF_TMP2="" +LSOF_TMPC_BASE=./lsof_Configure_tmp_ +LSOF_TMPC=${LSOF_TMPC_BASE}$$ +LSOF_TSTBIGF="" +LSOF_TSTSUBD="./tests" +LSOF_TSTCC="${LSOF_TSTSUBD}/config.cc" +LSOF_TSTCFLG="${LSOF_TSTSUBD}/config.cflags" +LSOF_TSTDFLG="" +LSOF_TSTK64=0 +LSOF_TSTKMEM=1 +LSOF_TSTLFF="${LSOF_TSTSUBD}/config.ldflags" +LSOF_TSTLFLG="" +LSOF_TSTVPATH=0 +LSOF_TSTXO="" +LSOF_TSTXOC="${LSOF_TSTSUBD}/config.xobj" +LSOF_UNSUP="WARNING: unsupported dialect or version" +LSOF_UNSUP2="" +if test "X$LSOF_VERS" = "X" # { +then + LSOF_VERS="" +fi # } +if test "X$LSOF_VSTR" = "X" # { +then + LSOF_VSTR="" +fi # } + +# Establish echo type -- Berkeley or SYSV. + +j=`echo -n ""` +if test "X$j" = "X-n " +then + EC="\c" + EO="" +else + EC="" + EO="-n" +fi + +# Make sure temporary files are removed before an abnormal exit. + +trap 'rm -f ${LSOF_HLP_BASE}* ${LSOF_TMPC_BASE}*; exit 1' 1 2 3 15 + +rm -f $LSOF_HLP +cat > $LSOF_HLP << LSOF_HLP +Usage: Configure + : -clean : clean up previous configuration + -d|-dialects : display a list of supported dialect versions + -h|-help : display help information + -n : avoid AFS, customization, and inventory checks + (****USE -d TO GET TESTED DIALECT VERSION NUMBERS****): + aix|aixgcc : IBM AIX xlc (aix) or gcc (aixgcc) + darwin : Apple Darwin + freebsd : FreeBSD + hpux|hpuxgcc : HP-UX cc (hpux) or gcc (hpuxgcc) + linux : Linux + netbsd : NetBSD + openbsd : OpenBSD + osr|sco : SCO OpenServer < 6.0.0, SCO developer's compiler + osrgcc|scogcc : SCO OpenServer < 6.0.0, gcc compiler + osr6 : SCO OpenServer 6.0.0, SCO compiler + solaris|solariscc : Solaris gcc (solaris) or cc (solariscc) + unixware|uw : SCO|Caldera UnixWare +LSOF_HLP + +LSOF_TGT="no-target" + +args=$# +while test $args -gt 0 # { +do + case $1 in # { + -clean) + if test -r $LSOF_MKFC # { + then + echo "$LSOF_MAKE -f $LSOF_MKFC clean" + $LSOF_MAKE -f $LSOF_MKFC clean + else + if test -r ${LSOF_LIB}/${LSOF_LIBMKF} # { + then + echo "(cd ${LSOF_LIB}; $LSOF_MAKE -f ${LSOF_LIBMKF} clean)" + (cd ${LSOF_LIB}; $LSOF_MAKE -f ${LSOF_LIBMKF} clean) + else + if test -r ${LSOF_LIB}/${LSOF_LIBMKF}.skel # { + then + echo "(cd ${LSOF_LIB}; $LSOF_MAKE -f ${LSOF_LIBMKF}.skel clean)" + (cd ${LSOF_LIB}; $LSOF_MAKE -f ${LSOF_LIBMKF}.skel clean) + fi # } + fi # } + fi # } + if test -r ${LSOF_TSTSUBD}/Makefile # { + then + echo "(cd ${LSOF_TSTSUBD}; $LSOF_MAKE spotless)" + (cd ${LSOF_TSTSUBD}; $LSOF_MAKE spotless) + else + echo '(cd ${LSOF_TSTSUBD}; rm *.o config.*)' + (cd ${LSOF_TSTSUBD}; rm *.o config.*) + fi # } + rm -f $LSOF_F $LSOF_MKFC $LSOF_FBSD_ZFS_MKF ${LSOF_TMPC_BASE}* + echo rm -f $LSOF_F $LSOF_MKFC $LSOF_FBSD_ZFS_MKF ${LSOF_TMPC_BASE}* + rm -rf AFSHeaders AFSVersion solaris11 version.h vnode_if.h + echo "rm -rf AFSHeaders AFSVersion solaris11 version.h vnode_if.h" + rm -f ${LSOF_HLP_BASE}* cd9660_node.h lockf_owner.h fbsd_minor.h + echo "rm -f ${LSOF_HLP_BASE}* cd9660_node.h lockf_owner.h fbsd_minor.h" + rm -f opt_kdtrace.h opt_random.h + echo "rm -f opt_kdtrace.h opt_random.h" + rm -f lib/dialects/aix/aix5/j2/j2_snapshot.h + echo "rm -f lib/dialects/aix/aix5/j2/j2_snapshot.h" + rm -f dialects/sun/solaris10 # DEBUG -- for s10_44 + echo "rm -f dialects/sun/solaris10" # DEBUG -- for s10_44 + rm -f dialects/hpux/kmem/hpux_mount.h + echo "rm -f dialects/hpux/kmem/hpux_mount.h" + rm -rf lib/dialects/netbsd/include + echo "rm -rf lib/dialects/netbsd/include" + rm -f dialects/uw/uw7/vm/swap.h + echo "rm -f dialects/uw/uw7/vm/swap.h" + rm -f ${LSOF_LIB}/${LSOF_LIBMKF} + echo "rm -f ${LSOF_LIB}/${LSOF_LIBMKF}" + exit 0 + ;; + + -d|-dialects) + if test -r ./00DIALECTS -a -r ./version # { + then + V=`sed '/VN/s/.ds VN \(.*\)/\1/' version` + echo "lsof $V has been *tested* on these UNIX dialect versions:" + cat 00DIALECTS + echo Although "$V hasn't been tested on other versions of these dialects," + echo "it may work. Try \`Configure \` and \`make\` to see." + rm -f $LSOF_HLP + exit 0 + else + echo "Can't display UNIX dialect version information:" + if test ! -r ./00DIALECTS # { + then + echo " ./00DIALECTS is inaccessible." + fi # } + if test ! -r ./version # { + then + echo " ./version is inaccessible." + fi # } + rm -f $LSOF_HLP + exit 1 + fi # } + ;; + + -h|-help) cat $LSOF_HLP + rm -f $LSOF_HLP + exit 0 + ;; + + -n*) + LSOF_SCRIPT_CALL="no" + ;; + + *) + if test "X$LSOF_TGT" != "Xno-target" # { + then + echo "Only one dialect may be configured at a time." + echo 'Both "$LSOF_TGT" and "$1" were specified.' + cat $LSOF_HLP + rm -f $LSOF_HLP + exit 1 + else + LSOF_TGT=$1 + fi # } + ;; + esac # } + shift + args=`expr $args - 1` +done # } + +case $LSOF_TGT in # { + no-target) + echo "No target dialect was specified." + cat $LSOF_HLP + rm -f $LSOF_HLP + exit 1 + ;; + +# Configure for AIX xlc and AIX gcc. + + aix|aixgcc) + + # AIXA stands for AIX architecture. It is assigned these values in this + # stanza: + # + # 0 The AIX version is < 5.0, or the AIX 5.0 architecture is + # Power and the kernel bit size is 32. + # + # 1 The AIX version is >= 5.0, the AIX architecture is Power, + # and the kernel bit size is 64. + # + # 2 The AIX version is >= 5.0 and the architecture is IA64. + + if test "X$LSOF_RANLIB_SUP" = "X" # { + then + LSOF_RANLIB="@echo \\\\\\\\c" # AIX make doesn't like a null ${RANLIB}. + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + + # If the AIX version isn't pre-defined, determine it. + + LSOF_TMP1=`uname -v` + if test "X$LSOF_TMP1" = "X5" # { + then + + # If the AIX version is 5, build the version string with `uname -rv` + # output. + + LSOF_VSTR=`uname -r | awk '{printf "5.%d.0.0\n",\$1}'` + echo "Uname reports the version is $LSOF_VSTR." + else + + # See if oslevel can determine the version. + + LSOF_TMP1=/usr/bin/oslevel + if test -x $LSOF_TMP1 # { + then + echo "Determining AIX version with $LSOF_TMP1." + echo "This may take a while, depending on your maintenance level." + LSOF_VSTR=`$LSOF_TMP1 | sed 's/[^0-9]*\([0-9\.]*\).*/\1/'` + echo "$LSOF_TMP1 reports the version is $LSOF_VSTR." + else + + # If oslevel can't be used, build the version string with + # `uname -rv` and issue a warning. + + LSOF_VSTR=`uname -rv | awk '{printf "%d.%d.0.0\n",\$2,\$1}'` + echo "WARNING: can't execute $LSOF_TMP1; uname -rv reports" + echo " the version is $LSOF_VSTR; edit CFGF in Makefile and" + echo " lib/Makefile to refine AIXV and LSOF_VSTR." + fi # } + fi # } + fi # } + if test "X$LSOF_VERS" = "X" # { + then + LSOF_VERS=`echo $LSOF_VSTR | sed 's/\.//g'` + fi # } + if test $LSOF_VERS -ge 4320 # { + then + LSOF_TSTBIGF=" " + fi # } + if test "X$LSOF_CC" = "X" # { + then + if test "X$LSOF_TGT" = "Xaixgcc" # { + then + LSOF_CC=gcc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + else + LSOF_CC=cc + fi # } + fi # } + LSOF_TGT="aix" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Prevent use of gcc for AIX below 4.1. + + if test $LSOF_VERS -lt 4100 # { + then + echo "********************************************************" + echo "* Sorry, but gcc can't be used to compile lsof for AIX *" + echo "* versions less than 4.1, because of possible kernel *" + echo "* structure alignment differences between it and xlc. *" + echo "********************************************************" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + + # Test for AFS. + + if test "X$AIX_HAS_AFS" != "X" # { + then + LSOF_AFS=$AIX_HAS_AFS + fi # } + if test "X$LSOF_AFS" != "Xno" # { + then + if test "X$LSOF_AFS" = "Xyes" -o -r ${AFS_VICE}/etc/ThisCell # { + then + if test "X$LSOF_AFS" != "Xyes" # { + then + if test "X$LSOF_SCRIPT_CALL" = "Xno" # { + then + if test -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + else + if test ! -x ./AFSConfig # { + then + echo "Can't find or execute the AFSConfig script" + rm -f $LSOF_HLP + exit 1 + fi # } + ./AFSConfig + if test $? -eq 0 -a -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + fi # } + fi # } + if test "X$LSOF_AFS" = "Xyes" # { + then + if test "X$LSOF_AFSV" = "X" # { + then + if test -r ./AFSVersion # { + then + LSOF_AFSV=`cat ./AFSVersion | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1 \2/' | awk '{printf "%d%02d\n",\$1,\$2}'` + else + echo "!!!FATAL: no ./AFSVersion file. It should have been" + echo " created by a previous AFS configuration run." + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + if test $LSOF_VERS -gt 4330 -o LSOF_AFSV -gt 305 # { + then + echo "!!!FATAL: Lsof does not support AFS on this combination of" + echo " AIX ($LSOF_VERS) and AFS ($LSOF_AFSV) versions." + echo " To disable AFS, set the value of the AIX_HAS_AFS" + echo " environment variable to \"no\"." + rm -f $LSOF_HLP + exit 1 + else + LSOF_CFGF="$LSOF_CFGF -DHAS_AFS=$LSOF_AFSV" + LSOF_DINC="$LSOF_DINC -I`cat ./AFSHeaders`" + if test -r ${LSOF_INCLUDE}/sys/inttypes.h # { + then + grep "^typedef.*int16;" ${LSOF_INCLUDE}/sys/inttypes.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASINT16TYPE" + fi # } + grep "^typedef.*u_int32;" ${LSOF_INCLUDE}/sys/inttypes.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASUINT16TYPE" + fi # } + grep "^typedef.*int32;" ${LSOF_INCLUDE}/sys/inttypes.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASINT32TYPE" + fi # } + fi # } + fi # } + fi # } + fi # } + fi # } + + # Miscellaneous AIX tests + + if test -d ${LSOF_INCLUDE}/nfs # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_NFS" + fi # } + echo $LSOF_CC | grep cc | grep -v gcc > /dev/null + if test $? -eq 0 -a $LSOF_VERS -ge 4140 -a $LSOF_VERS -lt 5000 # { + then + LSOF_CFGL="$LSOF_CFGL -bnolibpath" + fi # } + if test -r ${LSOF_INCLUDE}/sys/socket.h # { + then + grep AF_INET6 ${LSOF_INCLUDE}/sys/socket.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/stat.h # { + then + grep stat64 ${LSOF_INCLUDE}/sys/stat.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSTAT64" + fi # } + fi # } +#DEBUG SANFS if test -r ${LSOF_INCLUDE}/sys/sanfs/sanfsnode.h??? # { +#DEBUG SANFS then +#DEBUG SANFS LSOF_CFGF="$LSOF_CFGF -DHAS_SANFS" +#DEBUG SANFS fi # } + if test $LSOF_VERS -ge 5000 # { + then + + # This is AIX 5 or greater. + + if test -d ${LSOF_INCLUDE}/j2 # { + then + + # The AIX > 5.0 system has jfs2 support. Make the necesssary definitions + # and adjustments. + + rm -f lib/dialects/aix/aix5/j2/j2_snapshot.h + (cd lib/dialects/aix/aix5/j2; ln -s private_j2_snapshot.h j2_snapshot.h) + LSOF_CFGF="$LSOF_CFGF -DHAS_JFS2" + LSOF_CFGF="$LSOF_CFGF -I`pwd`/lib/dialects/aix/aix5" + if test $LSOF_VERS -ge 5200 # { + then + if test -r ${LSOF_INCLUDE}/j2/j2_snapshot.h # { + then + + # The system has its own j2_snapshot.h, so make sure the + # private lsof copy is discarded. + + rm -f lib/dialects/aix/aix5/j2/j2_snapshot.h + fi # } + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Test gcc version for AIX 5.2. + + LSOF_TMP1=`echo $LSOF_CCV | awk -F . '{printf "%d%02d",$1,$2}'` + if test $LSOF_TMP1 -ge 303 # { + then + + # Add gcc >= 3.3 option to handle use of i_dev from the wInode + # anonymous structure reference in the JFS2 inode structure of + # . + + LSOF_CFGF="$LSOF_CFGF -fms-extensions" + fi # } + fi #} + fi # } + fi # } + + # Determine the AIX architecture type and set AIXA accordingly. + + if test "X$AIX_ARCH" = "X" # { + then + uname -a | grep -i ia64 > /dev/null + if test $? -eq 0 # { + then + AIX_ARCH="ia64" + else + AIX_ARCH="" + fi # } + fi # } + if test "X$AIX_ARCH" = "Xia64" # { + then + + # This is AIX >= 5 on ia64. + + LSOF_TSTK64=1 + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Quit if gcc was specified as the compiler, since the gcc options to + # do an ia64 lsof compilation are unknown. + + echo "*************************************************************" + echo "* *" + echo "* !!!!!!!!!!!!!!!!!!!!! FATAL ERROR !!!!!!!!!!!!!!!!!!!!!!! *" + echo "* *" + echo "* Gcc can't be used to compile lsof for AIX 5 and above on *" + echo "* the ia64 architecture. Consult lsof's FAQ (in the file *" + echo "* 00FAQ) for more information. *" + echo "* *" + echo "*************************************************************" + rm -f $LSOF_HLP + exit 1 + fi # } + LSOF_TMP1=2 + if test "X$LSOF_AR" = "X" # { + then + LSOF_AR="/usr/bin/ar cr" + fi # } + LSOF_CFGF="$LSOF_CFGF -q64" + LSOF_CFGL="$LSOF_CFGL -lelf" + else + + # This is AIX >= 5 on Power architecture. + + echo $LSOF_CC | grep cc | grep -v gcc > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGL="$LSOF_CFGL -bnolibpath" + fi # } + if test "X$AIX_KERNBITS" = "X" # { + then + + # The kernel bit size wasn't predefined. Determine it by compiling + # and executing a test program. + + rm -f ${LSOF_TMPC}.* + echo "#include " > ${LSOF_TMPC}.c + echo 'int main(){ if (__KERNEL_32()) printf("32\\n");' >> ${LSOF_TMPC}.c + echo 'else if (__KERNEL_64()) printf("64\\n");' >> ${LSOF_TMPC}.c + echo 'else printf("0\\n");' >> ${LSOF_TMPC}.c + echo "return(0); }" >> ${LSOF_TMPC}.c + echo "Testing kernel bit size with $LSOF_CC" + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x + if test ! -x ${LSOF_TMPC}.x # { + then + echo "!!!FATAL: can't compile test program, ${LSOF_TMPC}.c." + rm -f $LSOF_HLP rm -f ${LSOF_TMPC}.* + exit 1 + fi # } + AIX_KERNBITS=`./${LSOF_TMPC}.x` + rm -f ${LSOF_TMPC}.* + fi # } + + # Use the kernel bit size specification to select archiver and compiler + # options, and to update AIXA. + + case $AIX_KERNBITS in # { + 32) + if test "X$LSOF_AR" = "X" # { + then + LSOF_AR="/usr/bin/ar cr" + fi # } + LSOF_TMP1=0 + ;; + 64) + if test "X$LSOF_AR" = "X" # { + then + LSOF_AR="/usr/bin/ar -X 64 -v -q" + fi # } + LSOF_TSTK64=1 + LSOF_TMP1=1 + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -maix64" + else + LSOF_CFGF="$LSOF_CFGF -q64" + fi # } + ;; + *) + echo "!!!FATAL: unrecognized kernel bit size: $AIX_KERNBITS" + rm -f $LSOF_HLP + exit 1 + esac # } + + # Put kernel bit size information in $LSOF_CINFO and $LSOF_CFGF. + + echo "Kernel bit size: $AIX_KERNBITS" + LSOF_TMP2="${AIX_KERNBITS} bit kernel" + if test "X$LSOF_CINFO" != "X" # { + then + LSOF_CINFO="${LSOF_CINFO} ${LSOF_TMP2}" + else + LSOF_CINFO="${LSOF_TMP2}" + fi # } + LSOF_CFGF="$LSOF_CFGF -DAIX_KERNBITS=${AIX_KERNBITS}" + fi # } + LSOF_CFGF="$LSOF_CFGF -DAIXA=$LSOF_TMP1" + if test "X$LSOF_TSTDFLG" = "X" # { + then + LSOF_TSTDFLG="-DLT_AIXA=$LSOF_TMP1" + else + LSOF_TSTDFLG="$LSOF_TSTDFLG -DLT_AIXA=$LSOF_TMP1" + fi # } + else + + # AIX is < 5, so set AIXA accordingly. + + LSOF_CFGF="$LSOF_CFGF -DAIXA=0" + if test "X$LSOF_TSTDFLG" = "X" # { + then + LSOF_TSTDFLG="-DLT_AIXA=0" + else + LSOF_TSTDFLG="$LSOF_TSTDFLG -DLT_AIXA=0" + fi # } + fi #} + LSOF_CFGF="$LSOF_CFGF -DAIXV=$LSOF_VERS" + LSOF_DIALECT_DIR=aix + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Do gcc tests. + + if test $LSOF_VERS -ge 4100 -a $LSOF_VERS -lt 4200 # { + then + if test "X$AIX_USHACK" = "X" # { + then + + # Compile and run a gcc test program to evaluate the user structure. + + rm -f ${LSOF_TMPC}.* + echo "#include " > ${LSOF_TMPC}.c + echo "#include " >> ${LSOF_TMPC}.c + echo "int main(){exit((offsetof(struct user, U_irss) & 0x7) ? 1 : 0);}" >>${LSOF_TMPC}.c + echo "Testing user.h with $LSOF_CC" + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x + if ! ${LSOF_TMPC}.x # { + then + LSOF_TMP1=1 + else + LSOF_TMP1=0 + fi # } + rm -f ${LSOF_TMPC}.* + else + if test "$AIX_USHACK" = "Y" -o "$AIX_USHACK" = "y" # { + then + LSOF_TMP1=1 + else + LSOF_TMP1=0 + fi # } + fi # } + if test ${LSOF_TMP1} -eq 1 # { + then + echo "Applying gcc AIX 4.1+ user struct alignment hack" + rm -rf ./dialects/aix/aix$LSOF_VERS + mkdir ./dialects/aix/aix$LSOF_VERS + mkdir ./dialects/aix/aix${LSOF_VERS}/sys + sed 's/U_irss\[/dummy_for_alignment, U_irss\[/' < ${LSOF_INCLUDE}/sys/user.h > ./dialects/aix/aix${LSOF_VERS}/sys/user.h + LSOF_CFGF="$LSOF_CFGF -U_LONG_LONG -I`pwd`/dialects/aix/aix$LSOF_VERS" + fi # } + fi # } + else + + # Get xlc version number + + rm -f ${LSOF_TMPC}.* + echo "int main(){}" > ${LSOF_TMPC}.c + echo "Getting version number of ${LSOF_CC}." + $LSOF_CC -c ${LSOF_TMPC}.c -I${LSOF_INCLUDE} -o ${LSOF_TMPC}.o -qlist > /dev/null 2>&1 + LSOF_CCV=`head -1 ${LSOF_TMPC}.lst | sed 's/\(.*\) ---.*/\1/'` + rm ${LSOF_TMPC}.* + echo "The version is \"${LSOF_CCV}\"." + echo $LSOF_CCV | grep "Version [0-9]" > /dev/null + if test $? -eq 0 # { + then + LSOF_TMP=`echo $LSOF_CCV | sed 's/.*Version \([0-9]*\).*/\1/'` + if test "X$LSOF_TMP" != "X" -a $LSOF_TMP -ge 4 # { + then + if test $LSOF_TMP -ge 6 # { + then + LSOF_CFGF="$LSOF_CFGF -qmaxmem=-1" + else + LSOF_CFGF="$LSOF_CFGF -qmaxmem=16384" + fi # } + fi # } + fi # } + fi # } + if test $LSOF_VERS -ge 5300 # { + then + LSOF_UNSUP="" + fi # } + ;; + +# Configure for Apple Darwin. + + darwin) + if test "X$LSOF_CC" = "X" # { + then + LSOF_CC=cc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the Darwin / Mac OS X version isn't pre-defined, determine it. + + case $LSOF_VSTR in # { + 1.2*) + LSOF_VERS=120 + ;; + 1.3*) + LSOF_VERS=130 + ;; + 1.4*) + LSOF_VERS=140 + ;; + 5.[012]*) + LSOF_VERS=500 + ;; + 5.[3-9]*) + LSOF_VERS=530 + ;; + 6.*) + LSOF_VERS=600 + ;; + 7.*) # Mac OS X 10.3 (Panther) + LSOF_VERS=700 + ;; + 8.*) # Mac OS X 10.4 (Tiger) + LSOF_VERS=800 + ;; + 9.*) # Mac OS X 10.5 (Leopard) + LSOF_VERS=900 + ;; + 10.*) # Mac OS X 10.6 (SnowLeopard) + LSOF_VERS=1000 + ;; + 11.*) # Mac OS X 10.7 (Lion) + LSOF_VERS=1100 + ;; + 12.*) # Mac OS X 10.8 (Mountain Lion) + LSOF_VERS=1200 + ;; + 13.*) # Mac OS X 10.9 (Mavericks) + LSOF_VERS=1300 + ;; + 14.*) # Mac OS X 10.10 (Yosemite) + LSOF_VERS=1400 + ;; + 15.*) # Mac OS X 10.11 (El Capitan) + LSOF_VERS=1500 + ;; + 16.*) # macOS 10.12 (Sierra) + LSOF_VERS=1600 + ;; + 17.*) # macOS 10.13 (High Sierra) + LSOF_VERS=1700 + ;; + 18.*) # macOS 10.14 (Mojave) + LSOF_VERS=1800 + ;; + 19.*) # macOS 10.15 (Catalina) + LSOF_VERS=1900 + ;; + *) + echo Unknown Darwin release: `uname -r` + echo Assuming Darwin 19.0 + LSOF_VERS=1900 + ;; + esac # } + fi # } + + # Do Darwin version-specific stuff. + + case $LSOF_VERS in # { + 120|130) + LSOF_TMP1="hfs/hfs.h hfs/hfs_macos_defs.h miscfs/devfs/devfsdefs.h miscfs/devfs/devfs_proto.h miscfs/fdesc/fdesc.h" + ;; + 140|500) + LSOF_TMP1="hfs/hfs.h hfs/hfs_macos_defs.h hfs/rangelist.h miscfs/devfs/devfsdefs.h miscfs/devfs/devfs_proto.h miscfs/fdesc/fdesc.h" + ;; + 530) + LSOF_TMP1="hfs/hfs.h hfs/hfs_macos_defs.h hfs/rangelist.h miscfs/devfs/devfsdefs.h miscfs/devfs/devfs_proto.h miscfs/fdesc/fdesc.h net/ndrv.h net/ndrv_var.h" + ;; + 600) + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + LSOF_TMP1="hfs/hfs.h hfs/hfs_catalog.h hfs/hfs_cnode.h hfs/hfs_macos_defs.h hfs/rangelist.h miscfs/devfs/devfsdefs.h miscfs/devfs/devfs_proto.h miscfs/fdesc/fdesc.h net/ndrv_var.h net/raw_cb.h netinet/ip_var.h netinet/tcp_var.h" + ;; + 700) + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + LSOF_TMP1="hfs/hfs.h hfs/hfs_catalog.h hfs/hfs_cnode.h hfs/hfs_macos_defs.h hfs/rangelist.h miscfs/devfs/devfsdefs.h miscfs/devfs/devfs_proto.h miscfs/fdesc/fdesc.h net/ndrv_var.h net/raw_cb.h netinet/ip_var.h netinet/tcp_var.h sys/eventvar.h" + ;; + 800) + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + LSOF_TMP1="net/ndrv_var.h net/raw_cb.h netinet/ip_var.h netinet/tcp_var.h sys/eventvar.h sys/file_internal.h sys/mount_internal.h sys/proc_internal.h sys/vnode_internal.h" + ;; + 900|1000|1100|1200) + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + LSOF_TMP1="" + LSOF_UNSUP="" + LSOF_TSTBIGF=" " # enable LTbigf test + if test $LSOF_VERS -eq 900 # { + then + LSOF_CFGF="$LSOF_CFGF -DNEEDS_MACH_PORT_T" + fi # } + ;; + 1300|1400|1500|1600|1700|1800|1900) + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + LSOF_TMP1="" + LSOF_UNSUP="" + LSOF_TSTBIGF=" " # enable LTbigf test + ;; + *) + echo "Unsupported Darwin version: $LSOF_VERS" + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + LSOF_TMP2="" + LSOF_TMP3="" + LSOF_TMP4="" + LSOF_CFGF="$LSOF_CFGF -mdynamic-no-pic" + LSOF_CFGL="$LSOF_CFGL -lcurses" + + # Test Darwin base. + + if test "X$DARWIN_BASE" = "X" -o "X$DARWIN_BASE" = "Xlibproc" # { + then + LSOF_TMP5="" + if test $LSOF_VERS -ge 800 -o "X$DARWIN_BASE" = "Xlibproc" # { + then + if test -r ${LSOF_INCLUDE}/libproc.h # { + then + DARWIN_BASE="libproc" + else + if test -r ${LSOF_INCLUDE}/../local/include/libproc.h # { + then + DARWIN_BASE="libproc" + LSOF_TMP5="${LSOF_INCLUDE}/../local/include" + else + if test -r /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libproc.h # { + then + DARWIN_BASE="libproc" + LSOF_TMP5="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/" + else + echo "FATAL: can't find libproc.h" + rm -f $LSOF_HLP + exit 1 + fi + fi # } + fi # } + else + + # The default Darwin base is libproc + + DARWIN_BASE="libproc" + fi # } + fi # } + + if test "X$DARWIN_BASE" = "Xlibproc" # { + then + + # Configure for libproc-based Darwin lsof. + + echo "Configuring libproc-based Darwin lsof" + LSOF_CINFO="libproc-based" + LSOF_DIALECT_DIR=darwin + if test $LSOF_VERS -lt 1000 # { + then + LSOF_CFGL="$LSOF_CFGL -lproc" + fi # } + LSOF_TSTKMEM=0 + if test "X$LSOF_TMP5" != "X" # { + then + LSOF_DINC="$LSOF_DINC -I$LSOF_TMP5" + fi # } + if test ! -r ${LSOF_INCLUDE}/sys/proc_info.h # { + then + if test "X$LSOF_TMP5" = "X" -o ! -r ${LSOF_TMP5}/sys/proc_info.h # { + then + echo "FATAL: can't find sys/proc_info.h" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + + # Add header file paths for libproc-based Darwin lsof. + + for i in $LSOF_TMP3 $LSOF_TMP4 $LSOF_INCLUDE # { + do + if test -d $i -a "X$i" != "X/usr/include" # { + then + LSOF_DINC="$LSOF_DINC -I${i}" + fi # } + done # } + + # Do other libproc-based Darwin lsof setups. + + if test -r ${LSOF_INCLUDE}/utmpx.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASUTMPX" + fi # } + fi # } + LSOF_CFGF="$LSOF_CFGF -DDARWINV=$LSOF_VERS" + LSOF_CFLAGS_OVERRIDE=1 + ;; + +# Configure for FreeBSD. + + freebsd) + LSOF_FBSD_ZFS=0 + LSOF_TSTKMEM=0 + if test "X$LSOF_CC" = "X" # { + then + LSOF_CC=cc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the FreeBSD version isn't pre-defined, determine it. + + case $LSOF_VSTR in # { + 12*) + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_TSTBIGF=" " + LSOF_VERS=12000 + ;; + 13*) + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_TSTBIGF=" " + LSOF_VERS=13000 + ;; + 14*) + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_TSTBIGF=" " + LSOF_VERS=14000 + ;; + 15*) + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_TSTBIGF=" " + LSOF_VERS=15000 + ;; + *) + echo Unknown FreeBSD release: `uname -r` + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + fi # } + + # Clear LSOF_UNSUP message for supported versions of FreeBSD. + + case $LSOF_VERS in # { + 12000|13000|14000) + LSOF_UNSUP="" + ;; + esac # } + + # Get system CFLAGS, if possible. + + LSOF_TMP1=`echo "all:\n.include " | $LSOF_MAKE -f- -VCFLAGS` + LSOF_TMP=1 + while test $LSOF_TMP -eq 1 # { + do + echo $LSOF_TMP1 | grep -q -e '-O' + if test $? -eq 0 # { + then + if test "X$LSOF_DEBUG" = "X" + then # { + LSOF_DEBUG=`echo $LSOF_TMP1 | sed 's/.*\(-O[^ $]*\).*/\1/'` + fi # } + LSOF_TMP1=`echo $LSOF_TMP1 | sed 's/\(.*\)-O[^ $]*\(.*\)/\1 \2/' | sed 's/^ *//g' | sed 's/ */ /g' | sed 's/ *$//'` + else + LSOF_TMP=0 + fi # } + LSOF_FBSD_ZFS_CFGF="$LSOF_CFGF $LSOF_TMP1" + done # } + LSOF_CFGF="$LSOF_CFGF $LSOF_TMP1" + echo $LSOF_CFGF | grep -q NEEDS_BOOL_TYPEDEF + if test $? -ne 0 + then # { + LSOF_CFGF="$LSOF_CFGF -DNEEDS_BOOL_TYPEDEF" + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DNEEDS_BOOL_TYPEDEF" + fi # } + + # Determine path to FreeBSD sources. + + LSOF_DINC_ADD=0 + if test "X$FREEBSD_SYS" = "X" # { + then + if test -d /usr/src/sys # { + then + FREEBSD_SYS=/usr/src/sys + else + if test -d /sys # { + then + FREEBSD_SYS="/sys" + else + echo "!!!WARNING!!! No kernel sources in /usr/src/sys or /sys (set FREEBSD_SYS)" + fi # } + fi # } + fi # } + + # Test for thread (task) support. + + if test -r ${LSOF_INCLUDE}/sys/user.h # { + then + grep -q ki_numthreads ${LSOF_INCLUDE}/sys/user.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASTASKS" + fi # } + else + echo "FATAL: can't find sys/user.h" + rm -f $LSOF_HLP + exit 1 + fi # } + + # All supported FreeBSD releases have closefrom and dup2. + LSOF_CFGF="$LSOF_CFGF -DHAS_DUP2" + LSOF_CFGF="$LSOF_CFGF -DHAS_CLOSEFROM" + + # Do FreeBSD version-specific stuff. + + case $LSOF_VERS in # { + 1000) + LSOF_CFGF="$LSOF_CFGF" + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_DINC="$LSOF_DINC -I`pwd`/dialects/freebsd/include" + if test "X$FREEBSD_KERNEL" = "X" # { + then + LSOF_N_UNIXV="/386bsd" + else + LSOF_N_UNIXV=$FREEBSD_KERNEL + fi # } + ;; + 2000|2005|2010) + LSOF_CFGL="$LSOF_CFGL -lkvm" + ;; + 2020) + LSOF_CFGL="$LSOF_CFGL -lkvm" + if test -r ${LSOF_INCLUDE}/vm/lock.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVMLOCKH" + fi # } + ;; + 3000|3010|3020|3030|3040|3050) + LSOF_CFGL="$LSOF_CFGL -lkvm" + if test -r ${LSOF_INCLUDE}/nfs/rpcv2.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASRPCV2H" + fi # } + if test -r ${LSOF_INCLUDE}/vm/lock.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVMLOCKH" + fi # } + ;; + *) + if test -r ${LSOF_INCLUDE}/nfs/rpcv2.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASRPCV2H" + fi # } + if test -r ${LSOF_INCLUDE}/sys/namei.h # { + then + grep -q "^struct[ ]*namecache[ ]*{" ${LSOF_INCLUDE}/sys/namei.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNAMECACHE" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/ufs/ufs/inode.h # { + then + grep -q i_effnlink ${LSOF_INCLUDE}/ufs/ufs/inode.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASEFFNLINK=i_effnlink" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/file.h # { + then + grep -q f_vnode ${LSOF_INCLUDE}/sys/file.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASF_VNODE" + fi # } + fi # } + LSOF_CFGL="$LSOF_CFGL -lkvm" + if test $LSOF_VERS -ge 5000 # { + then + + # Do FreeBSD 5 and higher version-specific stuff. + + if test -r ${LSOF_INCLUDE}/sys/vnode.h # { + then + grep VT_FDESC ${LSOF_INCLUDE}/sys/vnode.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + if test ! -r ${LSOF_INCLUDE}/fs/devfs/devfs.h # { + then + if test -r ${FREEBSD_SYS}/fs/devfs/devfs.h # { + then + LSOF_DINC_ADD=1 + else + echo "!!!FATAL: lsof cannot locate the devfs.h header file" + echo " in ${LSOF_INCLUDE}/fs/devfs/devfs.h or" + echo " ${FREEBSD_SYS}/fs/devfs/devfs.h. Consult" + echo " 00FAQ for an explanation." + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + fi # } + fi # } + if test -r ${FREEBSD_SYS}/sys/filedesc.h # { + then + grep -q filedescent ${FREEBSD_SYS}/sys/filedesc.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_FILEDESCENT" + fi # } + fi # } + if test -r ${FREEBSD_SYS}/fs/tmpfs/tmpfs.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_TMPFS" + fi #} + + # Do FreeBSD 5.2 and higher version-specific stuff. + + if test -r ${LSOF_INCLUDE}/wctype.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASWCTYPE_H" + fi # } + if test $LSOF_VERS -ge 5020 # { + then + + # Determine the status of the cpumask_t typedef. + + rm -f ${LSOF_TMPC}.* + cat > ${LSOF_TMPC}.c << .LSOF_END_HERE_DOC3 +#undef _KERNEL +#include +int main() { +cpumask_t c; +} +.LSOF_END_HERE_DOC3 + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + LSOF_TMP1=$? + rm -f ${LSOF_TMPC}.* + if test $LSOF_TMP1 -ne 0 # { + then + + # The cpumask_t typedef is unknown when _KERNEL is not defined. + + if test -r ${LSOF_INCLUDE}/sys/types.h \ + -a -r ${LSOF_INCLUDE}/machine/_types.h # { + then + grep -q cpumask_t ${LSOF_INCLUDE}/sys/types.h + if test $? -eq 0 # { + then + grep -q __cpumask_t ${LSOF_INCLUDE}/machine/_types.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASCPUMASK_T" + else + $LSOF_CC -E ${LSOF_INCLUDE}/machine/_types.h 2>/dev/null | grep -q __cpumask_t + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASCPUMASK_T" + fi # } + fi # } + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/socketvar.h # { + then + grep -q SBS_CANT ${LSOF_INCLUDE}/sys/socketvar.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSBSTATE" + fi # } + fi # } + fi # } + if test $LSOF_VERS -ge 5030 # { + then + + # Do FreeBSD 5.3 and higher version-specific stuff. + + if test -r ${LSOF_INCLUDE}/sys/vnode.h # { + then + grep -q "defined(_KVM_VNODE)" ${LSOF_INCLUDE}/sys/vnode.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_KVM_VNODE" + fi #} + fi # } + fi # } + if test $LSOF_VERS -ge 6000 # { + then + + # Do FreeBSD 6.0 and higher version-specific stuff. + + if test -r ${LSOF_INCLUDE}/sys/_types.h # { + then + grep __dev_t ${LSOF_INCLUDE}/sys/_types.h | grep -q 64 + if test $? -eq 0 # { + then + if test "X$LSOF_TSTDFLG" = "X" # { + then + LSOF_TSTDFLG="-DLT_DEV64" + else + LSOF_TSTDFLG="$LSOF_TSTDFLG -DLT_DEV64" + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/ufs/ufs/inode.h # { + then + grep -q i_din2 ${LSOF_INCLUDE}/ufs/ufs/inode.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_UFS1_2" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/conf.h # { + then + grep -q vm_memattr_t ${LSOF_INCLUDE}/sys/conf.h + if test $? -eq 0 #{ + then + LSOF_CFGF="$LSOF_CFGF -DHAS_VM_MEMATTR_T" + fi # } + grep -q device_t ${LSOF_INCLUDE}/sys/eventhandler.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DNEEDS_DEVICE_T" + fi # } + grep -q "^#define minor(" ${LSOF_INCLUDE}/sys/conf.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CONF_MINOR" + rm -f fbsd_minor.h + if test -r ${LSOF_INCLUDE}/sys/types.h # { + then + LSOF_TMP1=`grep "^#define[ ]minor(" ${LSOF_INCLUDE}/sys/types.h` + if test "X$LSOF_TMP1" != "X" # { + then + echo "Creating fbsd_minor.h" + cat > fbsd_minor.h << FBSD_MINOR1 +/* + * fbsd_minor.h -- created by lsof Configure script on +FBSD_MINOR1 + echo $EO " * $EC" >> ./fbsd_minor.h + date >> ./fbsd_minor.h + cat >> ./fbsd_minor.h << FBSD_MINOR2 + */ + +#if !defined(FBSD_MINOR_H) +#define FBSD_MINOR_H + +FBSD_MINOR2 + echo $EO "${LSOF_TMP1}${EC}" >> fbsd_minor.h + cat >> ./fbsd_minor.h << FBSD_MINOR3 + +#endif /* defined(FBSD_MINOR_H) */ +FBSD_MINOR3 + fi # } + fi # } + else + if test -r ${FREEBSD_SYS}/fs/devfs/devfs_int.h # { + then + grep -q cdev2priv ${FREEBSD_SYS}/fs/devfs/devfs_int.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CDEV2PRIV" + fi # } + fi # } + fi # } + grep -q si_priv ${LSOF_INCLUDE}/sys/conf.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SI_PRIV" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/sx.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SYS_SX_H" + fi # } + + # Do msdosfs test. + if test -r ${FREEBSD_SYS}/fs/msdosfs/denode.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASMSDOSFS" + fi # } + # Do ZFS test. Try for the newer OpenSolaris files first -- i.e., + # the ones in ${FREEBSD_SYS}/cddl/contrib/opensolaris. If that fails, + # try for the older ones in ${FREEBSD}/contrib/opensolaris. + + LSOF_FBSD_ZFS_SYS=${FREEBSD_SYS}/cddl + if test ! -r ${LSOF_FBSD_ZFS_SYS}/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h # { + then + LSOF_FBSD_ZFS_SYS=${FREEBSD_SYS} + if test ! -r ${LSOF_FBSD_ZFS_SYS}/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h # { + then + LSOF_FBSD_ZFS_SYS="" + fi # } + fi # } + if test "X$LSOF_FBSD_ZFS_SYS" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_ZFS" + LSOF_FBSD_ZFS=1 + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DFREEBSDV=$LSOF_VERS" + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DHAS_ZFS" + grep -q z_phys ${LSOF_FBSD_ZFS_SYS}/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h + if test $? -eq 0 # { + then + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DHAS_Z_PHYS" + fi # } + if test -r ${LSOF_FBSD_ZFS_SYS}/compat/opensolaris/sys/sdt.h #{ + then + grep -q opt_kdtrace.h ${LSOF_FBSD_ZFS_SYS}/compat/opensolaris/sys/sdt.h + if test $? -eq 0 # { + then + rm -f opt_kdtrace.h + touch opt_kdtrace.h + fi # } + fi # } + if test -r ${LSOF_FBSD_ZFS_SYS}/compat/opensolaris/sys/kcondvar.h #{ + then + grep -q cv_timedwait_sbt ${LSOF_FBSD_ZFS_SYS}/compat/opensolaris/sys/kcondvar.h + if test $? -eq 0 # { + then + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DHAS_CV_TIMEDWAIT_SBT" + fi # } + fi #} + if test -r /usr/include/sys/random.h # { + then + grep -q opt_random.h /usr/include/sys/random.h + if test $? -eq 0 # { + then + rm -f opt_random.h + touch opt_random.h + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/vnode.h # { + then + + # See if the vnode contains the byte level lock pointer. + + grep -q v_lockf ${LSOF_INCLUDE}/sys/vnode.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_V_LOCKF" + if test $LSOF_FBSD_ZFS -eq 1 # { + then + LSOF_FBSD_ZFS_CFGF="$LSOF_FBSD_ZFS_CFGF -DHAS_V_LOCKF" + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/lockf.h # { + then + + # Determine the type of locking structure to which the inode or + # vnode points. + + grep -q "^struct lockf_entry" ${LSOF_INCLUDE}/sys/lockf.h + if test $? -eq 0 # { + then + + # Build the ./lockf_owner.h header file. + + LSOF_TMP1="" + LSOF_TMP2=0 + echo "Creating ./lockf_owner.h from ${FREEBSD_SYS}/kern/kern_lockf.c" + rm -f ./lockf_owner.h + if test -r ${FREEBSD_SYS}/kern/kern_lockf.c # { + then + LSOF_TMP1=`grep -n "^struct lock_owner {" ${FREEBSD_SYS}/kern/kern_lockf.c | sed 's/\([0-9]*\):.*$/\1/'` + if test "X$LSOF_TMP1" != "X" # { + then + LSOF_TMP2=0 + for i in `grep -n "};" ${FREEBSD_SYS}/kern/kern_lockf.c | sed 's/\([0-9]*\):.*$/\1/'` # { + do + if test $LSOF_TMP2 -eq 0 -a $i -gt $LSOF_TMP1 # { + then + LSOF_TMP2=$i + fi # } + done # } + if test $LSOF_TMP2 -eq 0 # { + then + LSOF_TMP1="" + else + cat > ./lockf_owner.h << LOCKF_OWNER1 +/* + * lockf_owner.h -- created by lsof Configure script on +LOCKF_OWNER1 + echo $EO " * $EC" >> ./lockf_owner.h + date >> ./lockf_owner.h + cat >> ./lockf_owner.h << LOCKF_OWNER2 + */ + +#if !defined(LOCKF_OWNER_H) +#define LOCKF_OWNER_H + +LOCKF_OWNER2 + ed -s ${FREEBSD_SYS}/kern/kern_lockf.c >> ./lockf_owner.h << LOCKF_OWNER3 +${LSOF_TMP1},${LSOF_TMP2}p +LOCKF_OWNER3 + if test $? -ne 0 # { + then + LSOF_TMP1="" + else + cat >> ./lockf_owner.h << LOCKF_OWNER4 + +#endif /* defined(LOCKF_OWNER_H) */ +LOCKF_OWNER4 + fi # } + fi # } + fi # } + else + echo "FATAL ERROR: can't read ${FREEBSD_SYS}/kern/kern_lockf.c" + fi # } + if test "X$LSOF_TMP1" != "X" -a "X$LSOF_TMP2" != "X0" # { + then + echo "./lockf_owner.h creation succeeded." + LSOF_CFGF="$LSOF_CFGF -DHAS_LOCKF_ENTRY" + else + echo "FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + + # Test for in6p_.port in inpcb structure. + + if test -r ${LSOF_INCLUDE}/netinet/in_pcb.h # { + then + grep -q 'in6p_.port' ${LSOF_INCLUDE}/netinet/in_pcb.h + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_NO_6PORT" + fi # } + fi # } + + # Test for in6p_ppcb in inpcb structure. + + if test -r ${LSOF_INCLUDE}/netinet/in_pcb.h # { + then + grep -q 'in6p_ppcb' ${LSOF_INCLUDE}/netinet/in_pcb.h + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_NO_6PPCB" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/conf.h # { + then + grep -q 'doadump(boolean_t)' ${LSOF_INCLUDE}/sys/conf.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DNEEDS_BOOLEAN_T" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/sockbuf.h # { + then + grep -q 'u_int sb_ccc;' ${LSOF_INCLUDE}/sys/sockbuf.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SB_CCC" + fi # } + fi # } + fi # } + fi # } + fi # } + if test $LSOF_VERS -eq 10000 # { + then + + # Do specific FreeBSD 10 version-specific stuff. + + LSOF_TMP1=`uname -m` + if test "X$LSOF_TMP1" = "Xi386" # { + then + LSOF_CFGF="$LSOF_CFGF -DNEEDS_BOOL_TYPEDEF" + fi # } + fi # } + ;; + esac # } + LSOF_CFGF="$LSOF_CFGF -DFREEBSDV=$LSOF_VERS" + if test $LSOF_VERS -lt 2000 -a "X$FREEBSD_KERNEL" = "X" # { + then + if test ! -x $LSOF_N_UNIXV # { + then + echo "Hmmm -- $LSOF_N_UNIXV doesn't appear to be your kernel file." + echo "Please enter the name of the file in / that contains" + echo "the kernel for this host. It must be a regular file," + echo "not a directory, and must be executable." + LSOF_LOOP=1 + while test $LSOF_LOOP = 1 # { + do + echo "" + echo "/ contains:" + echo "" + ls -CF / + echo "" + echo -n "Kernel file name? " + read LSOF_N_UNIXV LSOF_EXCESS + LSOF_N_UNIXV="/$LSOF_N_UNIXV" + if test ! -d $LSOF_N_UNIXV -a -x $LSOF_N_UNIXV # { + then + LSOF_LOOP=0 + else + echo "" + echo $LSOF_N_UNIXV is not a regular executable file. + fi # } + done # } + fi # } + LSOF_N_UNIXV=`echo $LSOF_N_UNIXV | sed 's#^/*#/#'` + LSOF_CFGF="$LSOF_CFGF -DN_UNIXV=$LSOF_N_UNIXV" + fi # } + if test -r ${FREEBSD_SYS}/miscfs/fdesc/fdesc.h # { + then + LSOF_TMP1=${FREEBSD_SYS}/miscfs/fdesc/fdesc.h + else + if test $LSOF_VERS -ge 5000 -a -r ${LSOF_INCLUDE}/fs/fdescfs/fdesc.h # { + then + LSOF_TMP1=${LSOF_INCLUDE}/fs/fdescfs/fdesc.h + else + LSOF_TMP1="" + fi # } + fi # } + if test "X$LSOF_TMP1" != "X" # { + then + grep -q Fctty $LSOF_TMP1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASFDESCFS=1" + else + LSOF_CFGF="$LSOF_CFGF -DHASFDESCFS=2" + fi # } + grep -q fd_link $LSOF_TMP1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASFDLINK" + fi # } + LSOF_DINC_ADD=1 + fi # } + if test $LSOF_VERS -ge 5000 # { + then + LSOF_TMP1="fs" + else + LSOF_TMP1="miscfs" + fi # } + LSOF_CFGF="$LSOF_CFGF -DHASPROCFS" + if test -d ${FREEBSD_SYS}/${LSOF_TMP1}/pseudofs # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPSEUDOFS" + LSOF_DINC_ADD=1 + fi # } + if test -r ${LSOF_INCLUDE}/${LSOF_TMP1}/nullfs/null.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNULLFS" + else + if test -r ${FREEBSD_SYS}/${LSOF_TMP1}/nullfs/null.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNULLFS" + LSOF_DINC_ADD=1 + fi # } + fi # } + if test -r ${FREEBSD_SYS}/isofs/cd9660/cd9660_node.h # { + then + ISOFS_DIR="${FREEBSD_SYS}/isofs/cd9660" + else + if test -r ${FREEBSD_SYS}/fs/cd9660/cd9660_node.h # { + then + ISOFS_DIR="${FREEBSD_SYS}/fs/cd9660" + fi # } + fi # } + if test "X$ISOFS_DIR" != "X" # { + then + rm -f cd9660_node.h + grep -q "^#ifdef [_]*KERNEL" ${ISOFS_DIR}/cd9660_node.h + if test $? -eq 0 # { + then + ln -s ${ISOFS_DIR}/cd9660_node.h cd9660_node.h + else + sed -e '/^ \* Prototypes for ISOFS vnode operations/,$c\ + \ The ISOFS prototypes were removed by Configure. */' \ + < ${ISOFS_DIR}/cd9660_node.h > cd9660_node.h + echo "" >> cd9660_node.h + fi # } + LSOF_CFGF="$LSOF_CFGF -DHAS9660FS" + fi # } + if test -r ${LSOF_INCLUDE}/sys/namei.h + then + grep -q nc_vpid ${LSOF_INCLUDE}/sys/namei.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNCVPID" + fi # } + fi # } + if test $LSOF_DINC_ADD -eq 1 # { + then + if test "X$LSOF_DINC" = "X" # { + then + LSOF_DINC="-I${FREEBSD_SYS}" + else + LSOF_DINC="$LSOF_DINC -I${LSOF_INCLUDE} -I${FREEBSD_SYS}" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/netinet/in.h # { + then + grep IPV6_INRIA_VERSION ${LSOF_INCLUDE}/netinet/in.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6 -DHASINRIAIPv6" + fi # } + fi # } + echo $CFGF | grep HASIPv6 > /dev/null + if test $? -ne 0 -a -r ${LSOF_INCLUDE}/netinet6/in6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + if test -r ${LSOF_INCLUDE}/utmpx.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASUTMPX" + fi # } + + # Does struct xtcpcb have t_maxseg? + rm -f ${LSOF_TMPC}.* + cat > ${LSOF_TMPC}.c << .LSOF_END_HERE_DOC4 +#undef _KERNEL +#include +#include +#include +#include +#include +#include +#include +int main() { +struct xtcpcb pcb; pcb.t_maxseg = 0; +} +.LSOF_END_HERE_DOC4 + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_XTCPCB_TMAXSEG" + fi # } + rm -f ${LSOF_TMPC}.* + + # Does struct kinfo_file have kf_un.kf_sock.kf_sock_sendq? + grep -q kf_sock_sendq ${LSOF_INCLUDE}/sys/user.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_KF_SOCK_SENDQ" + fi # } + + # Does struct kinfo_file have kf_un.kf_file.kf_file_nlink? + grep -q kf_file_nlink ${LSOF_INCLUDE}/sys/user.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_KF_FILE_NLINK" + fi # } + + LSOF_DIALECT_DIR=freebsd + ;; + +# Configure for HP-UX and HP-UX gcc. + + hpux|hpuxgcc) + if test "X$LSOF_RANLIB_SUP" = "X" # { + then + LSOF_RANLIB="" + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the HP-UX version isn't pre-defined, determine it. + + LSOF_VERS=`echo $LSOF_VSTR | awk -F. '{printf "%d%02d",\$2,\$3}'` + fi # } + if test $LSOF_VERS -ge 1020 # { + then + LSOF_TSTBIGF="-D_LARGEFILE64_SOURCE" + fi # } + + # Determine compiler. + + if test "X$LSOF_CC" = "X" # { + then + if test "X$LSOF_TGT" = "Xhpuxgcc" # { + then + LSOF_CC=gcc + else + if test "X$HPUX_CCDIR1" = "X" # { + then + HPUX_CCDIR1="/bin" + fi # } + if test "X$HPUX_CCDIR2" = "X" # { + then + HPUX_CCDIR2="/usr/ccs/bin" + fi # } + if test -x ${HPUX_CCDIR1}/cc # { + then + LSOF_CC=${HPUX_CCDIR1}/cc + else + if test -x ${HPUX_CCDIR2}/cc # { + then + LSOF_CC=${HPUX_CCDIR2}/cc + else + echo "No executable cc in $HPUX_CCDIR1 or $HPUX_CCDIR2" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + $LSOF_CC -O < /dev/null 2>&1 | grep -q Bundled + if test $? -eq 0 # { + then + LSOF_DEBUG="No-O" # to disable -O + if test "X$HPUX_LIBC1" = "X" # { + then + HPUX_LIBC1="/usr/lib" + fi # } + if test -r ${HPUX_LIBC1}/libc.sl # { + then + LSOF_FCFGL="-L$HPUX_LIBC -lc" + else + if test "X$HPUX_LIBC2" = "X" # { + then + HPUX_LIBC2="/usr/lib" + fi # } + if test -r ${HPUX_LIBC2}/libc.sl # { + then + LSOF_FCFGL="-L$HPUX_LIBC2 -lc" + fi # } + fi # } + fi # } + fi # } + fi # } + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + else + $LSOF_CC -O < /dev/null 2>&1 | grep -q Bundled + if test $? -eq 0 # { + then + LSOF_DEBUG="No-O" # to disable -O + fi # } + fi # } + LSOF_TGT=hpux + + # Test for "const void" support. + + rm -f ${LSOF_TMPC}.* + echo "int main() { const void *x; return(0); }" >> $LSOF_TMPC.c + $LSOF_CC $LSOF_TMPC.c -o $LSOF_TMPC.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CONST" + fi # } + rm -f ${LSOF_TMPC}.* + + # Test HP-UX base. + + if test "X$HPUX_BASE" = "X" # { + then + if test -d $LSOF_INCLUDE/sys/pstat -a $LSOF_VERS -ge 1111 # { + then + HPUX_BASE="pstat" + else + HPUX_BASE="/dev/kmem" + fi # } + fi # } + if test "X$HPUX_BASE" = "Xpstat" # { + then + + # Configure for pstat-based HP-UX lsof. + + LSOF_CINFO="PSTAT-based" + echo "Configuring PSTAT-based HP-UX lsof" + LSOF_DIALECT_DIR=hpux/pstat + LSOF_CFGF="$LSOF_CFGF -DHPUXV=$LSOF_VERS -D_PSTAT64" + LSOF_CFGL="$LSOF_CFGL -lnsl" + LSOF_TSTKMEM=0 + LSOF_TSTK64=1 + ls -l $LSOF_CC | grep -q ansic + LSOF_TMP1=$? + ls -l $LSOF_CC | grep -q aCC + if test $? -eq 0 -o $LSOF_TMP1 -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -Ae +DD32" + else + echo $LSOF_CC | grep -q gcc + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF +DD32" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/netinet/in6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + if test -r ${LSOF_INCLUDE}/sys/pstat/stream_pstat_body.h # { + then + grep -q PS_STR_XPORT_DATA ${LSOF_INCLUDE}/sys/pstat/stream_pstat_body.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -D_PSTAT_STREAM_GET_XPORT" + fi # } + fi # } + if test $LSOF_VERS -ge 1123 # { + then + LSOF_CFGF="$LSOF_CFGF -D_LARGEFILE64_SOURCE" + fi # } + else + if test "X$HPUX_BASE" = "X/dev/kmem" # { + then + + # Configure for /dev/kmem-based HP-UX lsof. + + if test "X$HPUX_BOOTFILE" = "X" # { + then + HPUX_BOOTFILE="/stand/vmunix" + fi # } + if test $LSOF_VERS -gt 1100 # { + then + echo "" + echo "************************************************" + echo "* *" + echo "* !!!!!!!!!!!!!!! FATAL ERROR !!!!!!!!!!!!!!!! *" + echo "* *" + echo "* LSOF DOES NOT SUPPORT THIS VERSION OF HP-UX. *" + echo "* *" + echo "************************************************" + echo "" + rm -f $LSOF_HLP + exit 1 + fi # } + LSOF_CFGF="$LSOF_CFGF -DHPUXV=$LSOF_VERS" + LSOF_CINFO="/dev/kmem-based" + LSOF_DIALECT_DIR=hpux/kmem + echo "Configuring /dev/kmem-based HP-UX lsof" + if test $LSOF_VERS -lt 1000 # { + then + if test "X$HPUX_X25DIR" = "X" # { + then + HPUX_X25DIR="/etc/conf" + else + HPUX_X25DIR=$HPUX_X25DIR + fi # } + if test -r ${HPUX_X25DIR}/x25/x25addrstr.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHPUX_CCITT" + LSOF_DINC="$LSOF_DINC -I$HPUX_X25DIR" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/vx_inode.h -a -r ${LSOF_INCLUDE}/sys/fs/vx_hpux.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS" + fi # } + if test $LSOF_VERS -ge 1030 # { + then + if test "X$HPUX_KERNBITS" = "X" # { + then + HPUX_KERNBITS=`getconf _SC_KERNEL_BITS` + fi # } + LSOF_CFGF="$LSOF_CFGF -DHPUXKERNBITS=${HPUX_KERNBITS} -I`pwd`/dialects/hpux/kmem/hpux11" + if test $HPUX_KERNBITS -eq 64 # { + then + LSOF_TSTK64=1 + echo "" + echo "*****************************************" + echo "* *" + echo "* NOTICE! Configuring for 64 bit HP-UX *" + echo "* *" + echo "*****************************************" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Test gcc for 64 bit support, trying gcc with no options, then + # with -mlp64, testing the result with file. + + echo "" + echo "Testing $LSOF_CC for 64 bit support" + rm -f ${LSOF_TMPC}.* + echo "int main(){}" > ${LSOF_TMPC}.c + LSOF_TMP1="" + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + /bin/file ${LSOF_TMPC}.x | /bin/grep 64 > /dev/null + if test $? -eq 0 # { + then + LSOF_TMP1=" " + fi # } + fi # } + if test "X$LSOF_TMP1" = "X" # { + then + rm -f ${LSOF_TMPC}.x + $LSOF_CC ${LSOF_TMPC}.c -mlp64 -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + /bin/file ${LSOF_TMPC}.x | /bin/grep 64 > /dev/null + if test $? -eq 0 # { + then + LSOF_TMP1="-mlp64" + fi # } + fi # } + fi # } + rm -f ${LSOF_TMPC}.* + if test "X$LSOF_TMP1" = "X" # { + then + echo "" + echo "***************************************************" + echo "* *" + echo "* !!!!!!!!!!!!!!!!! FATAL ERROR !!!!!!!!!!!!!!!!! *" + echo "* *" + echo "* APPARENTLY GCC CANNOT BUILD 64 BIT EXECUTABLES. *" + echo "* A COMPILER MUST BE USED THAT CAN. SEE 00FAQ *" + echo "* FOR MORE INFORMATION. *" + echo "* *" + echo "***************************************************" + echo "" + rm -f $LSOF_HLP + exit 1 + else + if test "X$LSOF_TMP1" != "X " # { + then + LSOF_CFGF="$LSOF_CFGF $LSOF_TMP1" + fi # } + LSOF_CFGL="$LSOF_CFGL -lelf" + LSOF_CINFO="${LSOF_CINFO}, 64 bit HP-UX" + fi # } + else + + # Set options for the HP-UX compiler. + + LSOF_CFGF="$LSOF_CFGF +DD64" + LSOF_CFGL="$LSOF_CFGL -lelf" + LSOF_CINFO="${LSOF_CINFO}, 64 bit HP-UX" + fi # } + else + LSOF_CFGF="$LSOF_CFGF -D_FILE_OFFSET_BITS=64" + LSOF_CINFO="${LSOF_CINFO}, 32 bit HP-UX" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF +DAportable" + fi # } + fi # } + LSOF_CFGL="$LSOF_CFGL -lnsl" + else + + # When HP-UX is less than 10.30, but greater than or equal to 10, + # check NFS3 rnode status. + + if test $LSOF_VERS -ge 1000 # { + then + LSOF_TMP1=0 + if test "X$HPUX_RNODE3" = "X" # { + then + nm -x $HPUX_BOOTFILE | grep -q nfs_vnodeops3 + if test $? -eq 0 # { + then + if test -r ${LSOF_INCLUDE}/nfs/rnode.h # { + then + grep -q r_fh3 ${LSOF_INCLUDE}/nfs/rnode.h + if test $? -ne 0 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + else + if test "X$HPUX_RNODE3" = "X1" # { + then + LSOF_TMP1=1 + fi # } + fi # } + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASRNODE3" + fi # } + fi # } + fi # } + if test $LSOF_VERS -eq 1100 # { + then + + # Test for the ipis_s structure. If it is present, set HAS_IPC_S_PATCH. + + if test "X$HPUX_IPC_S_PATCH" = "X" # { + then + if test -x /usr/contrib/Q4/bin/q4exe # { + then + LSOF_TMP=/usr/contrib/Q4/bin/q4exe + else + LSOF_TMP=/usr/contrib/bin/q4 + fi # } + if test -x $LSOF_TMP # { + then + rm -f ${LSOF_TMPC}.out + echo "" + echo $EO "Looking in $HPUX_BOOTFILE for ipis_s with $LSOF_TMP ... $EC" + echo "yes\\nfields -c struct ipis_s" | $LSOF_TMP $HPUX_BOOTFILE > ${LSOF_TMPC}.out 2>&1 + if test $? -ne 0 # { + then + echo "" + echo "" + echo "!!!ERROR!!! $LSOF_TMP failed and produced the following output." + echo "" + cat ${LSOF_TMPC}.out + HPUX_IPC_S_PATCH=fail + else + grep ipis_s ${LSOF_TMPC}.out > /dev/null 2>&1 + if test $? -eq 0 # { + then + echo "ipis_s exists." + + # See if ipis_msgsqueued is present. + + grep ipis_msgsqueued ${LSOF_TMPC}.out > /dev/null 2>&1 + if test $? -eq 0 # { + then + HPUX_IPC_S_PATCH=2 + else + HPUX_IPC_S_PATCH=1 + fi # } + else + echo "ipis_s doesn't exist." + HPUX_IPC_S_PATCH=N + fi # } + fi # } + rm -f ${LSOF_TMPC}.out + else + echo "Can't locate or execute $LSOF_TMP" + echo $EO "ls says: $EC" + ls -ld $LSOF_TMP + HPUX_IPC_S_PATCH=fail + fi # } + fi # } + if test "X$HPUX_IPC_S_PATCH" = "Xfail" # { + then + echo "" + echo "!!!ERROR!!! !!!ERROR!!! !!!ERROR!!! !!!ERROR!!!" + echo "Configure can't use $LSOF_TMP to examine the ipis_s" + echo "structure. You must do that yourself, report the result in" + echo "the HPUX_IPC_S_PATCH environment variable, then repeat the" + echo "Configure step. Consult the Configure script's use of" + echo "$LSOF_TMP and the 00XCONFIG file for information" + echo "on ipis_s testing and the setting of HPUX_IPC_S_PATCH." + echo "!!!ERROR!!! !!!ERROR!!! !!!ERROR!!! !!!ERROR!!!" + echo "" + rm -f $LSOF_HLP + exit 1 + fi # } + if test "X$HPUX_IPC_S_PATCH" = "X1" -o "X$HPUX_IPC_S_PATCH" = "X2" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_IPC_S_PATCH=$HPUX_IPC_S_PATCH" + else + if test "X$HPUX_IPC_S_PATCH" != "Xn" -a "X$HPUX_IPC_S_PATCH" != "XN" # { + then + echo "Illegal value for HPUX_IPC_S_PATCH: $HPUX_IPC_S_PATCH" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + fi #} + + # Manufacture an hpux_mount.h header file with a mount struct in it, as + # required. + + if test -r ${LSOF_INCLUDE}/sys/mount.h # { + then + LSOF_TMP1="dialects/${LSOF_DIALECT_DIR}/hpux_mount.h" + rm -f $LSOF_TMP1 + echo "#if !defined(MANUFACTURED_HPUX_SYS_MOUNT_H)" > $LSOF_TMP1 + echo "#define MANUFACTURED_HPUX_SYS_MOUNT_H" >> $LSOF_TMP1 + echo "/* By lsof Configure:" `date` " */" >> $LSOF_TMP1 + echo "struct mount" >> $LSOF_TMP1 + sed '1,/struct mount/d' ${LSOF_INCLUDE}/sys/mount.h | sed -n '1,/m_dev/p' >> $LSOF_TMP1 + echo "};" >> $LSOF_TMP1 + echo "#endif" >> $LSOF_TMP1 + LSOF_CFGF="$LSOF_CFGF -I`pwd`/dialects/${LSOF_DIALECT_DIR}" + fi # } + + # Test for OnlineJFS. + + if test $LSOF_VERS -ge 1100 # { + then + if test "X$HPUX_HASONLINEJFS" = "X" -a -x /sbin/fs/vxfs/subtype # { + then + LSOF_TMP1=`/sbin/fs/vxfs/subtype` + if test "X$LSOF_TMP1" = "Xvxfs3.3" + then + HPUX_HASONLINEJFS="Y" + fi # } + fi # } + if test "X$HPUX_HASONLINEJFS" = "XY" -o "X$HPUX_HASONLINEJFS" = "Xy" + # { + then + LSOF_CFGF="$LSOF_CFGF -DHASONLINEJFS" + fi # } + fi # } + + # Test for AFS. + + if test -r ${AFS_VICE}/etc/ThisCell # { + then + if test "X$LSOF_SCRIPT_CALL" = "Xno" # { + then + if test -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + else + if test ! -x ./AFSConfig # { + then + echo "Can't find or execute the AFSConfig script" + rm -f $LSOF_HLP + exit 1 + fi # } + ./AFSConfig + if test $? -eq 0 -a -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + fi # } + if test "X$LSOF_AFS" = "Xyes" # { + then + LSOF_AFSV=`cat ./AFSVersion | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1 \2/' | awk '{printf "%d%02d\n",\$1,\$2}'` + LSOF_CFGF="$LSOF_CFGF -DHAS_AFS=$LSOF_AFSV" + LSOF_DINC="$LSOF_DINC -I`cat ./AFSHeaders`" + fi # } + fi # } + else + echo "HP-UX base unrecognized: $HPUX_BASE" + rm -f $LSOF_HLP + exit 1 + fi # } + fi # } + ;; + +# Configure for Linux. + + linux) + LSOF_TSTBIGF="-D_FILE_OFFSET_BITS=64" + LSOF_TSTKMEM=0 + if test "X$LSOF_CC" = "X" # { + then + LSOF_CC=cc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + if test "X$LINUX_CONF_CC" = "X" # { + then + LINUX_CONF_CC=$LSOF_CC + fi #} + LSOF_DIALECT_DIR="" + if test "X$LINUX_INCL" = "X" # { + then + LINUX_INCL=/usr/include + else + LSOF_DINC="$LSOF_DINC -I${LINUX_INCL}" + fi # } + if test "X$LINUX_VERSION_CODE" = "X" # { + then + if test -r "$LINUX_INCL/linux/version.h" # { + then + LINUX_VERSION_CODE=`cat $LINUX_INCL/linux/version.h | sed -n 's/.\+LINUX_VERSION_CODE \([[:digit:]]\+\)$/\1/p'` + fi # } + fi # } + LSOF_VSTR=`echo $LINUX_VERSION_CODE | perl -e '$version=; chomp($version); printf("%d.%d.%d\n", ($version >> 16) & 0xFF, ($version >> 8) & 0xFF, $version & 0xFF);'` + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the Linux version isn't predefined, determine it. + + LSOF_VERS=`echo $LSOF_VSTR | sed 's/\./ /g' | awk '{printf "%d%d%03d",\$1,\$2,\$3}'` + fi # } + LSOF_CFGF="$LSOF_CFGF -DLINUXV=$LSOF_VERS" + if test $LSOF_VERS -lt 21072 # { + then + echo "" + echo "!!!WARNING!!!==!!!WARNING!!!==!!!WARNING!!!==!!!WARNING!!!" + echo "! !" + echo "! THE /PROC-BASED LSOF SOURCES HAVE NOT BEEN TESTED ON !" + echo "! LINUX KERNELS BELOW 2.1.72, AND MAY NOT WORK ON THIS !" + echo "! KERNEL. IT SHOULD USE A /DEV/KMEM-BASED LSOF. !" + echo "! !" + echo "!!!WARNING!!!==!!!WARNING!!!==!!!WARNING!!!==!!!WARNING!!!" + echo "" + else + LSOF_UNSUP="" + fi # } + + # If the Linux C library type isn't predefined, determine it. + + if test "X$LINUX_CLIB" = "X" # { + then + echo -n "Testing C library type with $LINUX_CONF_CC ... " + rm -f ${LSOF_TMPC}.* + cat > $LSOF_TMPC.c << .LSOF_END_HERE_DOC1 +#include +#include +int main() { +#if defined(__GLIBC__) && defined(__GLIBC_MINOR__) +printf("-DGLIBCV=%d\n",__GLIBC__*100+__GLIBC_MINOR__); +#elif defined(__GLIBC__) +printf("-DGLIBCV=%d00\n",__GLIBC__); +#else +printf("\n"); +#endif +return(0); } +.LSOF_END_HERE_DOC1 + $LINUX_CONF_CC ${LSOF_TMPC}.c -I$LSOF_INCLUDE -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test -x ${LSOF_TMPC}.x # { + then + LINUX_CLIB=`${LSOF_TMPC}.x` + LSOF_TMP=$? + else + LINUX_CLIB="" + LSOF_TMP=1 + fi # } + rm -f ${LSOF_TMPC}.* + echo "done" + if test $LSOF_TMP -ne 0 # { + then + echo "Cannot determine C library type; assuming it is not glibc." + LINUX_CLIB="" + else + if test "X$LINUX_CLIB" = "X" # { + then + echo "The C library type is not glibc." + else + echo "The C library type is glibc, version \"$LINUX_CLIB\"." + fi # } + fi # } + fi # } + if test "X$LINUX_CLIB" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF $LINUX_CLIB" + fi # } + + # Test for IPv6 support. + + if test -r ${LSOF_INCLUDE}/netinet/ip6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + + # Test for . + + if test -r ${LSOF_INCLUDE}/rpc/rpc.h # { + then + : # Do nothing + elif test -r ${LSOF_INCLUDE}/tirpc/rpc/rpc.h + then + LSOF_DINC="${LSOF_DINC} -I${LSOF_INCLUDE}/tirpc" + LSOF_CFGL="${LSOF_CFGL} -ltirpc" + else + LSOF_CFGF="$LSOF_CFGF -DHASNORPC_H" + fi # } + + # Test for TCP_* symbols. + + if test -r ${LSOF_INCLUDE}/netinet/tcp.h # ( + then + grep -q TCP_ESTABLISHED ${LSOF_INCLUDE}/netinet/tcp.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DNEEDS_NETINET_TCPH" + fi #} + fi # } + + # Test for SELinux support. + + LSOF_TMP1=0 + if test "X$LINUX_HASSELINUX" = "X" # { + then + if test -r ${LSOF_INCLUDE}/selinux/selinux.h # { + then + LSOF_TMP1=1 + fi # } + else + if test "X$LINUX_HASSELINUX" = "XY" -o "X$LINUX_HASSELINUX" = "Xy" # { + then + LSOF_TMP1=1 + fi # } + fi # } + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSELINUX" + LSOF_CFGL="$LSOF_CFGL -lselinux" + fi # } + + # Test for UNIX socket endpoint support. + + if test -r ${LSOF_INCLUDE}/linux/sock_diag.h -a -r ${LSOF_INCLUDE}/linux/unix_diag.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASUXSOCKEPT" + fi # } + + # Test for pseudoterminal endpoint support. + + if test -r ${LSOF_INCLUDE}/linux/major.h # { + then + grep -q TTYAUX_MAJOR ${LSOF_INCLUDE}/linux/major.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPTYEPT" + fi # } + fi # } + + # Test for (unix) socket state support. + + if test -f ${LSOF_INCLUDE}/linux/net.h # { + then + grep -q SS_CONNECTED ${LSOF_INCLUDE}/linux/net.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSOSTATE -DHASSOOPT" + fi # } + fi # } + + # Test for dup2 and closefrom + + if test -f ${LSOF_INCLUDE}/unistd.h # { + then + grep -q dup2 ${LSOF_INCLUDE}/unistd.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_DUP2" + fi # } + + grep -q closefrom ${LSOF_INCLUDE}/unistd.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CLOSEFROM" + fi # } + fi # } + + LSOF_DIALECT_DIR="linux" + LSOF_CFGF="$LSOF_CFGF -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE" + ;; + +# Configure for NetBSD. + + netbsd) + if test "X$LSOF_CC" = "X" # { + then + LSOF_CC=cc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # Validate the NetBSD version. + + case $LSOF_VSTR in # { + 1.2*) + LSOF_VERS="1002000" + ;; + 1.3*) + LSOF_VERS="1003000" + ;; + 1.4*) + LSOF_VERS="1004000" + ;; + 1.5*) + LSOF_TSTBIGF=" " + LSOF_VERS="1005000" + ;; + 1.6*) + LSOF_TSTBIGF=" " + LSOF_VERS="1006000" + ;; + 1.*) + LSOF_VERS="1006000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 1.6" + ;; + 2.0*) + LSOF_TSTBIGF=" " + LSOF_VERS="2000000" + ;; + 2.99.9) + LSOF_TSTBIGF=" " + LSOF_VERS="2099009" + ;; + 2.99.10) + LSOF_TSTBIGF=" " + LSOF_VERS="2099010" + ;; + 2.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="2099010" + ;; + 2.*) + LSOF_VERS="2000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 2.0" + ;; + 3.0*) + LSOF_TSTBIGF=" " + LSOF_VERS="3000000" + ;; + 3.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="3099000" + ;; + 3.*) + LSOF_VERS="3000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 3.0" + ;; + 4.0*) + LSOF_TSTBIGF=" " + LSOF_VERS="4000000" + ;; + 4.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="4099000" + ;; + 4.*) + LSOF_VERS="4000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 4.0" + ;; + 5.[012]*) + LSOF_TSTBIGF=" " + LSOF_VERS="5000000" + ;; + 5.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="5099000" + ;; + 5.*) + LSOF_VERS="5000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 5.0" + ;; + 6.[01]*) + LSOF_TSTBIGF=" " + LSOF_VERS="6000000" + ;; + 6.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="6099000" + ;; + 6.*) + LSOF_VERS="6000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 6.0" + ;; + 7.[01]*) + LSOF_TSTBIGF=" " + LSOF_VERS="7000000" + ;; + 7.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="7099000" + ;; + 7.*) + LSOF_VERS="7000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 7.0" + ;; + 8.[0123]*) + LSOF_TSTBIGF=" " + LSOF_VERS="8000000" + ;; + 8.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="8099000" + ;; + 8.*) + LSOF_VERS="8000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 8.0" + ;; + 9.[0123]*) + LSOF_TSTBIGF=" " + LSOF_VERS="9000000" + ;; + 9.99.10[45678]) + LSOF_TSTBIGF=" " + LSOF_VERS="9099104" + ;; + 9.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="9099000" + ;; + 9.*) + LSOF_VERS="9000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 9.0" + ;; + 10.99.*) + LSOF_TSTBIGF=" " + LSOF_VERS="10099000" + ;; + 10.*) + LSOF_VERS="10000000" + echo "!!!WARNING!!! Unsupported NetBSD version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for NetBSD 10.0" + ;; + *) + echo "Unknown NetBSD release: $LSOF_VSTR" + echo Assuming NetBSD 10.0 + LSOF_VERS="10000000" + ;; + esac # } + fi # } + + LSOF_CFGF="$LSOF_CFGF -DNETBSDV=$LSOF_VERS" + + # For paddr_t + LSOF_CFGF="$LSOF_CFGF -D_KMEMUSER" + # For struct namecache + LSOF_CFGF="$LSOF_CFGF -D__NAMECACHE_PRIVATE" + + LSOF_TMP1="-DN_UNIXV=/netbsd" + if test -r /dev/ksyms # { + then + LSOF_TMP1="-DN_UNIXV=/dev/ksyms" + elif test -r ${LSOF_INCLUDE}/util.h # { + then + grep -q getbootfile ${LSOF_INCLUDE}/util.h + if test $? -eq 0 # { + then + LSOF_CFGL="$LSOF_CFGL -lutil" + LSOF_TMP1="-DHASGETBOOTFILE" + fi # } + fi # } + LSOF_CFGF="$LSOF_CFGF $LSOF_TMP1" + if test -r ${LSOF_INCLUDE}/kvm.h # { + then + grep -q kvm_getproc2 ${LSOF_INCLUDE}/kvm.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASKVMGETPROC2" + fi # } + fi # } + + # Here begin the dual tests on header files that may be in $LSOF_INCLUDE + # or $NETBSD_SYS. + # + # Note that $LSOF_TMP1 holds an indicator of the need for -I$NETBSD_SYS. + # LSOF_TMP4 contains a temporary indicator of the use of $NETBSD_SYS. + + LSOF_TMP1=0 + if test "X$NETBSD_SYS" = "X" # { + then + if test -d /usr/src # { + then + NETBSD_SYS="/usr/src/sys" + else + NETBSD_SYS=$LSOF_INCLUDE + fi # } + fi # } + LSOF_TMP2="nfs/nfsproto.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNFSPROTO" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + LSOF_TMP2="netinet/ip6.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + else + LSOF_TMP2="netinet/in.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q IPV6_INRIA_VERSION $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6 -DHASINRIAIPv6" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + fi # } + LSOF_TMP2="miscfs/fdesc/fdesc.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q Fctty $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASFDESCFS=1" + else + LSOF_CFGF="$LSOF_CFGF -DHASFDESCFS=2" + fi # } + grep -q fd_link $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASFDLINK" + fi # } + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + LSOF_TMP2="miscfs/nullfs/null.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNULLFS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + LSOF_TMP2="miscfs/procfs" + if test -d ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -d ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPROCFS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + if test -r ${LSOF_TMP3}/procfs.h # { + then + grep -q PFSroot ${LSOF_TMP3}/procfs.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPROCFS_PFSROOT" + fi # } + fi # } + fi # } + LSOF_TMP2="sys/bufq.h" + LSOF_NBSD_BUFQH=0 + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASBUFQ_H" + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + if test $NETBSD_SYS != $LSOF_INCLUDE # { + then + LSOF_CFGF="$LSOF_CFGF -DHASBUFQ_H" + LSOF_NBSD_BUFQH=1 + fi # } + fi # } + fi # } + LSOF_TMP2="isofs/cd9660" + if test -d ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -d ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS9660FS=1" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + else + LSOF_TMP2="fs/cd9660" + if test -d ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -d ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS9660FS=1" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="msdosfs" + if test -d ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -d ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASMSDOSFS=1" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + else + LSOF_TMP2="fs/msdosfs" + if test -d ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -d ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASMSDOSFS=2" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="miscfs/kernfs/kernfs.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q "kt_name;" $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASKERNFS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + grep -q "*kfs_kt;" $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASKERNFS_KFS_KT" + fi # } + fi # } + fi # } + LSOF_TMP2="sys/namei.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q nc_vpid $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNCVPID" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="ufs/ufs/inode.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q i_ffs_size $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASI_FFS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + else + grep -q i_ffs1_size $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASI_FFS1" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + grep -q i_ffs_effnlink $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASEFFNLINK=i_ffs_effnlink" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="sys/vnode.h" + LSOF_NBSD_PTYFS=0 + LSOF_NBSD_TMPFS=0 + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "XLSOF_TMP3" != "X" # { + then + grep -q VT_EXT2FS $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASEXT2FS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + LSOF_TMP2="ufs/ufs/inode.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP5="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP6=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP5="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP6=1 + else + LSOF_TMP5="" + fi # } + fi # } + if test "X$LSOF_TMP5" != "X" # { + then + grep -q "*e2fs_din" $LSOF_TMP5 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASI_E2FS_PTR" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=$LSOF_TMP6 + fi # } + fi # } + fi # } + fi # } + grep -q VT_LFS $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASLFS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + grep -q VT_PTYFS $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_TMP2="fs/ptyfs/ptyfs.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPTYFS" + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + if test $NETBSD_SYS != $LSOF_INCLUDE # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPTYFS" + LSOF_NBSD_PTYFS=1 + fi # } + fi # } + fi # } + fi # } + grep -q VT_TMPFS $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_TMP2="fs/tmpfs/tmpfs.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASTMPFS" + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + if test $NETBSD_SYS != $LSOF_INCLUDE # { + then + LSOF_CFGF="$LSOF_CFGF -DHASTMPFS" + LSOF_NBSD_TMPFS=1 + fi # } + fi # } + fi # } + fi # } + if test "X$NETBSD_UVM" = "X" # { + then + if test -r ${LSOF_INCLUDE}/uvm # { + then + NETBSD_UVM="Y" + fi # } + fi # } + fi # } + LSOF_TMP2="nfs/nfsnode.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q "*n_vattr" $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASNFSVATTRP" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="sys/lockf.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q vop_advlock_args $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_ADVLOCK_ARGS" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + grep -q lf_lwp $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_LF_LWP" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="sys/lwp.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_LWP_H" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + LSOF_TMP2="sys/filedesc.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + grep -q "^struct cwdinfo {" $LSOF_TMP3 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASCWDINFO" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + fi # } + LSOF_TMP2="sys/pipe.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + LSOF_TMP4=0 + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + LSOF_TMP4=1 + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SYS_PIPEH" + if test $LSOF_TMP1 -eq 0 -a $LSOF_TMP4 -eq 1 # { + then + LSOF_TMP1=1 + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/statvfs.h # { + then + grep -q '^struct statvfs {' ${LSOF_INCLUDE}/sys/statvfs.h + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSTATVFS" + fi # } + fi # } + + # Here end the dual NetBSD tests for header files in $LSOF_INCLUDE or + # NETBSD_SYS. + # + # After this LSOF_TMP1 may be reused. + + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_DINC="-I$LSOF_INCLUDE -I$NETBSD_SYS" + fi # } + + # Build special header files, as required. + + rm -rf lib/dialects/netbsd/include + if test "X$NETBSD_UVM" = "XY" -o "X$NETBSD_UVM" = "Xy" # { + then + mkdir lib/dialects/netbsd/include + touch lib/dialects/netbsd/include/opt_uvmhist.h + touch lib/dialects/netbsd/include/opt_lockdebug.h + LSOF_CFGF="$LSOF_CFGF -DUVM -I`pwd`/lib/dialects/netbsd/include" + if test -d ${LSOF_INCLUDE}/uvm # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_UVM_INCL" + fi # } + fi # } + LSOF_TMP2="sys/mount.h" + if test -r ${LSOF_INCLUDE}/$LSOF_TMP2 # { + then + LSOF_TMP3="${LSOF_INCLUDE}/$LSOF_TMP2" + else + if test -r ${NETBSD_SYS}/$LSOF_TMP2 # { + then + LSOF_TMP3="${NETBSD_SYS}/$LSOF_TMP2" + else + LSOF_TMP3="" + fi # } + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + + # Build a local NetBSD netexport.h header file for possible use by + # . Make sure CFGL contains a -I for it. + + LSOF_TMP1=${LSOF_TMPC}.edscr + LSOF_TMP2=${LSOF_TMPC}.netcred + LSOF_TMP3=${LSOF_TMPC}.netexport + LSOF_TMP4=lib/dialects/netbsd/include/netexport.h + if test ! -d lib/dialects/netbsd/include # { + then + mkdir lib/dialects/netbsd/include + fi # } + rm -f $LSOF_TMP1 $LSOF_TMP2 $LSOF_TMP3 $LSOF_TMP4 + echo "/^struct netcred" > $LSOF_TMP1 + echo "1,.-1d" >> $LSOF_TMP1 + echo "/^};" >> $LSOF_TMP1 + echo "1,.w $LSOF_TMP2" >> $LSOF_TMP1 + ed ${LSOF_INCLUDE}/sys/mount.h < $LSOF_TMP1 > /dev/null 2>&1 + rm -f $LSOF_TMP1 + echo "/^struct netexport" > $LSOF_TMP1 + echo "1,.-1d" >> $LSOF_TMP1 + echo "/^};" >> $LSOF_TMP1 + echo "1,.w $LSOF_TMP3" >> $LSOF_TMP1 + ed ${LSOF_INCLUDE}/sys/mount.h < $LSOF_TMP1 > /dev/null 2>&1 + echo "/*" > $LSOF_TMP4 + echo " * netexport.h" >> $LSOF_TMP4 + echo -n " * Created by Configure: " >> $LSOF_TMP4 + echo `date` >> $LSOF_TMP4 + echo " */" >> $LSOF_TMP4 + echo "" >> $LSOF_TMP4 + echo "#if !defined(NETEXPORT_H)" >> $LSOF_TMP4 + echo "#define NETEXPORT_H" >> $LSOF_TMP4 + echo "" >> $LSOF_TMP4 + echo "#include " >> $LSOF_TMP4 + echo "" >> $LSOF_TMP4 + if test -r $LSOF_TMP2 # { + then + cat $LSOF_TMP2 >> $LSOF_TMP4 + echo "" >> $LSOF_TMP4 + fi # } + if test -r $LSOF_TMP3 # { + then + cat $LSOF_TMP3 >> $LSOF_TMP4 + fi # } + echo "#endif /* !defined(NETEXPORT_H) */" >> $LSOF_TMP4 + rm -f $LSOF_TMP1 $LSOF_TMP2 $LSOF_TMP3 + echo $LSOF_CFGF | grep /lib/dialects/netbsd/include > /dev/null 2>&1 + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -I`pwd`/lib/dialects/netbsd/include" + fi # } + fi # } + if test $LSOF_NBSD_BUFQH -eq 1 # { + then + + # Make a local copy of $NETBSD_SYS/sys/bufq.h. + + if test ! -d lib/dialects/netbsd/include # { + then + mkdir lib/dialects/netbsd/include + fi # } + if test ! -d lib/dialects/netbsd/include/sys # { + then + mkdir lib/dialects/netbsd/include/sys + fi # } + cp $NETBSD_SYS/sys/bufq.h lib/dialects/netbsd/include/sys + echo $LSOF_CFGF | grep lib/dialects/netbsd/include > /dev/null 2>&1 + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -I`pwd`lib/dialects/netbsd/include" + fi # } + fi # } + if test $LSOF_NBSD_PTYFS -eq 1 # { + then + + # Make a local copy of $NETBSD_SYS/sys/fs/ptyfs/. + + if test ! -d lib/dialects/netbsd/include # { + then + mkdir lib/dialects/netbsd/include + fi # } + if test ! -d lib/dialects/netbsd/include/fs # { + then + mkdir lib/dialects/netbsd/include/fs + fi # } + rm -rf lib/dialects/netbsd/include/fs/ptyfs + mkdir lib/dialects/netbsd/include/fs/ptyfs + cp $NETBSD_SYS/fs/ptyfs/*.h lib/dialects/netbsd/include/fs/ptyfs + echo $LSOF_CFGF | grep lib/dialects/netbsd/include > /dev/null 2>&1 + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -I`pwd`/lib/dialects/netbsd/include" + fi # } + fi # } + if test $LSOF_NBSD_TMPFS -eq 1 # { + then + + # Make a local copy of $NETBSD_SYS/sys/fs/tmpfs/tmpfs.h. + + if test ! -d lib/dialects/netbsd/include # { + then + mkdir lib/dialects/netbsd/include + fi # } + if test ! -d lib/dialects/netbsd/include/fs # { + then + mkdir lib/dialects/netbsd/include/fs + fi # } + rm -rf lib/dialects/netbsd/include/fs/tmpfs + mkdir lib/dialects/netbsd/include/fs/tmpfs + cp $NETBSD_SYS/fs/tmpfs/tmpfs.h lib/dialects/netbsd/include/fs/tmpfs + echo $LSOF_CFGF | grep lib/dialects/netbsd/include > /dev/null 2>&1 + if test $? -ne 0 # { + then + LSOF_CFGF="$LSOF_CFGF -I`pwd`lib/dialects/netbsd/include" + fi # } + fi # } + + # Generate lockf.h from kern/vfs_lockf.c + rm -f ./lockf.h + if test -r ${NETBSD_SYS}/kern/vfs_lockf.c # { + then + # Find the line number of TAILQ_HEAD + LSOF_TMP1=`grep -n "^TAILQ_HEAD" ${NETBSD_SYS}/kern/vfs_lockf.c | sed 's/\([0-9]*\):.*$/\1/'` + if test "X$LSOF_TMP1" != "X" # { + then + LSOF_TMP2=0 + # Find the end of struct lockf + for i in `grep -n "};" ${NETBSD_SYS}/kern/vfs_lockf.c | sed 's/\([0-9]*\):.*/\1/'` # { + do + if test $LSOF_TMP2 -eq 0 -a $i -gt $LSOF_TMP1 # { + then + LSOF_TMP2=$i + fi # } + done # } + if test $LSOF_TMP2 -eq 0 # { + then + LSOF_TMP1="" + else + cat > ./lockf.h << LOCKF1 +/* +* lockf_owner.h -- created by lsof configure script on +LOCKF1 + printf " * " >> ./lockf.h + date >> ./lockf.h + cat >> ./lockf.h << LOCKF2 +*/ + +#if !defined(LOCKF_H) +#define LOCKF_H + +LOCKF2 + ed -s ${NETBSD_SYS}/kern/vfs_lockf.c >> ./lockf.h << LOCKF3 +${LSOF_TMP1},${LSOF_TMP2}p +LOCKF3 + if test $? -ne 0 # { + then + LSOF_TMP1="" + else + cat >> ./lockf.h << LOCKF4 + +#endif /* defined(LOCKF_H) */ +LOCKF4 + fi # } + fi # } + fi # } + else + echo "FATAL ERROR: can't read ${NETBSD_SYS}/kern/vfs_lockf.c" + fi # } + + if test "X$LSOF_TMP1" != "X" -a "X$LSOF_TMP2" != "X0" # { + then + echo "lockf.h creation succeeded." + LSOF_CFGF="$LSOF_CFGF -DHAS_LOCKF_H" + else + echo "lockf.h creation failed (see 00FAQ)" + fi # } + + LSOF_CFGL="$LSOF_CFGL -lkvm" + LSOF_DIALECT_DIR=netbsd + ;; + +# Configure for OpenBSD. (OpenBSD uses NetBSD dialect sources and version +# numbering. + + openbsd) + LSOF_TSTKMEM=0 + if test "X$LSOF_CC" = "X" # { + then + LSOF_CC=cc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the OpenBSD version isn't pre-defined, determine it. + + case $LSOF_VSTR in # { + 1*) + LSOF_VERS=1020 + echo "!!!WARNING!!! Unsupported OpenBSD 1.x version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for OpenBSD 1.2" + ;; + 2.5*) + LSOF_VERS=2050 + ;; + 2.6*) + LSOF_VERS=2060 + ;; + 2.7*) + LSOF_TSTBIGF=" " + LSOF_VERS=2070 + ;; + 2.8*) + LSOF_TSTBIGF=" " + LSOF_VERS=2080 + ;; + 2.9*) + LSOF_TSTBIGF=" " + LSOF_VERS=2090 + ;; + 2*) + LSOF_TSTBIGF=" " + LSOF_VERS=2090 + echo "!!!WARNING!!! Unsupported OpenBSD 2.x version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for OpenBSD 2.9" + ;; + 3.0*) + LSOF_TSTBIGF=" " + LSOF_VERS=3000 + ;; + 3.1*) + LSOF_TSTBIGF=" " + LSOF_VERS=3010 + ;; + 3.2*) + LSOF_TSTBIGF=" " + LSOF_VERS=3020 + ;; + 3.3*) + LSOF_TSTBIGF=" " + LSOF_VERS=3030 + ;; + 3.4*) + LSOF_TSTBIGF=" " + LSOF_VERS=3040 + ;; + 3.5*) + LSOF_TSTBIGF=" " + LSOF_VERS=3050 + ;; + 3.6*) + LSOF_TSTBIGF=" " + LSOF_VERS=3060 + ;; + 3.7*) + LSOF_TSTBIGF=" " + LSOF_VERS=3070 + ;; + 3.8*) + LSOF_TSTBIGF=" " + LSOF_VERS=3080 + ;; + 3.9*) + LSOF_TSTBIGF=" " + LSOF_VERS=3090 + ;; + 3*) + LSOF_TSTBIGF=" " + LSOF_VERS=3090 + echo "!!!WARNING!!! Unsupported OpenBSD 3.x version: $LSOF_VSTR" + echo "!!!WARNING!!! Configuring for OpenBSD 3.9" + ;; + 7.2*) + LSOF_TSTBIGF=" " + LSOF_VERS=7020 + ;; + 7.3*) + LSOF_TSTBIGF=" " + LSOF_VERS=7030 + ;; + *) + echo "Unknown OpenBSD release: $LSOF_VSTR" + echo Assuming OpenBSD 3.9 + LSOF_VERS=3090 + ;; + esac # } + fi # } + + # Test for legal OpenBSD version. + + case $LSOF_VERS in # { + 1020|2050|2060|2070|2080|2090|3000|3010|3020|3030|3040|3050|3060|3070|3080|3090|7020|7030) + ;; + *) + echo "Unknown OpenBSD version: $LSOF_VERS" + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + + LSOF_CFGF="$LSOF_CFGF -DOPENBSDV=$LSOF_VERS" + + if test -r ${LSOF_INCLUDE}/netinet6/in6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + + if test "X$OPENBSD_SYS" = "X" # { + then + OPENBSD_SYS="/sys" + fi # } + + if test -d ${OPENBSD_SYS}/miscfs/procfs # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPROCFS" + fi # } + + if test -r ${LSOF_INCLUDE}/sys/pipe.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SYS_PIPEH" + fi # } + + LSOF_DIALECT_DIR=openbsd + ;; + +# Configure for SCO OpenServer. + + osr|osrgcc|sco|scogcc) + if test "X$LSOF_RANLIB_SUP" = "X" # { + then + LSOF_RANLIB="" + fi # } + if test "X$OSR_CFGF" != "X" # { + then + + # Adopt LSOF_CFGF from OSR_CFGF in environment. + + LSOF_CFGF=$OSR_CFGF + fi # } + if test "X$OSR_CFGL" != "X" # { + then + + # Adopt LSOF_CFGL from OSR_CFGL in environment. + + LSOF_CFGL=$OSR_CFGL + fi # } + + # Evaluate compiler specification. + + if test "X$LSOF_CC" = "X" # { + then + if test "X$LSOF_TGT" = "Xosr" -o "X$LSOF_TGT" = "Xsco" # { + then + LSOF_CC=cc + LSOF_TMP1=1 + else + LSOF_CC=gcc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + LSOF_TMP1=2 + fi # } + else + LSOF_TMP1=0 + fi # } + LSOF_TGT="osr" + + # Determine version. + + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR="`LANG=C_C.C /bin/uname -X 2>/dev/null | grep Release | sed 's/Release = \(.*\)/\1/'`" + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the SCO OpenServer release version isn't predefined, determine it. + + case $LSOF_VSTR in # { + 3.2v2.0) + LSOF_VERS="20" + ;; + 3.2v2.1) + LSOF_VERS="21" + ;; + 3.2v4.0) + LSOF_VERS="40" + ;; + 3.2v4.1) + LSOF_VERS="41" + ;; + 3.2v4.2) + LSOF_VERS="42" + ;; + 3.2v5.*) + LSOF_TSTLFLG="-lsocket" + LSOF_VERS="`echo $LSOF_VSTR | sed 's/3\.2v//; s/\.//g'`" + ;; + *) + echo Unknown SCO OpenServer release: $LSOF_VSTR + echo Assuming 3.2.0 or 3.2.1 + LSOF_VERS="0" + ;; + esac # } + fi # } + + # Do SCO OpenServer specific stuff. + + case $LSOF_VERS in # { + 0) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -nointl" + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + LSOF_MKC="cp" + ;; + 20) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + LSOF_MKC="cp" + ;; + 21) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -nointl" + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + LSOF_MKC="cp" + ;; + 40) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -nointl" + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + ;; + 41) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -nointl" + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + ;; + 42) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -nointl" + LSOF_DEBUG="-Ox" + fi # } + LSOF_CFGL="$LSOF_CFGL -lrpc -lsocket -lc_s" + ;; + 5*) + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -belf" + LSOF_DEBUG="-O3 -Kspace" + fi # } + LSOF_CFGL="$LSOF_CFGL -lsocket" + ;; + *) + echo "Unsupported SCO OpenServer release: $LSOF_VERS" + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + LSOF_CFGF="$LSOF_CFGF -DOSRV=$LSOF_VERS" + if test "X$OSR_STATLSTAT" = "X" # { + then + echo "Testing libc.a for statlstat" + /bin/nm /lib/libc.a | grep statlstat > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_STATLSTAT" + fi # } + else + if test "X$OSR_STATLSTAT" = "XY" -o "X$OSR_STATLSTAT" = "Xy" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_STATLSTAT" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/nfs/rnode.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_NFS" + fi # } + if test ! -r ${LSOF_INCLUDE}/netdb.h # { + then + LSOF_DINC="$LSOF_DINC -I`pwd`/dialects/osr/include" + fi # } + LSOF_DIALECT_DIR=osr + ;; + +# Configure for Sun Solaris, SunPro C and gcc. + + solaris|solariscc) + if test "X$LSOF_RANLIB_SUP" = "X" # { + then + LSOF_RANLIB="" + fi # } + if test "X$LSOF_CC" = "X" # { + then + if test "X$LSOF_TGT" = "Xsolariscc" # { + then + if test "X$SOLARIS_CCDIR" = "X" # { + then + SOLARIS_CCDIR="/opt/SUNWspro/bin" + fi # } + if test -x ${SOLARIS_CCDIR}/cc # { + then + LSOF_CC=${SOLARIS_CCDIR}/cc + else + if test -x /opt/SunStudioExpress/bin/cc # { + then + LSOF_CC=/opt/SunStudioExpress/bin/cc + else + echo "WARNING: no cc in ${SOLARIS_CCDIR}; using cc without path." + LSOF_CC=cc + fi # } + fi # } + LSOF_CCV=`$LSOF_CC -V 2>&1 | sed -n 's/^cc: \(.*\)/\1/p'` + else + LSOF_CC=gcc + LSOF_CCV=`$LSOF_CC -v 2>&1 | sed -n 's/.*version \(.*\)/\1/p'` + fi # } + fi # } + LSOF_TGT="solaris" + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -r` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the Solaris version isn't predefined, determine it. + + case $LSOF_VSTR in # { + 5.[0-2]) + LSOF_VERS="20300" + ;; + 5.3) + LSOF_VERS="20300" + ;; + 5.4) + LSOF_VERS="20400" + ;; + 5.5) + LSOF_VERS="20500" + ;; + 5.5.1) + LSOF_VERS="20501" + ;; + 5.6*) + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="20600" + ;; + 5.7*) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="70000" + ;; + 5.8*) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="80000" + ;; + 5.9*) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="90000" + ;; + 5.10*) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="100000" + ;; + 5.11*) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + LSOF_VERS="110000" + ;; + *) + echo Unknown Solaris version: $LSOF_VSTR + rm -f $LSOF_HLP + exit 1 + esac # } + fi # } + + # Clear LSOF_UNSUP message for selected Solaris versions. + + case $LSOF_VERS in # { + 90000|100000|110000) + LSOF_UNSUP="" + ;; + esac # } + + # Do Solaris version-specific stuff. + + case $LSOF_VERS in # { + 20300) + + # Solaris patch 101318-32 creates a longer kernel tcp_s structure, + # and 101318-45 changes the way the vnode's v_filocks member is + # handled. The following code creates a symbol definition for + # patch 101318 whose value is the patch level. No symbol is defined + # if the patch level is not greater than zero. + + if test "X$SOLARIS_23P101318" = "X" # { + then + LSOF_PL=`grep -h SUNW_PATCHID=101318 /var/sadm/pkg/SUNWcar*/pkginfo | sed 's/.*-//' | sort -u | tail -1` + if test "X$LSOF_PL" = "X" # { + then + LSOF_PL=0 + fi # } + else + LSOF_PL=$SOLARIS_23P101318 + fi # } + if test $LSOF_PL -gt 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DP101318=$LSOF_PL" + fi # } + ;; + 20400) + if test "X$SOLARIS_24P101945" = "X" # { + then + LSOF_PL=`grep -h SUNW_PATCHID=101945 /var/sadm/pkg/SUNWcar*/pkginfo | sed 's/.*-//' | sort -u | tail -1` + if test "X$LSOF_PL" = "X" # { + then + LSOF_PL=0 + fi # } + else + LSOF_PL=$SOLARIS_24P101945 + fi # } + if test $LSOF_PL -ge 32 # { + then + if test "X$SOLARIS_24P102303" = "X" # { + then + LSOF_PL=`grep -h SUNW_PATCHID=102303 /var/sadm/pkg/SUNWhea*/pkginfo | sed 's/.*-//' | sort -u | tail -1` + if test "X$LSOF_PL" = "X" # { + then + LSOF_PL=0 + fi # } + else + LSOF_PL=$SOLARIS_24P102303 + fi # } + if test $LSOF_PL -ge 2 # { + then + echo "WARNING: your Solaris 2.4 system appears to have patches 101945-32 and 102303-2" + echo " installed. This probably means the NUM_*_VECTORS definitions in" + echo " don't match the ones used to build your kernel. Consult" + echo " the Sun Problems section of the 00FAQ file of the lsof distribution" + echo " for more information on how to work around the problem." + fi # } + fi # } + ;; + 20500|20501) + ;; + 20600|70000|80000|90000|100000|110000) + if test "X$SOLARIS_26PR_GWINDOWS" = "X" # { + then + rm -f ${LSOF_TMPC}.* + echo "#define _KMEMUSER" > ${LSOF_TMPC}.c + echo "#include " >> ${LSOF_TMPC}.c + echo "int main(){" >> ${LSOF_TMPC}.c + echo "enum prnodetype p=PR_GWINDOWS;}" >> ${LSOF_TMPC}.c + echo "Testing prdata.h for PR_GWINDOWS, using $LSOF_CC" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + else + $LSOF_CC ${LSOF_TMPC}.c -I$LSOF_INCLUDE -o ${LSOF_TMPC}.x > /dev/null 2>&1 + fi # } + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPR_GWINDOWS" + fi # } + else + if test "X$SOLARIS_26PR_GWINDOWS" = "XY" -o "X$SOLARIS_26PR_GWINDOWS" = "Xy" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPR_GWINDOWS" + fi # } + fi # } + if test "X$SOLARIS_26PR_LDT" = "X" # { + then + rm -f ${LSOF_TMPC}.* + echo "#define _KMEMUSER" > ${LSOF_TMPC}.c + echo "#include " >> ${LSOF_TMPC}.c + echo "int main(){" >> ${LSOF_TMPC}.c + echo "enum prnodetype p=PR_LDT;}" >> ${LSOF_TMPC}.c + echo "Testing prdata.h for PR_LDT, using $LSOF_CC" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + else + $LSOF_CC ${LSOF_TMPC}.c -I$LSOF_INCLUDE -o ${LSOF_TMPC}.x > /dev/null 2>&1 + fi # } + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPR_LDT" + fi # } + rm -f ${LSOF_TMPC}.* + else + if test "X$SOLARIS_26PR_LDT" = "XY" -o "X$SOLARIS_26PR_LDT" = "Xy" # { + then + LSOF_CFGF="$LSOF_CFGF -DHASPR_LDT" + fi # } + fi # } + if test $LSOF_VERS -ge 70000 # { + then + + # Do tests for Solaris 7 and above. + + if test "X$SOLARIS_KERNBITS" = "X" # { + then + SOLARIS_KERNBITS=`/bin/isainfo -kv` + fi # } + if test "X$SOLARIS_INSTR" = "X" # { + then + SOLARIS_INSTR=`/bin/isainfo -k` + fi #} + echo $SOLARIS_KERNBITS | grep 64 > /dev/null + if test $? -eq 0 # { + then + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + + # Test gcc for 64 bit support. + + echo "Testing $LSOF_CC for 64 bit support" + rm -f ${LSOF_TMPC}.* + echo "int main(){}" > ${LSOF_TMPC}.c + LSOF_TMP1="" + + # First try gcc's -m64 option -- it's the most current possibility. + + $LSOF_CC ${LSOF_TMPC}.c -m64 -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + /bin/file ${LSOF_TMPC}.x | /bin/grep 64 > /dev/null + if test $? -eq 0 # { + then + LSOF_TMP1="-m64" + fi # } + fi # } + rm -f ${LSOF_TMPC}.* + if test "X$LSOF_TMP1" = "X" # { + then + + # Try using the older -mcpu=v9 option with gcc instead of -m64. + + echo "int main(){}" > ${LSOF_TMPC}.c + $LSOF_CC ${LSOF_TMPC}.c -mcpu=v9 -o ${LSOF_TMPC}.x > /dev/null 2>&1 + if test $? -eq 0 # { + then + /bin/file ${LSOF_TMPC}.x | /bin/grep 64 > /dev/null + if test $? -eq 0 # { + then + LSOF_TMP1="-mcpu=v9" + fi # } + fi # } + rm -f ${LSOF_TMPC}.* + fi # } + if test "X$LSOF_TMP1" = "X" # { + then + echo "" + echo "!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!" + echo "! !" + echo "! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT !" + echo "! THIS GCC DOESN'T SUPPORT THE BUILDING OF 64 BIT !" + echo "! SOLARIS EXECUTABLES. LSOF WILL BE CONFIGURED FOR A !" + echo "! 32 BIT KERNEL. !" + echo "! !" + echo "!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!" + echo "" + else + echo "" + echo "*********************************" + echo "* Configuring for 64 bit kernel *" + echo "*********************************" + echo "" + LSOF_CFGF="$LSOF_CFGF $LSOF_TMP1" + LSOF_CINFO="64 bit kernel" + LSOF_TSTK64=1 + fi # } + else + + # Test Sun compiler for 64 bit support. + + case $SOLARIS_INSTR in # { + amd64*) + LSOF_TMP1="amd64" + LSOF_TMP2="amd64" + ;; + sparc*) + LSOF_TMP1="v9" + LSOF_TMP2="sparcv9" + ;; + *) + LSOF_TMP1="" + ;; + esac # } + if test "X$LSOF_TMP1" != "X" # { + then + echo "Testing $LSOF_CC for 64 bit $LSOF_TMP2 support" + rm -f ${LSOF_TMPC}.* + LSOF_TMP3="-xarch=$LSOF_TMP1" + echo "int main(){}" > ${LSOF_TMPC}.c + LSOF_TMP4=`$LSOF_CC ${LSOF_TMPC}.c $LSOF_TMP3 -o ${LSOF_TMPC}.x 2>&1` + if test $? -eq 0 # { + then + /bin/file ${LSOF_TMPC}.x | /bin/grep 64 > /dev/null + if test $? -ne 0 # { + then + LSOF_TMP3="" + else + echo "X$LSOF_TMP4" | grep "use -m64" > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_TMP3=-m64 + fi # } + fi # } + fi # } + rm -f ${LSOF_TMPC}.* + else + LSOF_TMP3="" + fi # } + if test "X$LSOF_TMP3" != "X" # { + then + echo "" + echo "*********************************" + echo "* Configuring for 64 bit kernel *" + echo "*********************************" + echo "" + LSOF_CFGF="$LSOF_CFGF $LSOF_TMP3" + LSOF_CINFO="64 bit kernel" + LSOF_TSTK64=1 + else + echo "" + echo "!!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!" + echo "!" + echo "! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT" + echo "! THE VERSION OF SUN C AVAILABLE DOESN'T SUPPORT THE" + echo "! \"$LSOF_TMP2\" INSTRUCTION SET." + echo "!" + echo "! LSOF WILL BE CONFIGURED FOR A 32 BIT KERNEL." + echo "!" + echo "!!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!" + echo "" + fi # } + fi # } + else + echo "" + echo "*********************************" + echo "* Configuring for 32 bit kernel *" + echo "*********************************" + echo "" + LSOF_CINFO="32 bit kernel" + fi # } + fi # } + + # Do tests specific to Solaris 8 and above. + + if test $LSOF_VERS -ge 80000 # { + then + if test -r ${LSOF_INCLUDE}/netinet/ip6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + fi # } + + # Do tests specific to Solaris 9 and above. + + if test $LSOF_VERS -ge 90000 # { + then + if test -r ${LSOF_INCLUDE}/sys/socketvar.h # { + then + grep soua_vp ${LSOF_INCLUDE}/sys/socketvar.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASSOUXSOUA" + fi # } + fi # } + if test $LSOF_VERS -lt 110000 # { + then + + # Do tests specific to Solaris 9 and 10. + + if test -r ${LSOF_INCLUDE}/sys/lgrp_user.h # { + then + if test -r ${LSOF_INCLUDE}/sys/lgrp.h # { + then + grep lgrp_root ${LSOF_INCLUDE}/sys/lgrp_user.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + grep lgrp_root ${LSOF_INCLUDE}/sys/lgrp.h > /dev/null 2>&1 + if test $? -eq 0 + then + LSOF_CFGF="$LSOF_CFGF -DHAS_LGRP_ROOT_CONFLICT" + fi # } + fi # } + fi # } + fi # } + fi # } + fi # } + + # Do tests specific to Solaris 10 and above. + + if test $LSOF_VERS -eq 100000 # { + then + if test -r ${LSOF_INCLUDE}/sys/socket_proto.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SOCKET_PROTO_H" + fi # } + fi # } + if test $LSOF_VERS -ge 100000 # { + then + if test -r ${LSOF_INCLUDE}/inet/ipclassifier.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_IPCLASSIFIER_H" + grep conn_ixa ${LSOF_INCLUDE}/inet/ipclassifier.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CONN_NEW" + fi #} + fi # } + if test -r ${LSOF_INCLUDE}/sys/cred_impl.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_CRED_IMPL_H" + + # DEBUG -- Begin temporary hack for Solaris 10, build s10_44. + + grep "c2/audit.h" ${LSOF_INCLUDE}/sys/cred_impl.h > /dev/null + if test $? -eq 0 # { + then + rm -rf `pwd`/dialects/sun/solaris10 + mkdir `pwd`/dialects/sun/solaris10 + mkdir `pwd`/dialects/sun/solaris10/c2 + touch `pwd`/dialects/sun/solaris10/c2/audit.h + LSOF_CFGF="$LSOF_CFGF -I`pwd`/dialects/sun/solaris10" + fi # } + + # DEBUG -- End temporary hack for Solaris 10, build s10_44. + + fi # } + if test -r ${LSOF_INCLUDE}/sys/vnode.h # { + then + grep v_path ${LSOF_INCLUDE}/sys/vnode.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_V_PATH" + LSOF_TSTVPATH=1 + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/pc_fs.h # { + then + grep pc_direntpersec ${LSOF_INCLUDE}/sys/fs/pc_fs.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_PC_DIRENTPERSEC" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/aio_req.h # { + then + grep "struct[ ]aio_req" ${LSOF_INCLUDE}/sys/aio_req.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_AIO_REQ_STRUCT" + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/zone.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASZONES" + fi # } + + # Check for Solaris 10 or higher CTF library and things that depend + # on it. + + if test -r ${LSOF_INCLUDE}/libctf.h # { + then + LSOF_CTFH=1 + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/zfs.h # { + then + if test $LSOF_CTFH -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_ZFS" + LSOF_CTFL=1 + else + echo "WARNING: ZFS support not enabled; libctf.h missing." + fi # } + fi # } + if test $LSOF_VERS -ge 110000 # { + then + + # Do things specific to Solaris 11 and above. + + if test $LSOF_CTFH -eq 1 # { + then + LSOF_CTFL=1 + else + echo "WARNING: socket support not enabled; libctf.h missing." + fi # } + rm -rf ./solaris11 + mkdir ./solaris11 + mkdir ./solaris11/sys + touch ./solaris11/sys/extdirent.h + echo "./solaris11/sys/extdirent.h created" + LSOF_CFGF="$LSOF_CFGF -I`pwd`/solaris11" + if test -r ${LSOF_INCLUDE}/sys/mutex.h # { + then + + # Check 'for pad_mutex_t;'. + + grep 'pad_mutex_t;' ${LSOF_INCLUDE}/sys/mutex.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_PAD_MUTEX" + fi # } + fi # ) + fi # } + + # If -lctf was added to LSOF_CFGL, define HAS_LIBCTF. + + if test $LSOF_CTFL -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_LIBCTF" + LSOF_CFGL="$LSOF_CFGL -lctf" + fi # } + ;; + *) + echo "Unsupported Solaris version: $LSOF_VERS" + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + LSOF_CFGF="$LSOF_CFGF -Dsolaris=$LSOF_VERS" + + # Test for . + + if test -r ${LSOF_INCLUDE}/sys/fs/cachefs_fs.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASCACHEFS" + fi # } + + + # Test for . + + if test -r ${LSOF_INCLUDE}/sys/rgm.h { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_SYS_RGM_H" + fi # } + + # Test for . + + if test -r ${LSOF_INCLUDE}/rpc/rpc_tags.h { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_RPC_RPC_TAGS_H" + fi # } + + # Test for + + if test -r ${LSOF_INCLUDE}/utmpx.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASUTMPX" + fi # } + + # Test for VSOCK. + + if test "X$SOLARIS_VSOCK" = "X" # { + then + rm -f ${LSOF_TMPC}.* + echo "#include " > ${LSOF_TMPC}.c + echo "int main(){" >> ${LSOF_TMPC}.c + echo "enum vtype p=VSOCK;}" >> ${LSOF_TMPC}.c + echo "Testing vnode.h for VSOCK, using $LSOF_CC" + echo $LSOF_CC | grep gcc > /dev/null + if test $? -eq 0 # { + then + $LSOF_CC ${LSOF_TMPC}.c -o ${LSOF_TMPC}.x > /dev/null 2>&1 + else + $LSOF_CC ${LSOF_TMPC}.c -I$LSOF_INCLUDE -o ${LSOF_TMPC}.x > /dev/null 2>&1 + fi # } + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_VSOCK" + fi # } + rm -f ${LSOF_TMPC}.* + else + if test "X$SOLARIS_VSOCK" = "XY" -o "X$SOLARIS_VSOCK" = "Xy" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_VSOCK" + fi # } + fi # } + + # Test for AFS. + + if test -r ${AFS_VICE}/etc/ThisCell # { + then + if test "X$LSOF_SCRIPT_CALL" = "Xno" # { + then + if test -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + else + if test ! -x ./AFSConfig # { + then + echo "Can't find or execute the AFSConfig script" + rm -f $LSOF_HLP + exit 1 + fi # } + ./AFSConfig + if test $? -eq 0 -a -r ./AFSHeaders -a -r ./AFSVersion # { + then + LSOF_AFS="yes" + fi # } + fi # } + if test "X$LSOF_AFS" = "Xyes" # { + then + if test "X$SUN_AFSAPATHDEF" = "X" # { + then + ls /usr/vice/etc/modload/libafs > /dev/null 2>&1 + if test $? -ne 0 # { + then + LSOF_TMP1=`ls /usr/vice/etc/modload/libafs* 2>/dev/null | wc -l` + if test $LSOF_TMP1 -ne 0 # { + then + SUN_AFSAPATHDEF=`ls -t /usr/vice/etc/modload/libafs* | head -1` + fi # } + fi # } + fi # } + if test "X$SUN_AFSAPATHDEF" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DAFSAPATHDEF=\\\"$SUN_AFSAPATHDEF\\\"" + fi # } + LSOF_AFSV=`cat ./AFSVersion | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1 \2/' | awk '{printf "%d%02d\n",\$1,\$2}'` + LSOF_CFGF="$LSOF_CFGF -DHAS_AFS=$LSOF_AFSV" + LSOF_DINC="$LSOF_DINC -I`cat ./AFSHeaders`" + fi # } + fi # } + + # Test for VxFS. + # + # If the location of the VxFS header files hasn't been defined in the + # environment, establish their likely locations. + + LSOF_TMP2=$SOLARIS_VXFSINCL + if test -d /opt/VRTS/include # { + then + LSOF_TMP2="$LSOF_TMP2 /opt/VRTS/include" + fi # } + if test -d /opt/VRTSvxfs/include # { + then + LSOF_TMP2="$LSOF_TMP2 /opt/VRTSvxfs/include" + fi # } + LSOF_TMP1=0 + for i in $LSOF_TMP2 # { + do + if test -r ${i}/vxfsutil.h # { + then + LSOF_TMP1=1 + SOLARIS_VXFSINCL=$i + break + fi # } + done # } + if test $LSOF_TMP1 -eq 1 # { + then + + # Warn that VxFS is unsupported. + + LSOF_UNSUP2="WARNING: VxFS is no longer supported by Solaris lsof." + + # The VxFS header files are for VxFS version 3.4 or above. Enable VxFS + # for those versions. + + LSOF_CFGF="$LSOF_CFGF -DHASVXFS -DHASVXFSUTIL -I$SOLARIS_VXFSINCL" + + # Determine which libvxfsutil.a is required -- 32 or 64 bit. + + LSOF_TMP2="" # assume 32 bit + echo "X$LSOF_CINFO" | grep "^X64" > /dev/null 2>&1 + if test $? -eq 0-a "X$SOLARIS_INSTR" != "X" # { + then + case $SOLARIS_INSTR in # { + amd64*) + LSOF_TMP2="/amd64" + ;; + sparcv9*) + LSOF_TMP2="/sparcv9" + ;; + esac # } + fi # } + + # See if the correct library has been specified and exists. + + if test "X$SOLARIS_VXFSLIB" = "X" # { + then + SOLARIS_VXFSLIB=`dirname $SOLARIS_VXFSINCL`/lib + fi # } + LSOF_TMP3="${SOLARIS_VXFSLIB}${LSOF_TMP2}/libvxfsutil.a" + if test ! -r $LSOF_TMP3 # { + then + echo "!!!FATAL: no VxFS $LSOF_TMP3" + exit 1 + fi # } + LSOF_CFGL="$LSOF_CFGL -L$SOLARIS_VXFSLIB${LSOF_TMP2} -lvxfsutil -ldl" + + # See if the library has the Reverse Name Lookup (RNL) function. + + nm $LSOF_TMP3 | grep vxfs_inotopath > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFSRNL -DHASVXFSDNLC" + fi # } + else + + # See if there are VxFS header files for VxFS versions below 3.4. + + if test -r ${LSOF_INCLUDE}/sys/fs/vx_inode.h # { + then + + # Define VxFS for VxFS versions below 3.4. Make additional header + # file tests. + + LSOF_CFGF="$LSOF_CFGF -DHASVXFS" + if test -r ${LSOF_INCLUDE}/sys/fs/vx_fs.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_FS_H" + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/vx_sol.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_SOL_H" + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/vx_machdep.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_MACHDEP_H" + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/vx_solaris.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_SOLARIS_H" + grep "off32_t;" ${LSOF_INCLUDE}/sys/fs/vx_machdep.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_OFF32_T" + fi # } + grep "off64_t;" ${LSOF_INCLUDE}/sys/fs/vx_solaris.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_OFF64_T" + fi # } + grep "vx_u64_t;" ${LSOF_INCLUDE}/sys/fs/vx_solaris.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_U64_T" + fi # } + fi # } + egrep "struct[ ]vx_inode[ ]\{" ${LSOF_INCLUDE}/sys/fs/vx_inode.h > /dev/null + # } (dummy '}' to match '{' in above egrep) + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS_VX_INODE" + fi # } + fi # } + fi # } + + # Set libraries and dialect subdirectory. + + LSOF_CFGL="$LSOF_CFGL -lkvm -lelf -lsocket -lnsl" + LSOF_DIALECT_DIR=sun + + # Set local-specific stuff. + + if test "X$LSOF_LOCALSUFFIX" = "XLOCAL" # { + then + LSOF_DOC="\${DESTDIR}/usr/local/man" + fi # } + ;; + +# Configure for SCO|Caldera OpenServer Release 6.0.0 and UnixWare. + + osr6|unixware|uw) + LSOF_TMP1=$LSOF_TGT + LSOF_TGT="uw" + if test "X$LSOF_RANLIB_SUP" = "X" # { + then + LSOF_RANLIB="" + fi # } + if test "X$LSOF_VSTR" = "X" # { + then + LSOF_VSTR=`uname -v` + fi # } + if test "X$LSOF_VERS" = "X" # { + then + + # If the Openserver Release 6.0.0 or UnixWare version isn't pre-defined, + # determine it. + + LSOF_VERS=`echo $LSOF_VSTR | sed 's/\([0-9\.]*\).*/\1/; s/\./ /g' | awk '{printf "%d%02d%02d\n", $1, $2, $3;}'` + fi # } + if test $LSOF_TMP1 = "osr6" # { + then + LSOF_CINFO="OSR6 support via UnixWare sources" + + # Convert the OpenServer Release 6.0.0 version number to a UnixWare one. + + case $LSOF_VERS in # { + 60000) + LSOF_VERS=70104 + ;; + *) + echo "Unknown OpenServer Release version: $LSOF_VERS" + rm -f $LSOF_HLP + exit 1 + esac # } + fi # } + LSOF_CFGF="$LSOF_CFGF -DUNIXWAREV=$LSOF_VERS" + + # Do OpenServer Release 6.0.0 and UnixWare version-specific stuff. + + case $LSOF_VERS in # { + 20100|20101|20102|20103) + if test -r ${LSOF_INCLUDE}/sys/fs/vx_inode.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS" + fi # } + LSOF_CFGL="$LSOF_CFGL -lsocket -lnsl -lelf -lgen" + ;; + 70000|70001|70100|70101|70103|70104) + LSOF_TSTBIGF=" " + LSOF_TSTLFLG="-lsocket -lnsl" + if test $LSOF_VERS -lt 70103 # { + then + LSOF_DINC="$LSOF_DINC -I`pwd`/dialects/uw/uw7" + else # $LSOF_VERS -ge 70103 + + # Process 7.1.3 and above. + + if test -r ${LSOF_INCLUDE}/netinet/in6.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASIPv6" + fi # } + if test $LSOF_VERS -ge 70104 # { + then + + # Process 7.1.4 and above. + + LSOF_TMP1=0 + if test -r ${LSOF_INCLUDE}/netinet/in_pcb.h # { + then + grep INKERNEL ${LSOF_INCLUDE}/netinet/in_pcb.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_TMP1=1 + fi # } + fi # } + if test $LSOF_TMP1 -eq 0 -a -r ${LSOF_INCLUDE}/netinet/tcp_var.h # { + then + grep INKERNEL ${LSOF_INCLUDE}/netinet/tcp_var.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_TMP1=1 + fi # } + fi # } + if test $LSOF_TMP1 -eq 1 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_INKERNEL" + fi # } + fi # } + fi # } + if test ! -r ${LSOF_INCLUDE}/vm/swap.h -a -r ${LSOF_INCLUDE}/sys/swap.h # { + then + (cd ./dialects/uw/uw7/vm; rm -f swap.h; ln -s ${LSOF_INCLUDE}/sys/swap.h swap.h) + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/vx_gemini.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASVXFS" + fi # } + LSOF_CFGL="$LSOF_CFGL -lsocket -lnsl -lelf -lgen" + /bin/pkginfo 2> /dev/null | grep -i patch | grep -i ptf7038 > /dev/null + if test -r ${LSOF_INCLUDE}/sys/file.h # { + then + grep f_open ${LSOF_INCLUDE}/sys/file.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_F_OPEN" + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/fs/cdfs_fs.h # { + then + grep "cdfs_LogSecShift;" ${LSOF_INCLUDE}/sys/fs/cdfs_fs.h > /dev/null 2>&1 + if test $? -eq 0 # { + then + LSOF_TMP=`grep "cdfs_LogSecShift;" ${LSOF_INCLUDE}/sys/fs/cdfs_fs.h | sed 's/^[ ]*\([^ ]*\).*/\1/'` + if test "X$LSOF_TMP" != "X" # { + then + LSOF_CFGF="$LSOF_CFGF -DTYPELOGSECSHIFT=$LSOF_TMP" + fi # } + fi # } + fi # } + if test -r ${LSOF_INCLUDE}/sys/proc.h # { + then + grep p_pgid ${LSOF_INCLUDE}/sys/proc.h > /dev/null + if test $? -eq 0 # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_P_PGID" + fi # } + fi # } + if test $LSOF_VERS -ge 70101 # { + then + + # Do OpenServer Release 6.0.0 and UnixWare 7.1.1 and above tests, as + # required. + + if test "X$UW_HAS_NSC" = "X" # { + then + UW_HAS_NSC=N + if test -x /bin/node_self # { + then + /bin/node_self > /dev/null 2>&1 + if test $? -eq 0 # { + then + UW_HAS_NSC=Y + fi # } + fi # } + fi # } + if test "X$UW_HAS_NSC" = "XY" -o "X$UW_HAS_NSC" = "Xy" # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_UW_NSC" + LSOF_CFGL="$LSOF_CFGL -lcluster" + fi # } + if test -r ${LSOF_INCLUDE}/sys/nsc_synch.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHAS_UW_CFS" + fi # } + fi # } + ;; + *) + echo Unsupported UnixWare version: `uname -v` + rm -f $LSOF_HLP + exit 1 + ;; + esac # } + if test -r ${LSOF_INCLUDE}/sys/fs/xnamnode.h # { + then + LSOF_CFGF="$LSOF_CFGF -DHASXNAMNODE" + fi # } + LSOF_DIALECT_DIR=uw + ;; + +# Handle unknown abbreviation. + + *) + echo "Can't configure for $LSOF_TGT." + cat $LSOF_HLP + rm -f $LSOF_HLP + exit 1 + ;; + +# End of LSOF_TGT cases + +esac # } + +# Do an inventory of the distribution, as required. + +if test "X$LSOF_SCRIPT_CALL" = "Xyes" -a ! -r ./.neverInv # { +then + if test ! -f ./Inventory # Want -x, but Ultrix doesn't grok it. # { + then + echo "Can't find Inventory script." + rm -f $LSOF_HLP + exit 1 + fi # } + ./Inventory +fi # } + +# Make sure target directory exists. + +if test ! -d ./lib/dialects/$LSOF_DIALECT_DIR # { +then + echo "Can't configure for $LSOF_TGT -- ./lib/dialects/$LSOF_DIALECT_DIR doesn't exist." + rm -f $LSOF_HLP + exit 1 +fi # } + +# Make sure $LSOF_MK exists in the target directory. + +if test ! -r ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_MK # { +then + echo "Can't configure for $LSOF_TGT -- ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_MK doesn't exist." + rm -f $LSOF_HLP + exit 1 +fi # } + +# Make sure $LSOF_MKF, $LSOF_SPMKF, or $LSOF_MKF.$LSOF_LOCALSUFFIX) exists +# in the target directory. + +if test "X$LSOF_SPMKF" != "X" # { +then + LSOF_TMP1=$LSOF_SPMKF +else + LSOF_TMP1=$LSOF_MKF +fi # } +if test "X$LSOF_LOCALSUFFIX" != "X" # { +then + LSOF_REST=$LSOF_TMP1.$LSOF_LOCALSUFFIX +else + LSOF_REST=$LSOF_TMP1 +fi # } +if test ! -r ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_REST # { +then + echo "Can't configure for $LSOF_TGT -- ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_REST doesn't exist." + rm -f $LSOF_HLP + exit 1 +fi # } + +# If this is FreeBSD, make sure $LSOF_FBSD_ZFS_MKF exists. + +if test $LSOF_FBSD_ZFS -eq 1 # { +then + if test ! ./dialects/$LSOF_DIALECT_DIR/$LSOF_FBSD_ZFS_MKF # { + then + echo "Can't configure for $LSOF_TGT -- ./dialects/$LSOF_DIALECT_DIR/$LSOF_FBSD_ZFS_MKF doesn't exist." + rm -f $LSOF_HLP + exit 1 + fi # } +fi # }} + +# Make sure $LSOF_VF exists. Extract the version number from it. + +if test ! -r $LSOF_VF # { +then + echo "Version number file, ./$LSOF_VF, doesn't exist." + rm -f $LSOF_HLP + exit 1 +else + LSOF_VN=`sed "s/.ds VN \(.*\)/\1/" < $LSOF_VF` +fi # } + +# Clean up in advance. + +rm -f $LSOF_F $LSOF_MKFC $LSOF_FBSD_ZFS_MKF $LSOF_TSTCFLG $LSOF_TSTCC +rm -f $LSOF_TSTXOC $LSOF_TSTLFF +echo "rm -f $LSOF_F $LSOF_MKFC $LSOF_FBSD_ZFS_MKF $LSOF_TSTCFLG" +echo "rm -f $LSOF_TSTCC $LSOF_TSTXOC $LSOF_TSTLFF" + +# Make sure there's a C compiler name. + +if test "X$LSOF_CC" = "X" # { +then + LSOF_CC=cc +fi # } + +# Do common feature analyses. + +# Check for localtime(3) and strftime(3). + +rm -f ${LSOF_TMPC}.* +cat > $LSOF_TMPC.c << .LSOF_END_HERE_DOC2 +#include +int main(){ + time_t cl; + struct tm *ts; + char bf[32]; + if ((cl = time(NULL)) == (time_t)-1) + return(1); + ts = localtime(&cl); + if (strftime(bf, sizeof(bf), "%D", ts) != 8) + return(1); + if ((bf[2] != '/') || (bf[5] != '/')) + return (1); + return(0); +} +.LSOF_END_HERE_DOC2 +echo $EO "Testing C library for localtime() and strftime(), using $LSOF_CC ... $EC" +$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 # } + then + LSOF_CFGF="$LSOF_CFGF -DHAS_STRFTIME" + echo "present" + else + echo "unusable" + fi # } +else + echo "missing" +fi # } +rm -f ${LSOF_TMPC}.[cox] + +# Make the dialect sources. + +if test "X$LSOF_MKC" = "X" # { +then + LSOF_MKC="ln -s" +fi # } +LSOF_MKC=$LSOF_MKC ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_MK $LSOF_TGT $LSOF_VERS || exit 1 + +# Make $LSOF_MKFC and ${LSOF_LIB}/$LSOF_LIBMKF. + +echo "# $LSOF_TGT Makefile for lsof revision $LSOF_VN" > $LSOF_MKFC +echo "" >> $LSOF_MKFC +echo "CC= $LSOF_CC" >> $LSOF_MKFC +if test "X$LSOF_CCV" != "X" # { +then + echo "" >> $LSOF_MKFC + echo "CCV= $LSOF_CCV" >> $LSOF_MKFC +fi # } +if test "X$LSOF_LIB_NO" = "X" # { +then + echo "" >> $LSOF_MKFC + echo "LIB= ${LSOF_LIB}/liblsof.a" >> $LSOF_MKFC +fi # } +if test "X$LSOF_LD" != "X" # { +then + echo "" >> $LSOF_MKFC + echo "LD= $LSOF_LD" >> $LSOF_MKFC +fi # } +if test "X$LSOF_CINFO" != "X" # { +then + echo "" >> $LSOF_MKFC + echo "CINFO= $LSOF_CINFO" >> $LSOF_MKFC +fi # } +if test "X$LSOF_CFGD" != "X" # { +then + echo "CFGD= $LSOF_CFGD" >> $LSOF_MKFC +fi # } +if test "X$LSOF_CFGDN" != "X" # { +then + echo "CFGDN= $LSOF_CFGDN" >> $LSOF_MKFC +fi # } +if test "X$LSOF_ARCH" != "X" # { +then + LSOF_CFGF="$LSOF_CFGF -DLSOF_ARCH=\\\"$LSOF_ARCH\\\"" +fi # } +if test "X$LSOF_VSTR" != "X" # { +then + LSOF_TMP=`echo $LSOF_VSTR | sed 's/(/\\\\(/g' | sed 's/)/\\\\)/g'` + LSOF_CFGF="$LSOF_CFGF -DLSOF_VSTR=\\\"$LSOF_TMP\\\"" +fi # } +echo "" >> $LSOF_MKFC +echo "CFGF= $LSOF_CFGF" >> $LSOF_MKFC +if test "X$LSOF_LIB_NO" = "X" # { +then + echo "" >> $LSOF_MKFC + echo "CFGL= $LSOF_FCFGL -L./$LSOF_LIB -llsof $LSOF_CFGL" >> $LSOF_MKFC +fi # } +echo "" >> $LSOF_MKFC +if test "X$LSOF_DEBUG" = "X" # { +then + LSOF_DEBUG="" +else + if test "X$LSOF_DEBUG" = "XNo-O" # { + then + LSOF_DEBUG="" + fi # } +fi # } +echo "DEBUG= $LSOF_DEBUG" >> $LSOF_MKFC +if test "X$LSOF_OPINC" != "X" # { +then + LSOF_DINC="$LSOF_DINC $LSOF_OPINC" +fi # } +if test "X$LSOF_DINC" != "X" # { +then + echo "" >> $LSOF_MKFC + echo "DINC= $LSOF_DINC" >> $LSOF_MKFC +fi # } +if test "X$LSOF_DOC" != "X" # { +then + echo "" >> $LSOF_MKFC + echo "DOC=$LSOF_DOC" >> $LSOF_MKFC +fi # } +if test "X$LSOF_DISTRIBKVM" != "X" -a "X$LSOF_DISTRIBKVM" != "XKVM" # { +then + echo "" >> $LSOF_MKFC + echo "KVM= $LSOF_DISTRIBKVM" >> $LSOF_MKFC +fi # } +echo "" >> $LSOF_MKFC +echo "DIALECT_DIR= $LSOF_DIALECT_DIR" >> $LSOF_MKFC +rm -f ${LSOF_LIB}/$LSOF_LIBMKF +if test "X$LSOF_LIB_NO" = "X" # { +then + cp $LSOF_MKFC ${LSOF_LIB}/$LSOF_LIBMKF +fi # } +cat ./lib/dialects/$LSOF_DIALECT_DIR/$LSOF_REST >> $LSOF_MKFC +if test "X$LSOF_CFLAGS_OVERRIDE" != "X" # { +then + sed -i -e 's/^CFLAGS=/override CFLAGS=/' $LSOF_MKFC +fi # } +if test "X$LSOF_LIB_NO" = "X" # { +then + + # Put archiving and optional randomizing strings in ${LSOF_LIB}/$LSOF_LIBMKF. + # + # Process optional CFLAGS override. + # + # Add the library Makefile skeleton section. + + echo "" >> ${LSOF_LIB}/$LSOF_LIBMKF + echo "DIALECT_DIR= $LSOF_DIALECT_DIR" >> ${LSOF_LIB}/$LSOF_LIBMKF + echo "" >> ${LSOF_LIB}/$LSOF_LIBMKF + if test "X$LSOF_AR" = "X" # { + then + echo "AR= ar cr \${LIB} \${OBJ}" >> ${LSOF_LIB}/$LSOF_LIBMKF + else + echo "AR= $LSOF_AR \${LIB} \${OBJ}" >> ${LSOF_LIB}/$LSOF_LIBMKF + fi # } + if test "X$LSOF_RANLIB" != "X" # { + then + echo "" >> ${LSOF_LIB}/$LSOF_LIBMKF + echo "RANLIB= $LSOF_RANLIB \${LIB}" >> ${LSOF_LIB}/$LSOF_LIBMKF + fi # } + echo "" >> ${LSOF_LIB}/$LSOF_LIBMKF + if test "X$LSOF_CFLAGS_OVERRIDE" = "X" # { + then + echo "CFLAGS= \${CDEFS} \${INCL} \${DEBUG}" >> ${LSOF_LIB}/$LSOF_LIBMKF + else + echo "override CFLAGS=\${CDEFS} \${INCL} \${DEBUG}" >> ${LSOF_LIB}/$LSOF_LIBMKF + fi # } + echo "" >> ${LSOF_LIB}/$LSOF_LIBMKF + cat ${LSOF_LIB}/$LSOF_LIBMKFSKEL >> ${LSOF_LIB}/$LSOF_LIBMKF + echo $LSOF_MKFC and ${LSOF_LIB}/$LSOF_LIBMKF created. +else + echo $LSOF_MKFC created. +fi # } + +# If this is FreeBSD, create $LSOF_FBSD_ZFS_MKF. + +if test $LSOF_FBSD_ZFS -eq 1 # { +then + rm -f $LSOF_FBSD_ZFS_MKF + echo "# $LSOF_TGT ZFS Makefile for lsof revision $LSOF_VN" > $LSOF_FBSD_ZFS_MKF + echo "" >> $LSOF_FBSD_ZFS_MKF + echo "CC= $LSOF_CC" >> $LSOF_FBSD_ZFS_MKF + echo "" >> $LSOF_FBSD_ZFS_MKF + echo "CFLAGS= $LSOF_FBSD_ZFS_CFGF" >> $LSOF_FBSD_ZFS_MKF + echo "" >> $LSOF_FBSD_ZFS_MKF + if test "X$LSOF_DEBUG" = "X" # { + then + LSOF_DEBUG="-O" + else + if test "X$LSOF_DEBUG" = "XNo-O" # { + then + LSOF_DEBUG="" + fi # } + fi # } + echo "DEBUG= $LSOF_DEBUG" >> $LSOF_FBSD_ZFS_MKF + echo "" >> $LSOF_FBSD_ZFS_MKF + echo "OPENSOLARIS= $LSOF_FBSD_ZFS_SYS" >> $LSOF_FBSD_ZFS_MKF + echo "" >> $LSOF_FBSD_ZFS_MKF + cat ./dialects/$LSOF_DIALECT_DIR/$LSOF_FBSD_ZFS_MKF >> $LSOF_FBSD_ZFS_MKF + echo $LSOF_FBSD_ZFS_MKF created. +fi # } + +# Create test cc file. + +echo "$LSOF_CC" > $LSOF_TSTCC +echo "$LSOF_TSTCC created" + +# Create test cflags file. + +echo "-DLT_DIAL_$LSOF_TGT" > $LSOF_TSTCFLG +if test "X$LSOF_TSTBIGF" != "X" # { +then + echo "-DLT_BIGF" >> $LSOF_TSTCFLG + if test "X$LSOF_TSTBIGF" != "X " # { + then + for i in $LSOF_TSTBIGF # { + do + echo "$i" >> $LSOF_TSTCFLG + done # } + fi # } +fi # } +if test "X$LSOF_TSTDFLG" != "X" # { +then + for i in $LSOF_TSTDFLG # { + do + echo "$i" >> $LSOF_TSTCFLG + done # } +fi # } +echo $LSOF_CC | grep gcc > /dev/null 2>&1 +if test $? -eq 0 # { +then + echo "-DLT_GCC" >> $LSOF_TSTCFLG +else + echo "-DLT_CC" >> $LSOF_TSTCFLG +fi # r} +if test $LSOF_TSTKMEM -eq 1 # { +then + echo "-DLT_KMEM" >> $LSOF_TSTCFLG +fi # } +if test $LSOF_TSTK64 -eq 1 # { +then + echo "-DLT_K64" >> $LSOF_TSTCFLG +fi # } +echo "-DLT_VERS=$LSOF_VERS" >> $LSOF_TSTCFLG +if test $LSOF_TSTVPATH -eq 1 # { +then + echo "-DLT_VPATH" >> $LSOF_TSTCFLG +fi # } +echo "$LSOF_TSTCFLG created" + +# Create tests loader flags file. + +echo $LSOF_TSTLFLG > $LSOF_TSTLFF +echo "$LSOF_TSTLFF created" + +# Create test extra objects file. + +echo "$LSOF_TSTXO" > $LSOF_TSTXOC +echo "$LSOF_TSTXOC created" + +rm -f $LSOF_HLP + +# Call Customize, as required. + +if test "X$LSOF_SCRIPT_CALL" = "Xyes" -a ! -r ./.neverCust # { +then + if test ! -f ./Customize # { Want -x, but Ultrix doesn't grok it. + then + echo "Can't find Customize script." + exit 1 + fi # } + ./Customize $LSOF_DIALECT_DIR +fi # } + +# Issue unsupported warnings, as appropriate. + +if test "X$LSOF_UNSUP" != "X" # { +then + echo "$LSOF_UNSUP" +fi #} +if test "X$LSOF_UNSUP2" != "X" # { +then + echo "$LSOF_UNSUP2" +fi #} +exit 0 diff --git a/Customize b/Customize new file mode 100755 index 0000000..3a01ea6 --- /dev/null +++ b/Customize @@ -0,0 +1,1151 @@ +#!/bin/sh +# +# $Id: Customize,v 1.9 2005/05/11 13:02:18 abe Exp $ +# +# Customize: customize dialect's machine.h header file. +# +# Allows easy modification of some important compile-time definitions for +# lsof, made in the dialect's machine.h header file, including: +# +# HASSECURITY the security option +# HASNOSOCKSECURITY +# the socket oberalization of HASSECURITY +# HASDCACHE enabling/disabling the device cache file +# (Note: changing the device cache file option isn't +# offered when machine.h contains NEVER_HASDCACHE +# anywhere, including in a comment.) +# HASENVDC enabling/disabling device cache path from environment +# HASKERNIDCK enabling/disabling the kernel identity check +# (not done for some dialects) +# HASPERSDC enabling/disabling personal device cache path +# construction +# HASPERSDCPATH enabling/disabling additional personal device cache +# path component +# HASSYSDC enabling/disabling system-wide device cache file path +# HASXOPT_ROOT enabling/disabling root use of the -X option +# WARNDEVACCESS enabling inaccessible /dev node warnings +# (Note: changing the inaccessible /dev/node warning +# option isn't offered when machine.h contains +# NEVER_WARNDEVACCESS anywhere, including in a +# comment.) +# WARNINGSTATE enable/disabling default warning message state +# +# Usage: Customize [dialect_directory] +# +# where: dialect_directory (optional) is the directory in which the dialect's +# dialect's sources, Makefile and scripts are found + +OLD=machine.h +NEW=new_machine.h + +# Save optional dialect directory. + +if test $# -eq 1 +then + DialDir=$1 +else + DialDir="" +fi + +# Establish trap and stty handling. + +ISIG=":" +trap 'rm -f $NEW; $ISIG; exit 1' 1 2 3 15 +stty -a 2>&1 | grep isig > /dev/null +if test $? -eq 0 +then + stty -a 2>&1 | egrep -e -isig > /dev/null + if test $? -eq 0 + then + ISIG="stty -isig" + stty isig + fi +fi + +# Decide how to use echo. + +ECHO=`echo -n ""` +if test "X$ECHO" = "X-n " +then + EC="\c" + EO="" +else + EC="" + EO="-n" +fi + +# Decide how to use tail(1). + +TMP1=`tail -n 1 $0 2> /dev/null` +if test $? -eq 0 -a "X$TMP1" = "X#LAST_LINE" +then + TA="-n 1" +else + TA="-1" +fi + +# Display the introduction and basic explanation. + +cat << .CAT_MARK + +You may now customize the machine.h header file for this UNIX +dialect. The customizations will take effect when you compile +lsof. You may also choose to skip customization and proceed to +the compilation of lsof. + +If you don't know if you need to customize or want to know more +about what you can customize, consult the 00DCACHE, 00FAQ, 00PORTING, +and 00README files of the lsof distribution. You might also find +it helpful to examine the machine.h header file for the dialect +you're customizing. + +You don't need to use this procedure to customize lsof; you can +edit the machine.h header file directly. If you later decide you +want to use this procedure to customize machine.h, execute the +./Customize script. +.CAT_MARK + +END=0 +while test $END -eq 0 +do + echo "" + echo $EO "Do you want to customize (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + exit 0 + fi + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + echo "" + echo "Customizing ..." + END=1 + else + echo "" + echo "Please answer y|n [y]." + fi +done + +# See if $OLD exists. + +if test ! -r $OLD +then + echo "" + echo "FATAL: The file \"$OLD\" doesn't exist. Customization can't" + echo "continue without it." + echo "" + echo "Did you run the Configure script?" + echo "" + echo "Customize quits." + echo "" + exit 1 +fi + +# See if $NEW exists. + +if test -r $NEW +then + echo "" + echo "=====================================================================" + echo "" + echo "WARNING: \"$NEW\" exists. Customization will replace it." + END=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to remove $NEW (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + echo "" + echo "Removing $NEW" + echo "" + rm -f $NEW + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + echo "" + echo "FATAL: Customize quits; it must be able to create \"$NEW\"." + echo "" + exit 1 + else + echo "" + echo "Please answer y|n [y]." + fi + fi + done +fi + +# Process HASSECURITY. + +cat << .CAT_MARK + +===================================================================== + +When HASSECURITY is enabled, only the root user may use lsof to +examine all open files; other users may examine only the files +belonging to the real user ID of their lsof process. If +HASNOSOCKSECURITY is also defined, anyone may list anyone else's +open socket files, provided their listing is selected with the "-i" +option. + +When HASSECURITY is disabled, anyone may use lsof to examine all +open files. + +.CAT_MARK + +grep HASSECURITY $OLD | tail $TA | egrep "^#define" > /dev/null +if test $? -eq 0 +then + echo "HASSECURITY is enabled." + NSEC=1 +else + echo "HASSECURITY is disabled." + NSEC=0 +fi +END=0 +while test $END -eq 0 +do + echo "" + if test $NSEC -eq 1 + then + echo $EO "Disable HASSECURITY (y|n) [n]? $EC" + else + echo $EO "Enable HASSECURITY (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $NSEC -eq 1 + then + NSEC=0 + echo "HASSECURITY will be disabled." + else + NSEC=1 + echo "HASSECURITY will be enabled." + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASSECURITY will not be changed." + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi +done + +# If HASSECURITY is enabled, see if HASNOSOCKSECURITY should also be defined. + +if test $NSEC -eq 1 +then + cat << .CAT_MARK + +==================================================================== + +When HASSECURITY is enabled, you may also define HASNOSOCKSECURITY. + +When both are defined, no one but root may list all of anyone else's +open files -- only their own open files -- but anyone may list +anyone else's open socket files. + +This option is useful with ntop (http://www.ntop.org). + +.CAT_MARK + + grep HASNOSOCKSECURITY $OLD | tail $TA | egrep "^#define" > /dev/null + if test $? -eq 0 + then + echo "HASNOSOCKSECURITY is enabled." + SOCKSEC=1 + else + echo "HASNOSOCKSECURITY is disabled." + SOCKSEC=0 + fi + END=0 + while test $END -eq 0 + do + echo "" + if test $SOCKSEC -eq 1 + then + echo $EO "Disable HASNOSOCKSECURITY (y|n) [n]? $EC" + else + echo $EO "Enable HASNOSOCKSECURITY (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $SOCKSEC -eq 1 + then + SOCKSEC=0 + echo "HASNOSOCKSECURITY will be disabled." + else + SOCKSEC=1 + echo "HASNOSOCKSECURITY will be enabled." + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASNOSOCKSECURITY will not be changed." + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done +else + SOCKSEC=0 +fi + +# Process WARNINGSTATE. + +cat << .CAT_MARK + +===================================================================== + +When WARNINGSTATE is enabled, lsof will issue whatever warning +messages it finds necessary. When WARNINGSTATE is disabled, lsof +will issue no warning messages. For individual uses of lsof, -w +disables warning state and +w enables it. + +.CAT_MARK + +grep WARNINGSTATE $OLD | tail $TA | egrep "^#define" > /dev/null +if test $? -eq 0 +then + echo "WARNINGSTATE is disabled." + WST=0 +else + echo "WARNINGSTATE is enabled." + WST=1 +fi +END=0 +NWST=$WST +while test $END -eq 0 +do + echo "" + if test $NWST -eq 0 + then + echo $EO "Enable WARNINGSTATE? (y|n) [n]? $EC" + else + echo $EO "Disable WARNINGSTATE? (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $NWST -eq 0 + then + echo "WARNINGSTATE will be enabled." + NWST=1 + else + echo "WARNINGSTATE will be disabled." + NWST=0 + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "WARNINGSTATE will not be changed." + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi +done + +# Process WARNDEVACCESS, unless the dialect's machine.h header file contains +# NEVER_WARNDEVACCESS. + +grep NEVER_WARNDEVACCESS $OLD > /dev/null +if test $? -eq 0 +then + NEVERWDA=1 + NWDA=0 +else + NEVERWDA=0 + cat << .CAT_MARK + +===================================================================== + +When WARNDEVACCESS is enabled, lsof will issue warning messages +when it can't access nodes in /dev (or /devices), subject to the +default or explicit (-w) WARNINGSTATE. + +When WARNDEVACCESS is disabled, lsof will silently skip nodes in +/dev (or /devices) that it can't access. + +.CAT_MARK + + grep WARNDEVACCESS $OLD | tail $TA | egrep "^#define" > /dev/null + if test $? -eq 0 + then + echo "WARNDEVACCESS is enabled." + WDA=1 + else + echo "WARNDEVACCESS is disabled." + WDA=0 + fi + END=0 + NWDA=$WDA + while test $END -eq 0 + do + echo "" + if test $NWDA -eq 1 + then + echo $EO "Disable WARNDEVACCESS (y|n) [n]? $EC" + else + echo $EO "Enable WARNDEVACCESS (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $NWDA -eq 1 + then + echo "WARNDEVACCESS will be disabled." + NWDA=0 + else + echo "WARNDEVACCESS will be enabled." + NWDA=1 + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "WARNDEVACCESS will not be changed." + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done +fi + +# Process HASDCACHE, unless the dialect's machine.h header file contains +# NEVER_HASDCACHE. + +ENVV="" +ENVN=0 +PDCV="" +PDCN=0 +PDCPV="" +PDCPN=0 +SDCV="" +SDCN=0 +grep NEVER_HASDCACHE $OLD > /dev/null +if test $? -eq 0 +then + NEVERDC=1 + CDC=0 + DC=0 + NDC=0 +else + NEVERDC=0 + cat << .CAT_MARK + +===================================================================== + +When HASDCACHE is enabled, lsof will write a device cache file that +contains information about the nodes in /dev (or /devices). The +options HASENVDC, HASPERSDC, HASPERSDCPATH, and HASSYSDC define +the device cache file path. + +When HASDCACHE is disabled, lsof won't write a device cache file. + +Consult the 00DCACHE and 00FAQ files of the lsof distribution for +more information. + +.CAT_MARK + + grep HASDCACHE $OLD | tail $TA | egrep "^#define" > /dev/null + if test $? -eq 0 + then + echo "HASDCACHE is enabled." + DC=1 + else + echo "HASDCACHE is disabled." + DC=0 + fi + END=0 + NDC=$DC + while test $END -eq 0 + do + echo "" + if test $NDC -eq 1 + then + echo $EO "Disable HASDCACHE (y|n) [n]? $EC" + else + echo $EO "Enable HASDCACHE (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $NDC -eq 1 + then + echo "HASDCACHE will be disabled." + NDC=0 + else + echo "HASDCACHE will be enabled." + NDC=1 + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASDCACHE will not be changed." + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done + + # See if other device cache options need to be declared. + + if test $DC -eq 1 -a $NDC -eq 1 + then + cat << .CAT_MARK + +===================================================================== + +You have decided that HASDCACHE should be defined. There are other +definitions associated with HASDCACHE that specify options for the +formation of the device cache file path. You may change them. + +Consult the 00DCACHE and 00FAQ files of the lsof distribution for +more information. + +The current path options are: + +.CAT_MARK + + grep HASENVDC $OLD | tail $TA | egrep "^#define" + egrep "HASPERSDC$|HASPERSDC[ ]" $OLD | tail $TA | egrep "^#define" + grep HASPERSDCPATH $OLD | tail $TA | egrep "^#define" + grep HASSYSDC $OLD | tail $TA | egrep "^#define" + END=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to change path options (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + CDC=1 + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + CDC=0 + END=1 + else + if test "X$ANS" = "X" + then + echo "" + echo "The path options will not be changed." + CDC=0 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + fi + done + else + CDC=0 + fi + if test \( $NDC -eq 1 -a $DC -eq 0 \) -o \( $DC -eq 1 -a $CDC -eq 1 \) + then + cat << .CAT_MARK + +===================================================================== + +You may specify for HASENVDC the name of the environment variable +from which lsof should take the device cache file path for non-root +users. Press ENTER to use the current value of HASENVDC: + +.CAT_MARK + + echo $EO " $EC" + TMP1=`grep HASENVDC $OLD | tail $TA | egrep "^#define"` + if test "X$TMP1" != "X" + then + TMP1=`echo "$TMP1" | sed 's/^#define[ ]HASENVDC[ ]"\([^"]*\)".*$/\1/'` + echo "$TMP1" + else + echo "no current HASENVDC value" + fi + END=0 + GV=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to define a name for HASENVDC (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + ENVV="" + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + GV=1 + END=1 + else + if test "X$ANS" = "X" + then + echo "" + echo "HASENVDC will not be changed." + ENVV=$TMP1 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + fi + done + if test $GV -eq 1 + then + echo "" + echo $EO "Please enter the HASENVDC name (no quotes): $EC" + read TMP1 EXCESS + ENVV=`echo $TMP1 | sed 's/^\"//' | sed 's/\"$//'` + if test "X$ENVV" = "X" + then + ENVN=1 + fi + fi + cat << .CAT_MARK + +===================================================================== + +HASPERSDC is a format that specifies how the personal device cache +path is constructed. Consult the 00DCACHE and 00FAQ files of the +lsof distribution for information on the conversions supported in +HASPERSDC. Press ENTER to use the current HASPERSDC format: + +.CAT_MARK + + echo $EO " $EC" + TMP1=`egrep "HASPERSDC$|HASPERSDC[ ]" $OLD | tail $TA | egrep "^#define"` + if test "X$TMP1" != "X" + then + TMP1=`echo "$TMP1" | sed 's/^#define[ ]HASPERSDC[ ]"\([^"]*\)".*$/\1/'` + echo "$TMP1" + else + echo "no current HASPERSDC format" + fi + END=0 + GV=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to define a format for HASPERSDC (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + GV=1 + END=1 + else + if test "X$ANS" = "X" + then + echo "" + echo "HASPERSDC will not be changed." + PDCV=$TMP1 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + fi + done + if test $GV -eq 1 + then + echo "" + echo $EO "Please enter the HASPERSDC format (no quotes): $EC" + read TMP1 EXCESS + PDCV=`echo $TMP1 | sed 's/^\"//' | sed 's/\"$//'` + if test "X$PDCV" = "X" + then + PDCN=1 + fi + fi + cat << .CAT_MARK + +===================================================================== + +Specify for HASPERSDCPATH the name of the environment variable from +which lsof should take a path name component to insert at the %p +conversion in the HASPERSDC format. + +Consult the 00FAQ and 00DCACHE files of the lsof distribution for +more information on HASPERSDCPATH usage. + +Press ENTER to use the current value for HASPERSDCPATH: + +.CAT_MARK + + echo $EO " $EC" + TMP1=`grep HASPERSDCPATH $OLD | tail $TA | egrep "^#define"` + if test "X$TMP1" != "X" + then + TMP1=`echo "$TMP1" | sed 's/^#define[ ]HASPERSDCPATH[ ]"\([^"]*\)".*$/\1/'` + echo "$TMP1" + else + echo "no current HASPERSDCPATH value" + fi + END=0 + GV=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to change HASPERSDCPATH (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASPERSDCPATH will not be changed." + PDCPV=$TMP1 + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + GV=1 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done + if test $GV -eq 1 + then + echo "" + echo $EO "Please enter the HASPERSDCPATH name (no quotes): $EC" + read TMP1 EXCESS + PDCPV=`echo $TMP1 | sed 's/^\"//' | sed 's/\"$//'` + if test "X$PDCPV" = "X" + then + PDCPN=1 + fi + fi + cat << .CAT_MARK + +===================================================================== + +Specify for HASSYSDC the system-wide device cache file path. Press +ENTER to use the current HASSYSDC value: + +.CAT_MARK + + echo $EO " $EC" + TMP1=`grep HASSYSDC $OLD | tail $TA | egrep "^#define"` + if test "X$TMP1" != "X" + then + TMP1=`echo "$TMP1" | sed 's/^#define[ ]HASSYSDC[ ]"\([^"]*\)".*$/\1/'` + echo "$TMP1" + else + echo "no current HASSYSDC value" + fi + END=0 + GV=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to define a system-device path (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + GV=1 + END=1 + else + if test "X$ANS" = "X" + then + echo "" + echo "No HASSYSDC change will be made." + SDCV=$TMP1 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + fi + done + if test $GV -eq 1 + then + echo "" + echo $EO "Please enter the system-wide path (no quotes): $EC" + read TMP1 EXCESS + SDCV=`echo $TMP1 | sed 's/^\"//' | sed 's/\"$//'` + if test "X$SDCV" = "X" + then + SDCN=1 + fi + fi + fi +fi + +# If HASXOPT is defined, and HASXOPT_ROOT is mentioned, +# ask about changing HASXOPT_ROOT. + +HXRC=0 +grep HASXOPT $OLD | tail $TA | egrep "^#define" > /dev/null +if test $? -eq 0 +then + grep HASXOPT_ROOT $OLD > /dev/null + if test $? -eq 0 + then + cat << .CAT_MARK + +===================================================================== + +HASXOPT is defined. If the dialect for which you are customizing +appears in the following list, you may want to change the definition +of HASXOPT_ROOT to restrict the use of the X option to lsof processes +whose real user ID is root, or enable use of it by all user IDs. + + AIX the -X option enables the risky operation of letting + lsof read library entry structures with readx(). + If HASXOPT_ROOT is defined, only processes whose + real user ID is root will be allowed to use -X. + If HASXOPT_ROOT is undefined, any process will be + allowed to use -X. Consult the 00FAQ file of the + lsof distribution for more information on why + readx() may be risky. + +.CAT_MARK + + grep HASXOPT_ROOT $OLD | tail $TA | egrep "^#define" > /dev/null + if test $? -eq 0 + then + echo "HASXOPT_ROOT is defined." + HXR="undefine" + HXRS=1 + else + echo "HASXOPT_ROOT is not defined." + HXR="define" + HXRS=0 + fi + END=0 + while test $END -eq 0 + do + echo "" + echo $EO "Do you want to $HXR HASXOPT_ROOT (y|n) [n]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + HXRA=1 + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASXOPT_ROOT will not be changed." + HXRA=0 + END=1 + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done + if test $HXRA -eq 1 + then + HXRC=1 + fi + fi +fi + +# Process HASKERNIDCK. Skip processing for selected dialect directories. + +case $DialDir in + linux/proc) + NIDCK=0 + ;; + *) + cat << .CAT_MARK + +===================================================================== + +When HASKERNIDCK is enabled, lsof compares the identity of the +kernel where it was built to the identity of the kernel where it +is running. This check can detect an lsof executable inappropriate +for the system on which it is being run. + +The kernel identity check can take considerable time on some UNIX +dialects -- e.g., AIX -- so there may be occasions when it is +desirable to disable it, in spite of the increased risk of using +an inappropriate lsof executable. + +.CAT_MARK + + grep HASKERNIDCK $OLD | tail $TA | grep "^#define" > /dev/null + if test $? -eq 0 + then + echo "HASKERNIDCK is enabled." + IDCK=1 + else + echo "HASKERNIDCK is disabled." + IDCK=0 + fi + END=0 + NIDCK=$IDCK + while test $END -eq 0 + do + echo "" + if test $NIDCK -eq 1 + then + echo $EO "Disable HASKERNIDCK (y|n) [n]? $EC" + else + echo $EO "Enable HASKERNIDCK (y|n) [n]? $EC" + fi + read ANS EXCESS + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" + then + echo "" + if test $NIDCK -eq 1 + then + NIDCK=0 + echo "HASKERNIDCK will be disabled." + else + NIDCK=1 + echo "HASKERNIDCK will be enabled." + fi + END=1 + else + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" -o "X$ANS" = "X" + then + echo "" + echo "HASKERNIDCK will not be changed." + END=1 + NIDCK=$IDCK + else + echo "" + echo "Please answer y|n [n]." + fi + fi + done + ;; +esac + +# Initialize new machine.h. + +rm -f $NEW +cp $OLD $NEW +chmod 0644 $NEW +echo "" >> $NEW +echo "/*" >> $NEW +echo $EO " * Added by Customize on $EC" >> $NEW +date >> $NEW +echo " */" >> $NEW +echo "" >> $NEW + +# Change HASSECURITY and HASNOSOCKSECURITY, as required. + +echo "#undef HASSECURITY" >> $NEW +echo "#undef HASNOSOCKSECURITY" >> $NEW +if test $NSEC -eq 1 +then + echo "#define HASSECURITY 1" >> $NEW + if test $SOCKSEC -eq 1 + then + echo "#define HASNOSOCKSECURITY 1" >> $NEW + fi +fi + +# Change WARNDEVACCESS, as required. + +if test $NEVERWDA -eq 0 +then + echo "#undef WARNDEVACCESS" >> $NEW + if test $NWDA -eq 1 + then + echo "#define WARNDEVACCESS 1" >> $NEW + fi +fi + +# Change WARNINGSTATE, as required. + +echo "#undef WARNINGSTATE" >> $NEW +if test $NWST -eq 0 +then + echo "#define WARNINGSTATE 1" >> $NEW +fi + +# Change device cache definitions, as required. + +if test \( $NDC -eq 1 -a $DC -eq 0 \) -o \( $DC -eq 1 -a $CDC -eq 1 \) +then + if test "X$ENVV" = "X" -a "X$PDCV" = "X" -a "X$SDCV" = "X" + then + cat << .CAT_MARK + +FATAL: HASDCACHE is defined, but there is no definition for + any of HASENVDC, HASPERSDC, or HASSYSDC + + No new machine.h has been created. + + Customize quits. + + Restart Customize and define at least one of HASENVDC, + HASPERSDC, or HASSYSDC. + +.CAT_MARK + + rm -f $NEW + exit 1 + fi +fi +if test "X$PDCV" != "X" +then + echo "$PDCV" | grep "%p" > /dev/null + if test $? -eq 0 -a $PDCPN -eq 1 + then + cat << .CAT_MARK + +FATAL: HASDCACHE is defined and HASPERSDC has a %p conversion, + but HASPERSDCPATH is NULL. + + No new machine.h has been created. + + Customize quits. + + Restart Customize and define HASPERSDCPATH. + +.CAT_MARK + + rm -f $NEW + exit 1 + fi +fi +echo "#undef HASDCACHE" >> $NEW +if test $NEVERDC -eq 1 +then + echo "#undef HASENVDC" >> $NEW + echo "#undef HASPERSDC" >> $NEW + echo "#undef HASPERSDCPATH" >> $NEW + echo "#undef HASSYSDC" >> $NEW +else + if test $NDC -eq 1 + then + echo "#define HASDCACHE 1" >> $NEW + if test "X$ENVV" != "X" -o $ENVN -eq 1 + then + echo "#undef HASENVDC" >> $NEW + if test $ENVN -eq 0 + then + echo "#define HASENVDC \"$ENVV\"" >> $NEW + fi + fi + if test "X$PDCV" != "X" -o $PDCN -eq 1 + then + echo "#undef HASPERSDC" >> $NEW + if test $PDCN -eq 0 + then + echo "#define HASPERSDC \"$PDCV\"" >> $NEW + fi + fi + if test "X$PDCPV" != "X" -o $PDCPN -eq 1 + then + echo "#undef HASPERSDCPATH" >> $NEW + if test $PDCPN -eq 0 + then + echo "#define HASPERSDCPATH \"$PDCPV\"" >> $NEW + fi + fi + if test "X$SDCV" != "X" -o $SDCN -eq 1 + then + echo "#undef HASSYSDC" >> $NEW + if test $SDCN -eq 0 + then + echo "#define HASSYSDC \"$SDCV\"" >> $NEW + fi + fi + fi +fi + +# Change HASXOPT_ROOT, as required. + +if test $HXRC -eq 1 +then + if test $HXRS -eq 1 + then + echo "#undef HASXOPT_ROOT" >> $NEW + else + echo "#define HASXOPT_ROOT 1" >> $NEW + fi +fi + +# Change HASKERNIDCK, as required. + +echo "#undef HASKERNIDCK" >> $NEW +if test $NIDCK -eq 1 +then + echo "#define HASKERNIDCK 1" >> $NEW +fi + +# Replace the current machine.h with the new one, as requested. + +echo "" +echo "=====================================================================" +echo "" +echo "A new $OLD file has been created in \"$NEW\"." +END=0 +while test $END -eq 0 +do + echo "" + echo "Do you want to rename $OLD to ${OLD}.old and replace it with" + echo $EO "$NEW (y|n) [y]? $EC" + read ANS EXCESS + if test "X$ANS" = "Xn" -o "X$ANS" = "XN" + then + END=1 + else + if test "X$ANS" = "Xy" -o "X$ANS" = "XY" -o "X$ANS" = "X" + then + rm -f ${OLD}.old + mv $OLD ${OLD}.old + mv $NEW $OLD + END=1 + else + echo "" + echo "Please answer y|n [y]." + fi + fi +done +echo "" +echo "You may now run the make command -- e.g.," +echo "" +echo " $ make" +echo "" +exit 0 +#LAST_LINE diff --git a/Doxyfile b/Doxyfile new file mode 100644 index 0000000..8379fa0 --- /dev/null +++ b/Doxyfile @@ -0,0 +1,2733 @@ +# Doxyfile 1.9.4 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project. +# +# All text after a double hash (##) is considered a comment and is placed in +# front of the TAG it is preceding. +# +# All text after a single hash (#) is considered a comment and will be ignored. +# The format is: +# TAG = value [value, ...] +# For lists, items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (\" \"). +# +# Note: +# +# Use doxygen to compare the used configuration file with the template +# configuration file: +# doxygen -x [configFile] +# Use doxygen to compare the used configuration file with the template +# configuration file without replacing the environment variables: +# doxygen -x_noenv [configFile] + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# This tag specifies the encoding used for all characters in the configuration +# file that follow. The default is UTF-8 which is also the encoding used for all +# text before the first occurrence of this tag. Doxygen uses libiconv (or the +# iconv built into libc) for the transcoding. See +# https://www.gnu.org/software/libiconv/ for the list of possible encodings. +# The default value is: UTF-8. + +DOXYFILE_ENCODING = UTF-8 + +# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by +# double-quotes, unless you are using Doxywizard) that should identify the +# project for which the documentation is generated. This name is used in the +# title of most generated pages and in a few other places. +# The default value is: My Project. + +PROJECT_NAME = "lsof: LiSt Open Files" + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. This +# could be handy for archiving the generated documentation or if some version +# control system is used. + +PROJECT_NUMBER = + +# Using the PROJECT_BRIEF tag one can provide an optional one line description +# for a project that appears at the top of each page and should give viewer a +# quick idea about the purpose of the project. Keep the description short. + +PROJECT_BRIEF = + +# With the PROJECT_LOGO tag one can specify a logo or an icon that is included +# in the documentation. The maximum height of the logo should not exceed 55 +# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy +# the logo to the output directory. + +PROJECT_LOGO = + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path +# into which the generated documentation will be written. If a relative path is +# entered, it will be relative to the location where doxygen was started. If +# left blank the current directory will be used. + +OUTPUT_DIRECTORY = output + +# If the CREATE_SUBDIRS tag is set to YES then doxygen will create up to 4096 +# sub-directories (in 2 levels) under the output directory of each output format +# and will distribute the generated files over these directories. Enabling this +# option can be useful when feeding doxygen a huge amount of source files, where +# putting all generated files in the same directory would otherwise causes +# performance problems for the file system. Adapt CREATE_SUBDIRS_LEVEL to +# control the number of sub-directories. +# The default value is: NO. + +CREATE_SUBDIRS = NO + +# Controls the number of sub-directories that will be created when +# CREATE_SUBDIRS tag is set to YES. Level 0 represents 16 directories, and every +# level increment doubles the number of directories, resulting in 4096 +# directories at level 8 which is the default and also the maximum value. The +# sub-directories are organized in 2 levels, the first level always has a fixed +# number of 16 directories. +# Minimum value: 0, maximum value: 8, default value: 8. +# This tag requires that the tag CREATE_SUBDIRS is set to YES. + +CREATE_SUBDIRS_LEVEL = 8 + +# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII +# characters to appear in the names of generated files. If set to NO, non-ASCII +# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode +# U+3044. +# The default value is: NO. + +ALLOW_UNICODE_NAMES = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Bulgarian, +# Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, English +# (United States), Esperanto, Farsi (Persian), Finnish, French, German, Greek, +# Hindi, Hungarian, Indonesian, Italian, Japanese, Japanese-en (Japanese with +# English messages), Korean, Korean-en (Korean with English messages), Latvian, +# Lithuanian, Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, +# Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, +# Swedish, Turkish, Ukrainian and Vietnamese. +# The default value is: English. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member +# descriptions after the members that are listed in the file and class +# documentation (similar to Javadoc). Set to NO to disable this. +# The default value is: YES. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief +# description of a member or function before the detailed description +# +# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. +# The default value is: YES. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator that is +# used to form the text in various listings. Each string in this list, if found +# as the leading text of the brief description, will be stripped from the text +# and the result, after processing the whole list, is used as the annotated +# text. Otherwise, the brief description is used as-is. If left blank, the +# following values are used ($name is automatically replaced with the name of +# the entity):The $name class, The $name widget, The $name file, is, provides, +# specifies, contains, represents, a, an and the. + +ABBREVIATE_BRIEF = "The $name class" \ + "The $name widget" \ + "The $name file" \ + is \ + provides \ + specifies \ + contains \ + represents \ + a \ + an \ + the + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# doxygen will generate a detailed section even if there is only a brief +# description. +# The default value is: NO. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. +# The default value is: NO. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path +# before files name in the file list and in the header files. If set to NO the +# shortest path that makes the file name unique will be used +# The default value is: YES. + +FULL_PATH_NAMES = YES + +# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. +# Stripping is only done if one of the specified strings matches the left-hand +# part of the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the path to +# strip. +# +# Note that you can specify absolute paths here, but also relative paths, which +# will be relative from the directory where doxygen is started. +# This tag requires that the tag FULL_PATH_NAMES is set to YES. + +STRIP_FROM_PATH = + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the +# path mentioned in the documentation of a class, which tells the reader which +# header file to include in order to use a class. If left blank only the name of +# the header file containing the class definition is used. Otherwise one should +# specify the list of include paths that are normally passed to the compiler +# using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but +# less readable) file names. This can be useful is your file systems doesn't +# support long names like on DOS, Mac, or CD-ROM. +# The default value is: NO. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the +# first line (until the first dot) of a Javadoc-style comment as the brief +# description. If set to NO, the Javadoc-style will behave just like regular Qt- +# style comments (thus requiring an explicit @brief command for a brief +# description.) +# The default value is: NO. + +JAVADOC_AUTOBRIEF = YES + +# If the JAVADOC_BANNER tag is set to YES then doxygen will interpret a line +# such as +# /*************** +# as being the beginning of a Javadoc-style comment "banner". If set to NO, the +# Javadoc-style will behave just like regular comments and it will not be +# interpreted by doxygen. +# The default value is: NO. + +JAVADOC_BANNER = NO + +# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first +# line (until the first dot) of a Qt-style comment as the brief description. If +# set to NO, the Qt-style will behave just like regular Qt-style comments (thus +# requiring an explicit \brief command for a brief description.) +# The default value is: NO. + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a +# multi-line C++ special comment block (i.e. a block of //! or /// comments) as +# a brief description. This used to be the default behavior. The new default is +# to treat a multi-line C++ comment block as a detailed description. Set this +# tag to YES if you prefer the old behavior instead. +# +# Note that setting this tag to YES also means that rational rose comments are +# not recognized any more. +# The default value is: NO. + +MULTILINE_CPP_IS_BRIEF = NO + +# By default Python docstrings are displayed as preformatted text and doxygen's +# special commands cannot be used. By setting PYTHON_DOCSTRING to NO the +# doxygen's special commands can be used and the contents of the docstring +# documentation blocks is shown as doxygen documentation. +# The default value is: YES. + +PYTHON_DOCSTRING = YES + +# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the +# documentation from any documented member that it re-implements. +# The default value is: YES. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new +# page for each member. If set to NO, the documentation of a member will be part +# of the file/class/namespace that contains it. +# The default value is: NO. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen +# uses this value to replace tabs by spaces in code fragments. +# Minimum value: 1, maximum value: 16, default value: 4. + +TAB_SIZE = 4 + +# This tag can be used to specify a number of aliases that act as commands in +# the documentation. An alias has the form: +# name=value +# For example adding +# "sideeffect=@par Side Effects:^^" +# will allow you to put the command \sideeffect (or @sideeffect) in the +# documentation, which will result in a user-defined paragraph with heading +# "Side Effects:". Note that you cannot put \n's in the value part of an alias +# to insert newlines (in the resulting output). You can put ^^ in the value part +# of an alias to insert a newline as if a physical newline was in the original +# file. When you need a literal { or } or , in the value part of an alias you +# have to escape them by means of a backslash (\), this can lead to conflicts +# with the commands \{ and \} for these it is advised to use the version @{ and +# @} or use a double escape (\\{ and \\}) + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources +# only. Doxygen will then generate output that is more tailored for C. For +# instance, some of the names that are used will be different. The list of all +# members will be omitted, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_FOR_C = NO + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or +# Python sources only. Doxygen will then generate output that is more tailored +# for that language. For instance, namespaces will be presented as packages, +# qualified scopes will look different, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources. Doxygen will then generate output that is tailored for Fortran. +# The default value is: NO. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for VHDL. +# The default value is: NO. + +OPTIMIZE_OUTPUT_VHDL = NO + +# Set the OPTIMIZE_OUTPUT_SLICE tag to YES if your project consists of Slice +# sources only. Doxygen will then generate output that is more tailored for that +# language. For instance, namespaces will be presented as modules, types will be +# separated into more groups, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_SLICE = NO + +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, and +# language is one of the parsers supported by doxygen: IDL, Java, JavaScript, +# Csharp (C#), C, C++, Lex, D, PHP, md (Markdown), Objective-C, Python, Slice, +# VHDL, Fortran (fixed format Fortran: FortranFixed, free formatted Fortran: +# FortranFree, unknown formatted Fortran: Fortran. In the later case the parser +# tries to guess whether the code is fixed or free formatted code, this is the +# default for Fortran type files). For instance to make doxygen treat .inc files +# as Fortran files (default is PHP), and .f files as C (default is Fortran), +# use: inc=Fortran f=C. +# +# Note: For files without extension you can use no_extension as a placeholder. +# +# Note that for custom extensions you also need to set FILE_PATTERNS otherwise +# the files are not read by doxygen. When specifying no_extension you should add +# * to the FILE_PATTERNS. +# +# Note see also the list of default file extension mappings. + +EXTENSION_MAPPING = + +# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments +# according to the Markdown format, which allows for more readable +# documentation. See https://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by doxygen, so you can +# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in +# case of backward compatibilities issues. +# The default value is: YES. + +MARKDOWN_SUPPORT = YES + +# When the TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings up +# to that level are automatically included in the table of contents, even if +# they do not have an id attribute. +# Note: This feature currently applies only to Markdown headings. +# Minimum value: 0, maximum value: 99, default value: 5. +# This tag requires that the tag MARKDOWN_SUPPORT is set to YES. + +TOC_INCLUDE_HEADINGS = 5 + +# When enabled doxygen tries to link words that correspond to documented +# classes, or namespaces to their corresponding documentation. Such a link can +# be prevented in individual cases by putting a % sign in front of the word or +# globally by setting AUTOLINK_SUPPORT to NO. +# The default value is: YES. + +AUTOLINK_SUPPORT = YES + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want +# to include (a tag file for) the STL sources as input, then you should set this +# tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); +# versus func(std::string) {}). This also make the inheritance and collaboration +# diagrams that involve STL classes more complete and accurate. +# The default value is: NO. + +BUILTIN_STL_SUPPORT = NO + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. +# The default value is: NO. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip (see: +# https://www.riverbankcomputing.com/software/sip/intro) sources only. Doxygen +# will parse them like normal C++ but will assume all classes use public instead +# of private inheritance when no explicit protection keyword is present. +# The default value is: NO. + +SIP_SUPPORT = NO + +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to YES will make +# doxygen to replace the get and set methods by a property in the documentation. +# This will only work if the methods are indeed getting or setting a simple +# type. If this is not the case, or you want to show the methods anyway, you +# should set this option to NO. +# The default value is: YES. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. +# The default value is: NO. + +DISTRIBUTE_GROUP_DOC = NO + +# If one adds a struct or class to a group and this option is enabled, then also +# any nested class or struct is added to the same group. By default this option +# is disabled and one has to add nested compounds explicitly via \ingroup. +# The default value is: NO. + +GROUP_NESTED_COMPOUNDS = NO + +# Set the SUBGROUPING tag to YES to allow class member groups of the same type +# (for instance a group of public functions) to be put as a subgroup of that +# type (e.g. under the Public Functions section). Set it to NO to prevent +# subgrouping. Alternatively, this can be done per class using the +# \nosubgrouping command. +# The default value is: YES. + +SUBGROUPING = YES + +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions +# are shown inside the group in which they are included (e.g. using \ingroup) +# instead of on a separate page (for HTML and Man pages) or section (for LaTeX +# and RTF). +# +# Note that this feature does not work in combination with +# SEPARATE_MEMBER_PAGES. +# The default value is: NO. + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions +# with only public data fields or simple typedef fields will be shown inline in +# the documentation of the scope in which they are defined (i.e. file, +# namespace, or group documentation), provided this scope is documented. If set +# to NO, structs, classes, and unions are shown on a separate page (for HTML and +# Man pages) or section (for LaTeX and RTF). +# The default value is: NO. + +INLINE_SIMPLE_STRUCTS = NO + +# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or +# enum is documented as struct, union, or enum with the name of the typedef. So +# typedef struct TypeS {} TypeT, will appear in the documentation as a struct +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named TypeS. This can typically be +# useful for C code in case the coding convention dictates that all compound +# types are typedef'ed and only the typedef is referenced, never the tag name. +# The default value is: NO. + +TYPEDEF_HIDES_STRUCT = NO + +# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This +# cache is used to resolve symbols given their name and scope. Since this can be +# an expensive process and often the same symbol appears multiple times in the +# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small +# doxygen will become slower. If the cache is too large, memory is wasted. The +# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range +# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 +# symbols. At the end of a run doxygen will report the cache usage and suggest +# the optimal cache size from a speed point of view. +# Minimum value: 0, maximum value: 9, default value: 0. + +LOOKUP_CACHE_SIZE = 0 + +# The NUM_PROC_THREADS specifies the number of threads doxygen is allowed to use +# during processing. When set to 0 doxygen will based this on the number of +# cores available in the system. You can set it explicitly to a value larger +# than 0 to get more control over the balance between CPU load and processing +# speed. At this moment only the input processing can be done using multiple +# threads. Since this is still an experimental feature the default is set to 1, +# which effectively disables parallel processing. Please report any issues you +# encounter. Generating dot graphs in parallel is controlled by the +# DOT_NUM_THREADS setting. +# Minimum value: 0, maximum value: 32, default value: 1. + +NUM_PROC_THREADS = 1 + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in +# documentation are documented, even if no documentation was available. Private +# class members and static file members will be hidden unless the +# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. +# Note: This will also disable the warnings about undocumented members that are +# normally produced when WARNINGS is set to YES. +# The default value is: NO. + +EXTRACT_ALL = NO + +# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will +# be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual +# methods of a class will be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIV_VIRTUAL = NO + +# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal +# scope will be included in the documentation. +# The default value is: NO. + +EXTRACT_PACKAGE = NO + +# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be +# included in the documentation. +# The default value is: NO. + +EXTRACT_STATIC = NO + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined +# locally in source files will be included in the documentation. If set to NO, +# only classes defined in header files are included. Does not have any effect +# for Java sources. +# The default value is: YES. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. If set to YES, local methods, +# which are defined in the implementation section but not in the interface are +# included in the documentation. If set to NO, only methods in the interface are +# included. +# The default value is: NO. + +EXTRACT_LOCAL_METHODS = NO + +# If this flag is set to YES, the members of anonymous namespaces will be +# extracted and appear in the documentation as a namespace called +# 'anonymous_namespace{file}', where file will be replaced with the base name of +# the file that contains the anonymous namespace. By default anonymous namespace +# are hidden. +# The default value is: NO. + +EXTRACT_ANON_NSPACES = NO + +# If this flag is set to YES, the name of an unnamed parameter in a declaration +# will be determined by the corresponding definition. By default unnamed +# parameters remain unnamed in the output. +# The default value is: YES. + +RESOLVE_UNNAMED_PARAMS = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all +# undocumented members inside documented classes or files. If set to NO these +# members will be included in the various overviews, but no documentation +# section is generated. This option has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. If set +# to NO, these classes will be included in the various overviews. This option +# has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend +# declarations. If set to NO, these declarations will be included in the +# documentation. +# The default value is: NO. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any +# documentation blocks found inside the body of a function. If set to NO, these +# blocks will be appended to the function's detailed documentation block. +# The default value is: NO. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation that is typed after a +# \internal command is included. If the tag is set to NO then the documentation +# will be excluded. Set it to YES to include the internal documentation. +# The default value is: NO. + +INTERNAL_DOCS = NO + +# With the correct setting of option CASE_SENSE_NAMES doxygen will better be +# able to match the capabilities of the underlying filesystem. In case the +# filesystem is case sensitive (i.e. it supports files in the same directory +# whose names only differ in casing), the option must be set to YES to properly +# deal with such files in case they appear in the input. For filesystems that +# are not case sensitive the option should be set to NO to properly deal with +# output files written for symbols that only differ in casing, such as for two +# classes, one named CLASS and the other named Class, and to also support +# references to files without having to specify the exact matching casing. On +# Windows (including Cygwin) and MacOS, users should typically set this option +# to NO, whereas on Linux or other Unix flavors it should typically be set to +# YES. +# The default value is: system dependent. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with +# their full class and namespace scopes in the documentation. If set to YES, the +# scope will be hidden. +# The default value is: NO. + +HIDE_SCOPE_NAMES = NO + +# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will +# append additional text to a page's title, such as Class Reference. If set to +# YES the compound reference will be hidden. +# The default value is: NO. + +HIDE_COMPOUND_REFERENCE= NO + +# If the SHOW_HEADERFILE tag is set to YES then the documentation for a class +# will show which file needs to be included to use the class. +# The default value is: YES. + +SHOW_HEADERFILE = YES + +# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of +# the files that are included by a file in the documentation of that file. +# The default value is: YES. + +SHOW_INCLUDE_FILES = YES + +# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each +# grouped member an include statement to the documentation, telling the reader +# which file to include in order to use the member. +# The default value is: NO. + +SHOW_GROUPED_MEMB_INC = NO + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include +# files with double quotes in the documentation rather than with sharp brackets. +# The default value is: NO. + +FORCE_LOCAL_INCLUDES = NO + +# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the +# documentation for inline members. +# The default value is: YES. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the +# (detailed) documentation of file and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. +# The default value is: YES. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief +# descriptions of file, namespace and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. Note that +# this will also influence the order of the classes in the class list. +# The default value is: NO. + +SORT_BRIEF_DOCS = NO + +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the +# (brief and detailed) documentation of class members so that constructors and +# destructors are listed first. If set to NO the constructors will appear in the +# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. +# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief +# member documentation. +# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting +# detailed member documentation. +# The default value is: NO. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy +# of group names into alphabetical order. If set to NO the group names will +# appear in their defined order. +# The default value is: NO. + +SORT_GROUP_NAMES = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by +# fully-qualified names, including namespaces. If set to NO, the class list will +# be sorted only by class name, not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the alphabetical +# list. +# The default value is: NO. + +SORT_BY_SCOPE_NAME = NO + +# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper +# type resolution of all parameters of a function it will reject a match between +# the prototype and the implementation of a member function even if there is +# only one candidate or it is obvious which candidate to choose by doing a +# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still +# accept a match between prototype and implementation in such cases. +# The default value is: NO. + +STRICT_PROTO_MATCHING = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo +# list. This list is created by putting \todo commands in the documentation. +# The default value is: YES. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test +# list. This list is created by putting \test commands in the documentation. +# The default value is: YES. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug +# list. This list is created by putting \bug commands in the documentation. +# The default value is: YES. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) +# the deprecated list. This list is created by putting \deprecated commands in +# the documentation. +# The default value is: YES. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional documentation +# sections, marked by \if ... \endif and \cond +# ... \endcond blocks. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the +# initial value of a variable or macro / define can have for it to appear in the +# documentation. If the initializer consists of more lines than specified here +# it will be hidden. Use a value of 0 to hide initializers completely. The +# appearance of the value of individual variables and macros / defines can be +# controlled using \showinitializer or \hideinitializer command in the +# documentation regardless of this setting. +# Minimum value: 0, maximum value: 10000, default value: 30. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at +# the bottom of the documentation of classes and structs. If set to YES, the +# list will mention the files that were used to generate the documentation. +# The default value is: YES. + +SHOW_USED_FILES = YES + +# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This +# will remove the Files entry from the Quick Index and from the Folder Tree View +# (if specified). +# The default value is: YES. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces +# page. This will remove the Namespaces entry from the Quick Index and from the +# Folder Tree View (if specified). +# The default value is: YES. + +SHOW_NAMESPACES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from +# the version control system). Doxygen will invoke the program by executing (via +# popen()) the command command input-file, where command is the value of the +# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided +# by doxygen. Whatever the program writes to standard output is used as the file +# version. For an example see the documentation. + +FILE_VERSION_FILTER = + +# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed +# by doxygen. The layout file controls the global structure of the generated +# output files in an output format independent way. To create the layout file +# that represents doxygen's defaults, run doxygen with the -l option. You can +# optionally specify a file name after the option, if omitted DoxygenLayout.xml +# will be used as the name of the layout file. See also section "Changing the +# layout of pages" for information. +# +# Note that if you run doxygen from a directory containing a file called +# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE +# tag is left empty. + +LAYOUT_FILE = + +# The CITE_BIB_FILES tag can be used to specify one or more bib files containing +# the reference definitions. This must be a list of .bib files. The .bib +# extension is automatically appended if omitted. This requires the bibtex tool +# to be installed. See also https://en.wikipedia.org/wiki/BibTeX for more info. +# For LaTeX the style of the bibliography can be controlled using +# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the +# search path. See also \cite for info how to create references. + +CITE_BIB_FILES = + +#--------------------------------------------------------------------------- +# Configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated to +# standard output by doxygen. If QUIET is set to YES this implies that the +# messages are off. +# The default value is: NO. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES +# this implies that the warnings are on. +# +# Tip: Turn warnings on while writing the documentation. +# The default value is: YES. + +WARNINGS = YES + +# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate +# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: YES. + +WARN_IF_UNDOCUMENTED = YES + +# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as documenting some parameters in +# a documented function twice, or documenting parameters that don't exist or +# using markup commands wrongly. +# The default value is: YES. + +WARN_IF_DOC_ERROR = YES + +# If WARN_IF_INCOMPLETE_DOC is set to YES, doxygen will warn about incomplete +# function parameter documentation. If set to NO, doxygen will accept that some +# parameters have no documentation without warning. +# The default value is: YES. + +WARN_IF_INCOMPLETE_DOC = YES + +# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that +# are documented, but have no documentation for their parameters or return +# value. If set to NO, doxygen will only warn about wrong parameter +# documentation, but not about the absence of documentation. If EXTRACT_ALL is +# set to YES then this flag will automatically be disabled. See also +# WARN_IF_INCOMPLETE_DOC +# The default value is: NO. + +WARN_NO_PARAMDOC = NO + +# If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when +# a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS +# then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but +# at the end of the doxygen process doxygen will return with a non-zero status. +# Possible values are: NO, YES and FAIL_ON_WARNINGS. +# The default value is: NO. + +WARN_AS_ERROR = NO + +# The WARN_FORMAT tag determines the format of the warning messages that doxygen +# can produce. The string should contain the $file, $line, and $text tags, which +# will be replaced by the file and line number from which the warning originated +# and the warning text. Optionally the format may contain $version, which will +# be replaced by the version of the file (if it could be obtained via +# FILE_VERSION_FILTER) +# See also: WARN_LINE_FORMAT +# The default value is: $file:$line: $text. + +WARN_FORMAT = "$file:$line: $text" + +# In the $text part of the WARN_FORMAT command it is possible that a reference +# to a more specific place is given. To make it easier to jump to this place +# (outside of doxygen) the user can define a custom "cut" / "paste" string. +# Example: +# WARN_LINE_FORMAT = "'vi $file +$line'" +# See also: WARN_FORMAT +# The default value is: at line $line of file $file. + +WARN_LINE_FORMAT = "at line $line of file $file" + +# The WARN_LOGFILE tag can be used to specify a file to which warning and error +# messages should be written. If left blank the output is written to standard +# error (stderr). In case the file specified cannot be opened for writing the +# warning and error messages are written to standard error. When as file - is +# specified the warning and error messages are written to standard output +# (stdout). + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# Configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag is used to specify the files and/or directories that contain +# documented source files. You may enter file names like myfile.cpp or +# directories like /usr/src/myproject. Separate the files or directories with +# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING +# Note: If this tag is empty the current directory is searched. + +INPUT = include + +# This tag can be used to specify the character encoding of the source files +# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses +# libiconv (or the iconv built into libc) for the transcoding. See the libiconv +# documentation (see: +# https://www.gnu.org/software/libiconv/) for the list of possible encodings. +# The default value is: UTF-8. + +INPUT_ENCODING = UTF-8 + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and +# *.h) to filter out the source-files in the directories. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# read by doxygen. +# +# Note the list of default checked file patterns might differ from the list of +# default file extension mappings. +# +# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp, +# *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, +# *.hh, *.hxx, *.hpp, *.h++, *.l, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, +# *.inc, *.m, *.markdown, *.md, *.mm, *.dox (to be provided as doxygen C +# comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f18, *.f, *.for, *.vhd, +# *.vhdl, *.ucf, *.qsf and *.ice. + +FILE_PATTERNS = *.c \ + *.cc \ + *.cxx \ + *.cpp \ + *.c++ \ + *.java \ + *.ii \ + *.ixx \ + *.ipp \ + *.i++ \ + *.inl \ + *.idl \ + *.ddl \ + *.odl \ + *.h \ + *.hh \ + *.hxx \ + *.hpp \ + *.h++ \ + *.l \ + *.cs \ + *.d \ + *.php \ + *.php4 \ + *.php5 \ + *.phtml \ + *.inc \ + *.m \ + *.markdown \ + *.md \ + *.mm \ + *.dox \ + *.py \ + *.pyw \ + *.f90 \ + *.f95 \ + *.f03 \ + *.f08 \ + *.f18 \ + *.f \ + *.for \ + *.vhd \ + *.vhdl \ + *.ucf \ + *.qsf \ + *.ice + +# The RECURSIVE tag can be used to specify whether or not subdirectories should +# be searched for input files as well. +# The default value is: NO. + +RECURSIVE = NO + +# The EXCLUDE tag can be used to specify files and/or directories that should be +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. +# +# Note that relative paths are relative to the directory from which doxygen is +# run. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or +# directories that are symbolic links (a Unix file system feature) are excluded +# from the input. +# The default value is: NO. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories for example use the pattern */test/* + +EXCLUDE_PATTERNS = + +# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names +# (namespaces, classes, functions, etc.) that should be excluded from the +# output. The symbol name can be a fully qualified name, a word, or if the +# wildcard * is used, a substring. Examples: ANamespace, AClass, +# ANamespace::AClass, ANamespace::*Test +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories use the pattern */test/* + +EXCLUDE_SYMBOLS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or directories +# that contain example code fragments that are included (see the \include +# command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and +# *.h) to filter out the source-files in the directories. If left blank all +# files are included. + +EXAMPLE_PATTERNS = * + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude commands +# irrespective of the value of the RECURSIVE tag. +# The default value is: NO. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or directories +# that contain images that are to be included in the documentation (see the +# \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command: +# +# +# +# where is the value of the INPUT_FILTER tag, and is the +# name of an input file. Doxygen will then use the output that the filter +# program writes to standard output. If FILTER_PATTERNS is specified, this tag +# will be ignored. +# +# Note that the filter must not add or remove lines; it is applied before the +# code is scanned, but not when the output code is generated. If lines are added +# or removed, the anchors will not be placed correctly. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: pattern=filter +# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how +# filters are used. If the FILTER_PATTERNS tag is empty or if none of the +# patterns match the file name, INPUT_FILTER is applied. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will also be used to filter the input files that are used for +# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). +# The default value is: NO. + +FILTER_SOURCE_FILES = NO + +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and +# it is also possible to disable source filtering for a specific pattern using +# *.ext= (so without naming a filter). +# This tag requires that the tag FILTER_SOURCE_FILES is set to YES. + +FILTER_SOURCE_PATTERNS = + +# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that +# is part of the input, its contents will be placed on the main page +# (index.html). This can be useful if you have a project on for instance GitHub +# and want to reuse the introduction page also for the doxygen output. + +USE_MDFILE_AS_MAINPAGE = + +#--------------------------------------------------------------------------- +# Configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will be +# generated. Documented entities will be cross-referenced with these sources. +# +# Note: To get rid of all source code in the generated output, make sure that +# also VERBATIM_HEADERS is set to NO. +# The default value is: NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body of functions, +# classes and enums directly into the documentation. +# The default value is: NO. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any +# special comment blocks from generated source code fragments. Normal C, C++ and +# Fortran comments will always remain visible. +# The default value is: YES. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES then for each documented +# entity all documented functions referencing it will be listed. +# The default value is: NO. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES then for each documented function +# all documented entities called/used by that function will be listed. +# The default value is: NO. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set +# to YES then the hyperlinks from functions in REFERENCES_RELATION and +# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will +# link to the documentation. +# The default value is: YES. + +REFERENCES_LINK_SOURCE = YES + +# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the +# source code will show a tooltip with additional information such as prototype, +# brief description and links to the definition and documentation. Since this +# will make the HTML file larger and loading of large files a bit slower, you +# can opt to disable this feature. +# The default value is: YES. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +SOURCE_TOOLTIPS = YES + +# If the USE_HTAGS tag is set to YES then the references to source code will +# point to the HTML generated by the htags(1) tool instead of doxygen built-in +# source browser. The htags tool is part of GNU's global source tagging system +# (see https://www.gnu.org/software/global/global.html). You will need version +# 4.8.6 or higher. +# +# To use it do the following: +# - Install the latest version of global +# - Enable SOURCE_BROWSER and USE_HTAGS in the configuration file +# - Make sure the INPUT points to the root of the source tree +# - Run doxygen as normal +# +# Doxygen will invoke htags (and that will in turn invoke gtags), so these +# tools must be available from the command line (i.e. in the search path). +# +# The result: instead of the source browser generated by doxygen, the links to +# source code will now point to the output of htags. +# The default value is: NO. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a +# verbatim copy of the header file for each class for which an include is +# specified. Set to NO to disable this. +# See also: Section \class. +# The default value is: YES. + +VERBATIM_HEADERS = YES + +# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the +# clang parser (see: +# http://clang.llvm.org/) for more accurate parsing at the cost of reduced +# performance. This can be particularly helpful with template rich C++ code for +# which doxygen's built-in parser lacks the necessary type information. +# Note: The availability of this option depends on whether or not doxygen was +# generated with the -Duse_libclang=ON option for CMake. +# The default value is: NO. + +CLANG_ASSISTED_PARSING = NO + +# If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_INC_PATHS +# tag is set to YES then doxygen will add the directory of each input to the +# include path. +# The default value is: YES. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_ADD_INC_PATHS = YES + +# If clang assisted parsing is enabled you can provide the compiler with command +# line options that you would normally use when invoking the compiler. Note that +# the include paths will already be set by doxygen for the files and directories +# specified with INPUT and INCLUDE_PATH. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_OPTIONS = + +# If clang assisted parsing is enabled you can provide the clang parser with the +# path to the directory containing a file called compile_commands.json. This +# file is the compilation database (see: +# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) containing the +# options used when the source files were built. This is equivalent to +# specifying the -p option to a clang tool, such as clang-check. These options +# will then be passed to the parser. Any options specified with CLANG_OPTIONS +# will be added as well. +# Note: The availability of this option depends on whether or not doxygen was +# generated with the -Duse_libclang=ON option for CMake. + +CLANG_DATABASE_PATH = + +#--------------------------------------------------------------------------- +# Configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all +# compounds will be generated. Enable this if the project contains a lot of +# classes, structs, unions or interfaces. +# The default value is: YES. + +ALPHABETICAL_INDEX = YES + +# In case all classes in a project start with a common prefix, all classes will +# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag +# can be used to specify a prefix (or a list of prefixes) that should be ignored +# while generating the index headers. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output +# The default value is: YES. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a +# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of +# it. +# The default directory is: html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each +# generated HTML page (for example: .htm, .php, .asp). +# The default value is: .html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a user-defined HTML header file for +# each generated HTML page. If the tag is left blank doxygen will generate a +# standard header. +# +# To get valid HTML the header file that includes any scripts and style sheets +# that doxygen needs, which is dependent on the configuration options used (e.g. +# the setting GENERATE_TREEVIEW). It is highly recommended to start with a +# default header using +# doxygen -w html new_header.html new_footer.html new_stylesheet.css +# YourConfigFile +# and then modify the file new_header.html. See also section "Doxygen usage" +# for information on how to generate the default header that doxygen normally +# uses. +# Note: The header is subject to change so you typically have to regenerate the +# default header when upgrading to a newer version of doxygen. For a description +# of the possible markers and block names see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each +# generated HTML page. If the tag is left blank doxygen will generate a standard +# footer. See HTML_HEADER for more information on how to generate a default +# footer and what special commands can be used inside the footer. See also +# section "Doxygen usage" for information on how to generate the default footer +# that doxygen normally uses. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style +# sheet that is used by each HTML page. It can be used to fine-tune the look of +# the HTML output. If left blank doxygen will generate a default style sheet. +# See also section "Doxygen usage" for information on how to generate the style +# sheet that doxygen normally uses. +# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as +# it is more robust and this tag (HTML_STYLESHEET) will in the future become +# obsolete. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_STYLESHEET = + +# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined +# cascading style sheets that are included after the standard style sheets +# created by doxygen. Using this option one can overrule certain style aspects. +# This is preferred over using HTML_STYLESHEET since it does not replace the +# standard style sheet and is therefore more robust against future updates. +# Doxygen will copy the style sheet files to the output directory. +# Note: The order of the extra style sheet files is of importance (e.g. the last +# style sheet in the list overrules the setting of the previous ones in the +# list). For an example see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_STYLESHEET = + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that the +# files will be copied as-is; there are no commands or markers available. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_FILES = + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen +# will adjust the colors in the style sheet and background images according to +# this color. Hue is specified as an angle on a color-wheel, see +# https://en.wikipedia.org/wiki/Hue for more information. For instance the value +# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 +# purple, and 360 is red again. +# Minimum value: 0, maximum value: 359, default value: 220. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_HUE = 220 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors +# in the HTML output. For a value of 0 the output will use gray-scales only. A +# value of 255 will produce the most vivid colors. +# Minimum value: 0, maximum value: 255, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_SAT = 100 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the +# luminance component of the colors in the HTML output. Values below 100 +# gradually make the output lighter, whereas values above 100 make the output +# darker. The value divided by 100 is the actual gamma applied, so 80 represents +# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not +# change the gamma. +# Minimum value: 40, maximum value: 240, default value: 80. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_GAMMA = 80 + +# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML +# page will contain the date and time when the page was generated. Setting this +# to YES can help to show when doxygen was last run and thus if the +# documentation is up to date. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_TIMESTAMP = NO + +# If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML +# documentation will contain a main index with vertical navigation menus that +# are dynamically created via JavaScript. If disabled, the navigation index will +# consists of multiple levels of tabs that are statically embedded in every HTML +# page. Disable this option to support browsers that do not have JavaScript, +# like the Qt help browser. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_MENUS = YES + +# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML +# documentation will contain sections that can be hidden and shown after the +# page has loaded. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_SECTIONS = NO + +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries +# shown in the various tree structured indices initially; the user can expand +# and collapse entries dynamically later on. Doxygen will expand the tree to +# such a level that at most the specified number of entries are visible (unless +# a fully collapsed tree already exceeds this amount). So setting the number of +# entries 1 will produce a full collapsed tree by default. 0 is a special value +# representing an infinite number of entries and will result in a full expanded +# tree by default. +# Minimum value: 0, maximum value: 9999, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_INDEX_NUM_ENTRIES = 100 + +# If the GENERATE_DOCSET tag is set to YES, additional index files will be +# generated that can be used as input for Apple's Xcode 3 integrated development +# environment (see: +# https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To +# create a documentation set, doxygen will generate a Makefile in the HTML +# output directory. Running make will produce the docset in that directory and +# running make install will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at +# startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy +# genXcode/_index.html for more information. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_DOCSET = NO + +# This tag determines the name of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# The default value is: Doxygen generated docs. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# This tag determines the URL of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDURL = + +# This tag specifies a string that should uniquely identify the documentation +# set bundle. This should be a reverse domain-name style string, e.g. +# com.mycompany.MyDocSet. Doxygen will append .docset to the name. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify +# the documentation publisher. This should be a reverse domain-name style +# string, e.g. com.mycompany.MyDocSet.documentation. +# The default value is: org.doxygen.Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. +# The default value is: Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_NAME = Publisher + +# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three +# additional HTML index files: index.hhp, index.hhc, and index.hhk. The +# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop +# on Windows. In the beginning of 2021 Microsoft took the original page, with +# a.o. the download links, offline the HTML help workshop was already many years +# in maintenance mode). You can download the HTML help workshop from the web +# archives at Installation executable (see: +# http://web.archive.org/web/20160201063255/http://download.microsoft.com/downlo +# ad/0/A/9/0A939EF6-E31C-430F-A3DF-DFAE7960D564/htmlhelp.exe). +# +# The HTML Help Workshop contains a compiler that can convert all HTML output +# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML +# files are now used as the Windows 98 help format, and will replace the old +# Windows help format (.hlp) on all Windows platforms in the future. Compressed +# HTML files also contain an index, a table of contents, and you can search for +# words in the documentation. The HTML workshop also contains a viewer for +# compressed HTML files. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_HTMLHELP = NO + +# The CHM_FILE tag can be used to specify the file name of the resulting .chm +# file. You can add a path in front of the file if the result should not be +# written to the html output directory. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_FILE = + +# The HHC_LOCATION tag can be used to specify the location (absolute path +# including file name) of the HTML help compiler (hhc.exe). If non-empty, +# doxygen will try to run the HTML help compiler on the generated index.hhp. +# The file has to be specified with full path. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +HHC_LOCATION = + +# The GENERATE_CHI flag controls if a separate .chi index file is generated +# (YES) or that it should be included in the main .chm file (NO). +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +GENERATE_CHI = NO + +# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) +# and project file content. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_INDEX_ENCODING = + +# The BINARY_TOC flag controls whether a binary table of contents is generated +# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it +# enables the Previous and Next buttons. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members to +# the table of contents of the HTML help documentation and to the tree view. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +TOC_EXPAND = NO + +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that +# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help +# (.qch) of the generated HTML documentation. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify +# the file name of the resulting .qch file. The path specified is relative to +# the HTML output folder. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help +# Project output. For more information please see Qt Help Project / Namespace +# (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace). +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_NAMESPACE = org.doxygen.Project + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt +# Help Project output. For more information please see Qt Help Project / Virtual +# Folders (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders). +# The default value is: doc. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_VIRTUAL_FOLDER = doc + +# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom +# filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_NAME = + +# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_ATTRS = + +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's filter section matches. Qt Help Project / Filter Attributes (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#filter-attributes). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_SECT_FILTER_ATTRS = + +# The QHG_LOCATION tag can be used to specify the location (absolute path +# including file name) of Qt's qhelpgenerator. If non-empty doxygen will try to +# run qhelpgenerator on the generated .qhp file. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHG_LOCATION = + +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be +# generated, together with the HTML files, they form an Eclipse help plugin. To +# install this plugin and make it available under the help contents menu in +# Eclipse, the contents of the directory containing the HTML and XML files needs +# to be copied into the plugins directory of eclipse. The name of the directory +# within the plugins directory should be the same as the ECLIPSE_DOC_ID value. +# After copying Eclipse needs to be restarted before the help appears. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_ECLIPSEHELP = NO + +# A unique identifier for the Eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have this +# name. Each documentation set should have its own identifier. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. + +ECLIPSE_DOC_ID = org.doxygen.Project + +# If you want full control over the layout of the generated HTML pages it might +# be necessary to disable the index and replace it with your own. The +# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top +# of each HTML page. A value of NO enables the index and the value YES disables +# it. Since the tabs in the index contain the same information as the navigation +# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +DISABLE_INDEX = NO + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. If the tag +# value is set to YES, a side panel will be generated containing a tree-like +# index structure (just like the one that is generated for HTML Help). For this +# to work a browser that supports JavaScript, DHTML, CSS and frames is required +# (i.e. any modern browser). Windows users are probably better off using the +# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can +# further fine tune the look of the index (see "Fine-tuning the output"). As an +# example, the default style sheet generated by doxygen has an example that +# shows how to put an image at the root of the tree instead of the PROJECT_NAME. +# Since the tree basically has the same information as the tab index, you could +# consider setting DISABLE_INDEX to YES when enabling this option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_TREEVIEW = NO + +# When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the +# FULL_SIDEBAR option determines if the side bar is limited to only the treeview +# area (value NO) or if it should extend to the full height of the window (value +# YES). Setting this to YES gives a layout similar to +# https://docs.readthedocs.io with more room for contents, but less room for the +# project logo, title, and description. If either GENERATE_TREEVIEW or +# DISABLE_INDEX is set to NO, this option has no effect. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FULL_SIDEBAR = NO + +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that +# doxygen will group on one line in the generated HTML documentation. +# +# Note that a value of 0 will completely suppress the enum values from appearing +# in the overview section. +# Minimum value: 0, maximum value: 20, default value: 4. +# This tag requires that the tag GENERATE_HTML is set to YES. + +ENUM_VALUES_PER_LINE = 4 + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used +# to set the initial width (in pixels) of the frame in which the tree is shown. +# Minimum value: 0, maximum value: 1500, default value: 250. +# This tag requires that the tag GENERATE_HTML is set to YES. + +TREEVIEW_WIDTH = 250 + +# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to +# external symbols imported via tag files in a separate window. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +EXT_LINKS_IN_WINDOW = NO + +# If the OBFUSCATE_EMAILS tag is set to YES, doxygen will obfuscate email +# addresses. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +OBFUSCATE_EMAILS = YES + +# If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the pdf2svg +# tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see +# https://inkscape.org) to generate formulas as SVG images instead of PNGs for +# the HTML output. These images will generally look nicer at scaled resolutions. +# Possible values are: png (the default) and svg (looks nicer but requires the +# pdf2svg or inkscape tool). +# The default value is: png. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FORMULA_FORMAT = png + +# Use this tag to change the font size of LaTeX formulas included as images in +# the HTML documentation. When you change the font size after a successful +# doxygen run you need to manually remove any form_*.png images from the HTML +# output directory to force them to be regenerated. +# Minimum value: 8, maximum value: 50, default value: 10. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_FONTSIZE = 10 + +# Use the FORMULA_TRANSPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are not +# supported properly for IE 6.0, but are supported on all modern browsers. +# +# Note that when changing this option you need to delete any form_*.png files in +# the HTML output directory before the changes have effect. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_TRANSPARENT = YES + +# The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands +# to create new LaTeX commands to be used in formulas as building blocks. See +# the section "Including formulas" for details. + +FORMULA_MACROFILE = + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see +# https://www.mathjax.org) which uses client side JavaScript for the rendering +# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX +# installed or if you want to formulas look prettier in the HTML output. When +# enabled you may also need to install MathJax separately and configure the path +# to it using the MATHJAX_RELPATH option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +USE_MATHJAX = NO + +# With MATHJAX_VERSION it is possible to specify the MathJax version to be used. +# Note that the different versions of MathJax have different requirements with +# regards to the different settings, so it is possible that also other MathJax +# settings have to be changed when switching between the different MathJax +# versions. +# Possible values are: MathJax_2 and MathJax_3. +# The default value is: MathJax_2. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_VERSION = MathJax_2 + +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. For more details about the output format see MathJax +# version 2 (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) and MathJax version 3 +# (see: +# http://docs.mathjax.org/en/latest/web/components/output.html). +# Possible values are: HTML-CSS (which is slower, but has the best +# compatibility. This is the name for Mathjax version 2, for MathJax version 3 +# this will be translated into chtml), NativeMML (i.e. MathML. Only supported +# for NathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This +# is the name for Mathjax version 3, for MathJax version 2 this will be +# translated into HTML-CSS) and SVG. +# The default value is: HTML-CSS. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the HTML +# output directory using the MATHJAX_RELPATH option. The destination directory +# should contain the MathJax.js script. For instance, if the mathjax directory +# is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax +# Content Delivery Network so you can quickly see the result without installing +# MathJax. However, it is strongly recommended to install a local copy of +# MathJax from https://www.mathjax.org before deployment. The default value is: +# - in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2 +# - in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3 +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_RELPATH = + +# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax +# extension names that should be enabled during MathJax rendering. For example +# for MathJax version 2 (see +# https://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions): +# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols +# For example for MathJax version 3 (see +# http://docs.mathjax.org/en/latest/input/tex/extensions/index.html): +# MATHJAX_EXTENSIONS = ams +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_EXTENSIONS = + +# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces +# of code that will be used on startup of the MathJax code. See the MathJax site +# (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an +# example see the documentation. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box for +# the HTML output. The underlying search engine uses javascript and DHTML and +# should work on any modern browser. Note that when using HTML help +# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) +# there is already a search function so this one should typically be disabled. +# For large projects the javascript based search engine can be slow, then +# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to +# search using the keyboard; to jump to the search box use + S +# (what the is depends on the OS and browser, but it is typically +# , /