From 418bf6e9076f845acb04bba946f6f1ced6574298 Mon Sep 17 00:00:00 2001 From: Andres Salomon Date: Wed, 13 Nov 2024 08:37:11 +0000 Subject: [PATCH] Import lsof_4.99.3+dfsg.orig.tar.xz [dgit import orig lsof_4.99.3+dfsg.orig.tar.xz] --- .builds/netbsd.yml | 25 + .builds/openbsd.yml | 29 + .circleci/config.yml | 173 + .cirrus.yml | 23 + .ck00MAN | 1 + .clang-format | 4 + .github/ISSUE_TEMPLATE/bug_report.md | 32 + .github/ISSUE_TEMPLATE/feature_request.md | 20 + .github/workflows/build.yml | 27 + .gitignore | 169 + .readthedocs.yaml | 21 + .travis.yml | 73 + 0..README.BEFORE.README.FIRST | 1 + 00.README.FIRST | 48 + 00CREDITS | 1 + 00DCACHE | 742 ++ 00DIALECTS | 7 + 00DIST | 5594 ++++++++++++ 00FAQ | 7781 +++++++++++++++++ 00LSOF-L | 99 + 00MANIFEST | 343 + 00PORTING | 1793 ++++ 00QUICKSTART | 1 + 00README | 1470 ++++ 00TEST | 1032 +++ 00XCONFIG | 697 ++ AFSConfig | 346 + AUTHORS | 0 COPYING | 26 + ChangeLog | 6 + Configure | 5208 +++++++++++ Customize | 1151 +++ Doxyfile | 2733 ++++++ HOW_TO_MAINTAIN.rst | 2 + HOW_TO_RELEASE.rst | 1 + INSTALL | 368 + Inventory | 204 + Lsof.8 | 4661 ++++++++++ Makefile.am | 224 + NEWS | 0 README | 1 + README.md | 76 + autotools/autotools.h.in | 257 + autotools/version.h.in | 49 + check.bash | 144 + configure.ac | 596 ++ default.nix | 24 + docs/contributing.md | 68 + docs/credits.md | 597 ++ docs/faq.md | 3085 +++++++ docs/getting-started.md | 107 + docs/index.md | 59 + docs/maintaining.md | 246 + docs/manpage.md | 2919 +++++++ docs/manpage.sh | 8 + docs/options.md | 207 + docs/requirements.in | 1 + docs/requirements.txt | 40 + docs/tutorial.md | 699 ++ include/lsof.h | 586 ++ include/lsof_fields.h | 181 + lib/Makefile.skel | 60 + lib/ckkv.c | 82 + lib/common.h | 1543 ++++ lib/cvfs.c | 98 + lib/dialects/aix/Makefile | 168 + lib/dialects/aix/Mksrc | 34 + lib/dialects/aix/aix5/README | 7 + lib/dialects/aix/aix5/j2/j2_lock.h | 19 + .../aix/aix5/j2/private_j2_snapshot.h | 17 + lib/dialects/aix/ddev.c | 686 ++ lib/dialects/aix/dfile.c | 523 ++ lib/dialects/aix/dlsof.h | 432 + lib/dialects/aix/dmnt.c | 289 + lib/dialects/aix/dnode.c | 1257 +++ lib/dialects/aix/dnode1.c | 296 + lib/dialects/aix/dnode2.c | 75 + lib/dialects/aix/dproc.c | 1424 +++ lib/dialects/aix/dproto.h | 66 + lib/dialects/aix/dsock.c | 418 + lib/dialects/aix/dstore.c | 398 + lib/dialects/aix/machine.h | 631 ++ lib/dialects/hpux/kmem/Makefile | 160 + lib/dialects/hpux/kmem/Mksrc | 24 + lib/dialects/hpux/kmem/dfile.c | 245 + lib/dialects/hpux/kmem/dlsof.h | 439 + lib/dialects/hpux/kmem/dmnt.c | 236 + lib/dialects/hpux/kmem/dnode.c | 1052 +++ lib/dialects/hpux/kmem/dnode1.c | 145 + lib/dialects/hpux/kmem/dnode2.c | 346 + lib/dialects/hpux/kmem/dproc.c | 804 ++ lib/dialects/hpux/kmem/dproto.h | 67 + lib/dialects/hpux/kmem/dsock.c | 1125 +++ lib/dialects/hpux/kmem/dstore.c | 226 + lib/dialects/hpux/kmem/hpux11/ipc_s.h | 98 + lib/dialects/hpux/kmem/hpux11/kernbits.h | 22 + lib/dialects/hpux/kmem/hpux11/lla.h | 91 + lib/dialects/hpux/kmem/hpux11/nfs_clnt.h | 76 + lib/dialects/hpux/kmem/hpux11/proc.h | 243 + lib/dialects/hpux/kmem/hpux11/rnode.h | 94 + lib/dialects/hpux/kmem/hpux11/sth.h | 84 + lib/dialects/hpux/kmem/hpux11/tcp_s.h | 208 + lib/dialects/hpux/kmem/hpux11/udp_s.h | 79 + lib/dialects/hpux/kmem/hpux11/vnode.h | 131 + lib/dialects/hpux/kmem/machine.h | 608 ++ lib/dialects/hpux/pstat/Makefile | 149 + lib/dialects/hpux/pstat/Mksrc | 24 + lib/dialects/hpux/pstat/dfile.c | 753 ++ lib/dialects/hpux/pstat/dlsof.h | 205 + lib/dialects/hpux/pstat/dproc.c | 845 ++ lib/dialects/hpux/pstat/dproto.h | 55 + lib/dialects/hpux/pstat/dsock.c | 1597 ++++ lib/dialects/hpux/pstat/dstore.c | 66 + lib/dialects/hpux/pstat/machine.h | 590 ++ lib/dialects/linux/Makefile | 180 + lib/dialects/linux/Mksrc | 37 + lib/dialects/linux/dfile.c | 347 + lib/dialects/linux/dlsof.h | 203 + lib/dialects/linux/dmnt.c | 696 ++ lib/dialects/linux/dnode.c | 901 ++ lib/dialects/linux/dproc.c | 1921 ++++ lib/dialects/linux/dproto.h | 69 + lib/dialects/linux/dsock.c | 5013 +++++++++++ lib/dialects/linux/dstore.c | 117 + lib/dialects/linux/machine.h | 589 ++ lib/dialects/linux/tests/Makefile | 33 + .../linux/tests/case-00-linux-hello.bash | 10 + lib/dialects/linux/tests/case-10-mqueue.bash | 69 + .../linux/tests/case-10-ux-socket-state.bash | 81 + lib/dialects/linux/tests/case-20-epoll.bash | 35 + .../linux/tests/case-20-eventfd-endpoint.bash | 81 + .../tests/case-20-inet-socket-endpoint.bash | 44 + .../case-20-inet6-ffffffff-handling.bash | 46 + .../tests/case-20-inet6-socket-endpoint.bash | 45 + lib/dialects/linux/tests/case-20-mmap.bash | 59 + .../linux/tests/case-20-mqueue-endpoint.bash | 90 + .../linux/tests/case-20-open-flags-cx.bash | 5 + .../linux/tests/case-20-open-flags-path.bash | 5 + .../linux/tests/case-20-open-flags-tmpf.bash | 5 + .../linux/tests/case-20-pidfd-pid.bash | 24 + .../linux/tests/case-20-pipe-endpoint.bash | 39 + .../tests/case-20-pipe-no-close-endpoint.bash | 51 + .../linux/tests/case-20-pty-endpoint.bash | 75 + ...case-20-ux-socket-endpoint-unaccepted.bash | 80 + .../tests/case-20-ux-socket-endpoint.bash | 45 + lib/dialects/linux/tests/epoll.c | 49 + lib/dialects/linux/tests/eventfd.c | 29 + lib/dialects/linux/tests/mmap.c | 35 + lib/dialects/linux/tests/mount-and-mmap.bash | 20 + lib/dialects/linux/tests/mq_fork.c | 43 + lib/dialects/linux/tests/mq_open.c | 24 + lib/dialects/linux/tests/open_with_flags.c | 63 + lib/dialects/linux/tests/pidfd.c | 26 + lib/dialects/linux/tests/pipe.c | 41 + lib/dialects/linux/tests/pty.c | 48 + lib/dialects/linux/tests/util-open-flags.bash | 44 + lib/dialects/linux/tests/ux.c | 133 + lib/dialects/netbsd/Makefile | 158 + lib/dialects/netbsd/Mksrc | 32 + lib/dialects/netbsd/dlsof.h | 573 ++ lib/dialects/netbsd/dmnt.c | 259 + lib/dialects/netbsd/dnode.c | 1449 +++ lib/dialects/netbsd/dnode1.c | 91 + lib/dialects/netbsd/dproc.c | 576 ++ lib/dialects/netbsd/dproto.h | 53 + lib/dialects/netbsd/dsock.c | 438 + lib/dialects/netbsd/dstore.c | 135 + lib/dialects/netbsd/machine.h | 575 ++ lib/dialects/openbsd/Makefile | 158 + lib/dialects/openbsd/Mksrc | 32 + lib/dialects/openbsd/dfile.c | 75 + lib/dialects/openbsd/dlsof.h | 158 + lib/dialects/openbsd/dmnt.c | 160 + lib/dialects/openbsd/dnode.c | 159 + lib/dialects/openbsd/dproc.c | 233 + lib/dialects/openbsd/dproto.h | 43 + lib/dialects/openbsd/dsock.c | 187 + lib/dialects/openbsd/dstore.c | 90 + lib/dialects/openbsd/machine.h | 564 ++ .../openbsd/tests/case-00-openbsd-hello.bash | 1 + lib/dialects/sun/Makefile | 159 + lib/dialects/sun/Mksrc | 27 + lib/dialects/sun/ddev.c | 1086 +++ lib/dialects/sun/dfile.c | 590 ++ lib/dialects/sun/distfile.kvm | 14 + lib/dialects/sun/dlsof.h | 697 ++ lib/dialects/sun/dmnt.c | 396 + lib/dialects/sun/dnode.c | 5268 +++++++++++ lib/dialects/sun/dnode1.c | 414 + lib/dialects/sun/dnode2.c | 483 + lib/dialects/sun/dproc.c | 2138 +++++ lib/dialects/sun/dproto.h | 111 + lib/dialects/sun/dsock.c | 1996 +++++ lib/dialects/sun/dstore.c | 247 + lib/dialects/sun/machine.h | 696 ++ lib/dialects/sun/solaris_kaddr_filters | 239 + lib/dvch.c | 1352 +++ lib/fino.c | 133 + lib/hash.h | 75 + lib/isfn.c | 358 + lib/lkud.c | 193 + lib/lsof.c | 1113 +++ lib/misc.c | 1606 ++++ lib/node.c | 225 + lib/pdvn.c | 169 + lib/prfp.c | 216 + lib/print.c | 1483 ++++ lib/proc.c | 1402 +++ lib/proto.h | 331 + lib/ptti.c | 0 lib/rdev.c | 491 ++ lib/rmnt.c | 225 + lib/rnam.c | 643 ++ lib/rnch.c | 777 ++ lib/rnmh.c | 716 ++ lib/rnmt.c | 212 + m4/.gitignore | 2 + m4/header.m4 | 82 + mkdocs.yml | 18 + scripts/00MANIFEST | 49 + scripts/00README | 43 + scripts/big_brother.pl | 210 + scripts/count_pf.pl | 94 + scripts/identd.pl | 130 + scripts/idrlogin.pl | 195 + scripts/list_NULf.pl | 159 + scripts/list_fields.awk | 198 + scripts/list_fields.pl | 154 + scripts/shared.pl | 407 + scripts/sort_res.pl | 134 + scripts/watch_a_file.pl | 94 + scripts/xusers.awk | 137 + src/arg.c | 2193 +++++ src/cli.h | 37 + src/dialects/linux/dprint.c | 199 + src/main.c | 1956 +++++ src/print.c | 2137 +++++ src/ptti.c | 1355 +++ src/store.c | 176 + src/usage.c | 997 +++ src/util.c | 63 + support/AIXDistrib | 14 + support/DarwinDistrib | 14 + support/Distfile.msrc | 17 + support/FreeBSDDistrib | 14 + support/GPGDistrib | 493 ++ support/GenericCopy | 88 + support/GenericDistrib | 70 + support/GenericDistrib2 | 1 + support/GenericRdist | 80 + support/GenericSubdir | 106 + support/GitHub-release/00README | 10 + support/GitHub-release/ITaP | 47 + support/GitHub-release/Purdue | 156 + support/HPUXDistrib | 14 + support/NSDistrib | 14 + support/NetBSDDistrib | 14 + support/OSRDistrib | 15 + support/OpenBSDDistrib | 14 + support/SpecialRdist | 74 + support/SunDistrib | 14 + support/UWDistrib | 15 + support/argtest | 104 + support/binaries/README | 27 + support/contrib.00INDEX | 22 + support/contrib.README | 8 + support/install-lsof | 143 + support/install.log | 156 + support/look_rlog | 21 + support/lsof-log.xls | 0 support/lsof.00INDEX | 128 + support/lsof.README | 326 + support/makeman | 46 + support/mentor | 5 + support/mirrors | 9 + support/rdist.distrib | 10 + tests/00README | 102 + tests/Add2TestDB | 83 + tests/CkTestDB | 140 + tests/LTbasic.c | 416 + tests/LTbasic2.c | 99 + tests/LTbigf.c | 728 ++ tests/LTdnlc.c | 398 + tests/LTlib.c | 1053 +++ tests/LTlock.c | 739 ++ tests/LTnfs.c | 501 ++ tests/LTnlink.c | 569 ++ tests/LTsock.c | 842 ++ tests/LTszoff.c | 486 + tests/LTunix.c | 345 + tests/LsofTest.h | 333 + tests/Makefile | 165 + tests/TestDB | 153 + tests/case-00-hello.bash | 34 + tests/case-01-version.bash | 27 + tests/case-13-classic.bash | 49 + tests/case-14-classic-opt.bash | 44 + tests/case-20-exit-status.bash | 58 + tests/case-20-fd-only-inclusion.bash | 35 + tests/case-20-handle-missing-files.bash | 16 + tests/case-20-offset-field.bash | 24 + tests/case-20-repeat-count.bash | 19 + tests/case-21-exit-Q-status.bash | 108 + tests/case-22-empty-process-name.bash | 31 + tests/common.bash | 14 + version | 1 + version.in | 1 + zipme | 16 + 308 files changed, 129663 insertions(+) create mode 100644 .builds/netbsd.yml create mode 100644 .builds/openbsd.yml create mode 100644 .circleci/config.yml create mode 100644 .cirrus.yml create mode 100644 .ck00MAN create mode 100644 .clang-format create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md create mode 100644 .github/workflows/build.yml create mode 100644 .gitignore create mode 100644 .readthedocs.yaml create mode 100644 .travis.yml create mode 120000 0..README.BEFORE.README.FIRST create mode 100644 00.README.FIRST create mode 100644 00CREDITS create mode 100644 00DCACHE create mode 100644 00DIALECTS create mode 100644 00DIST create mode 100644 00FAQ create mode 100644 00LSOF-L create mode 100644 00MANIFEST create mode 100644 00PORTING create mode 100644 00QUICKSTART create mode 100644 00README create mode 100644 00TEST create mode 100644 00XCONFIG create mode 100755 AFSConfig create mode 100644 AUTHORS create mode 100644 COPYING create mode 100644 ChangeLog create mode 100755 Configure create mode 100755 Customize create mode 100644 Doxyfile create mode 100644 HOW_TO_MAINTAIN.rst create mode 100644 HOW_TO_RELEASE.rst create mode 100644 INSTALL create mode 100755 Inventory create mode 100644 Lsof.8 create mode 100644 Makefile.am create mode 100644 NEWS create mode 120000 README create mode 100644 README.md create mode 100644 autotools/autotools.h.in create mode 100644 autotools/version.h.in create mode 100755 check.bash create mode 100644 configure.ac create mode 100644 default.nix create mode 100644 docs/contributing.md create mode 100644 docs/credits.md create mode 100644 docs/faq.md create mode 100644 docs/getting-started.md create mode 100644 docs/index.md create mode 100644 docs/maintaining.md create mode 100644 docs/manpage.md create mode 100755 docs/manpage.sh create mode 100644 docs/options.md create mode 100644 docs/requirements.in create mode 100644 docs/requirements.txt create mode 100644 docs/tutorial.md create mode 100644 include/lsof.h create mode 100644 include/lsof_fields.h create mode 100644 lib/Makefile.skel create mode 100644 lib/ckkv.c create mode 100644 lib/common.h create mode 100644 lib/cvfs.c create mode 100644 lib/dialects/aix/Makefile create mode 100755 lib/dialects/aix/Mksrc create mode 100644 lib/dialects/aix/aix5/README create mode 100644 lib/dialects/aix/aix5/j2/j2_lock.h create mode 100644 lib/dialects/aix/aix5/j2/private_j2_snapshot.h create mode 100644 lib/dialects/aix/ddev.c create mode 100644 lib/dialects/aix/dfile.c create mode 100644 lib/dialects/aix/dlsof.h create mode 100644 lib/dialects/aix/dmnt.c create mode 100644 lib/dialects/aix/dnode.c create mode 100644 lib/dialects/aix/dnode1.c create mode 100644 lib/dialects/aix/dnode2.c create mode 100644 lib/dialects/aix/dproc.c create mode 100644 lib/dialects/aix/dproto.h create mode 100644 lib/dialects/aix/dsock.c create mode 100644 lib/dialects/aix/dstore.c create mode 100644 lib/dialects/aix/machine.h create mode 100644 lib/dialects/hpux/kmem/Makefile create mode 100755 lib/dialects/hpux/kmem/Mksrc create mode 100644 lib/dialects/hpux/kmem/dfile.c create mode 100644 lib/dialects/hpux/kmem/dlsof.h create mode 100644 lib/dialects/hpux/kmem/dmnt.c create mode 100644 lib/dialects/hpux/kmem/dnode.c create mode 100644 lib/dialects/hpux/kmem/dnode1.c create mode 100644 lib/dialects/hpux/kmem/dnode2.c create mode 100644 lib/dialects/hpux/kmem/dproc.c create mode 100644 lib/dialects/hpux/kmem/dproto.h create mode 100644 lib/dialects/hpux/kmem/dsock.c create mode 100644 lib/dialects/hpux/kmem/dstore.c create mode 100644 lib/dialects/hpux/kmem/hpux11/ipc_s.h create mode 100644 lib/dialects/hpux/kmem/hpux11/kernbits.h create mode 100644 lib/dialects/hpux/kmem/hpux11/lla.h create mode 100644 lib/dialects/hpux/kmem/hpux11/nfs_clnt.h create mode 100644 lib/dialects/hpux/kmem/hpux11/proc.h create mode 100644 lib/dialects/hpux/kmem/hpux11/rnode.h create mode 100644 lib/dialects/hpux/kmem/hpux11/sth.h create mode 100644 lib/dialects/hpux/kmem/hpux11/tcp_s.h create mode 100644 lib/dialects/hpux/kmem/hpux11/udp_s.h create mode 100644 lib/dialects/hpux/kmem/hpux11/vnode.h create mode 100644 lib/dialects/hpux/kmem/machine.h create mode 100644 lib/dialects/hpux/pstat/Makefile create mode 100755 lib/dialects/hpux/pstat/Mksrc create mode 100644 lib/dialects/hpux/pstat/dfile.c create mode 100644 lib/dialects/hpux/pstat/dlsof.h create mode 100644 lib/dialects/hpux/pstat/dproc.c create mode 100644 lib/dialects/hpux/pstat/dproto.h create mode 100644 lib/dialects/hpux/pstat/dsock.c create mode 100644 lib/dialects/hpux/pstat/dstore.c create mode 100644 lib/dialects/hpux/pstat/machine.h create mode 100644 lib/dialects/linux/Makefile create mode 100755 lib/dialects/linux/Mksrc create mode 100644 lib/dialects/linux/dfile.c create mode 100644 lib/dialects/linux/dlsof.h create mode 100644 lib/dialects/linux/dmnt.c create mode 100644 lib/dialects/linux/dnode.c create mode 100644 lib/dialects/linux/dproc.c create mode 100644 lib/dialects/linux/dproto.h create mode 100644 lib/dialects/linux/dsock.c create mode 100644 lib/dialects/linux/dstore.c create mode 100644 lib/dialects/linux/machine.h create mode 100644 lib/dialects/linux/tests/Makefile create mode 100755 lib/dialects/linux/tests/case-00-linux-hello.bash create mode 100755 lib/dialects/linux/tests/case-10-mqueue.bash create mode 100755 lib/dialects/linux/tests/case-10-ux-socket-state.bash create mode 100755 lib/dialects/linux/tests/case-20-epoll.bash create mode 100755 lib/dialects/linux/tests/case-20-eventfd-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-inet-socket-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-inet6-ffffffff-handling.bash create mode 100755 lib/dialects/linux/tests/case-20-inet6-socket-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-mmap.bash create mode 100755 lib/dialects/linux/tests/case-20-mqueue-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-open-flags-cx.bash create mode 100755 lib/dialects/linux/tests/case-20-open-flags-path.bash create mode 100755 lib/dialects/linux/tests/case-20-open-flags-tmpf.bash create mode 100755 lib/dialects/linux/tests/case-20-pidfd-pid.bash create mode 100755 lib/dialects/linux/tests/case-20-pipe-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-pipe-no-close-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-pty-endpoint.bash create mode 100755 lib/dialects/linux/tests/case-20-ux-socket-endpoint-unaccepted.bash create mode 100755 lib/dialects/linux/tests/case-20-ux-socket-endpoint.bash create mode 100644 lib/dialects/linux/tests/epoll.c create mode 100644 lib/dialects/linux/tests/eventfd.c create mode 100644 lib/dialects/linux/tests/mmap.c create mode 100755 lib/dialects/linux/tests/mount-and-mmap.bash create mode 100644 lib/dialects/linux/tests/mq_fork.c create mode 100644 lib/dialects/linux/tests/mq_open.c create mode 100644 lib/dialects/linux/tests/open_with_flags.c create mode 100644 lib/dialects/linux/tests/pidfd.c create mode 100644 lib/dialects/linux/tests/pipe.c create mode 100644 lib/dialects/linux/tests/pty.c create mode 100644 lib/dialects/linux/tests/util-open-flags.bash create mode 100644 lib/dialects/linux/tests/ux.c create mode 100644 lib/dialects/netbsd/Makefile create mode 100755 lib/dialects/netbsd/Mksrc create mode 100644 lib/dialects/netbsd/dlsof.h create mode 100644 lib/dialects/netbsd/dmnt.c create mode 100644 lib/dialects/netbsd/dnode.c create mode 100644 lib/dialects/netbsd/dnode1.c create mode 100644 lib/dialects/netbsd/dproc.c create mode 100644 lib/dialects/netbsd/dproto.h create mode 100644 lib/dialects/netbsd/dsock.c create mode 100644 lib/dialects/netbsd/dstore.c create mode 100644 lib/dialects/netbsd/machine.h create mode 100644 lib/dialects/openbsd/Makefile create mode 100755 lib/dialects/openbsd/Mksrc create mode 100644 lib/dialects/openbsd/dfile.c create mode 100644 lib/dialects/openbsd/dlsof.h create mode 100644 lib/dialects/openbsd/dmnt.c create mode 100644 lib/dialects/openbsd/dnode.c create mode 100644 lib/dialects/openbsd/dproc.c create mode 100644 lib/dialects/openbsd/dproto.h create mode 100644 lib/dialects/openbsd/dsock.c create mode 100644 lib/dialects/openbsd/dstore.c create mode 100644 lib/dialects/openbsd/machine.h create mode 100755 lib/dialects/openbsd/tests/case-00-openbsd-hello.bash create mode 100644 lib/dialects/sun/Makefile create mode 100755 lib/dialects/sun/Mksrc create mode 100644 lib/dialects/sun/ddev.c create mode 100644 lib/dialects/sun/dfile.c create mode 100644 lib/dialects/sun/distfile.kvm create mode 100644 lib/dialects/sun/dlsof.h create mode 100644 lib/dialects/sun/dmnt.c create mode 100644 lib/dialects/sun/dnode.c create mode 100644 lib/dialects/sun/dnode1.c create mode 100644 lib/dialects/sun/dnode2.c create mode 100644 lib/dialects/sun/dproc.c create mode 100644 lib/dialects/sun/dproto.h create mode 100644 lib/dialects/sun/dsock.c create mode 100644 lib/dialects/sun/dstore.c create mode 100644 lib/dialects/sun/machine.h create mode 100644 lib/dialects/sun/solaris_kaddr_filters create mode 100644 lib/dvch.c create mode 100644 lib/fino.c create mode 100644 lib/hash.h create mode 100644 lib/isfn.c create mode 100644 lib/lkud.c create mode 100644 lib/lsof.c create mode 100644 lib/misc.c create mode 100644 lib/node.c create mode 100644 lib/pdvn.c create mode 100644 lib/prfp.c create mode 100644 lib/print.c create mode 100644 lib/proc.c create mode 100644 lib/proto.h create mode 100644 lib/ptti.c create mode 100644 lib/rdev.c create mode 100644 lib/rmnt.c create mode 100644 lib/rnam.c create mode 100644 lib/rnch.c create mode 100644 lib/rnmh.c create mode 100644 lib/rnmt.c create mode 100644 m4/.gitignore create mode 100644 m4/header.m4 create mode 100644 mkdocs.yml create mode 100644 scripts/00MANIFEST create mode 100644 scripts/00README create mode 100755 scripts/big_brother.pl create mode 100755 scripts/count_pf.pl create mode 100755 scripts/identd.pl create mode 100755 scripts/idrlogin.pl create mode 100755 scripts/list_NULf.pl create mode 100644 scripts/list_fields.awk create mode 100755 scripts/list_fields.pl create mode 100755 scripts/shared.pl create mode 100755 scripts/sort_res.pl create mode 100755 scripts/watch_a_file.pl create mode 100755 scripts/xusers.awk create mode 100644 src/arg.c create mode 100644 src/cli.h create mode 100644 src/dialects/linux/dprint.c create mode 100644 src/main.c create mode 100644 src/print.c create mode 100644 src/ptti.c create mode 100644 src/store.c create mode 100644 src/usage.c create mode 100644 src/util.c create mode 100755 support/AIXDistrib create mode 100755 support/DarwinDistrib create mode 100644 support/Distfile.msrc create mode 100755 support/FreeBSDDistrib create mode 100755 support/GPGDistrib create mode 100755 support/GenericCopy create mode 100755 support/GenericDistrib create mode 120000 support/GenericDistrib2 create mode 100755 support/GenericRdist create mode 100755 support/GenericSubdir create mode 100644 support/GitHub-release/00README create mode 100644 support/GitHub-release/ITaP create mode 100644 support/GitHub-release/Purdue create mode 100755 support/HPUXDistrib create mode 100755 support/NSDistrib create mode 100755 support/NetBSDDistrib create mode 100755 support/OSRDistrib create mode 100755 support/OpenBSDDistrib create mode 100755 support/SpecialRdist create mode 100755 support/SunDistrib create mode 100755 support/UWDistrib create mode 100755 support/argtest create mode 100644 support/binaries/README create mode 100644 support/contrib.00INDEX create mode 100644 support/contrib.README create mode 100755 support/install-lsof create mode 100644 support/install.log create mode 100755 support/look_rlog create mode 100644 support/lsof-log.xls create mode 100644 support/lsof.00INDEX create mode 100644 support/lsof.README create mode 100755 support/makeman create mode 100755 support/mentor create mode 100644 support/mirrors create mode 100755 support/rdist.distrib create mode 100644 tests/00README create mode 100755 tests/Add2TestDB create mode 100755 tests/CkTestDB create mode 100644 tests/LTbasic.c create mode 100644 tests/LTbasic2.c create mode 100644 tests/LTbigf.c create mode 100644 tests/LTdnlc.c create mode 100644 tests/LTlib.c create mode 100644 tests/LTlock.c create mode 100644 tests/LTnfs.c create mode 100644 tests/LTnlink.c create mode 100644 tests/LTsock.c create mode 100644 tests/LTszoff.c create mode 100644 tests/LTunix.c create mode 100644 tests/LsofTest.h create mode 100644 tests/Makefile create mode 100644 tests/TestDB create mode 100755 tests/case-00-hello.bash create mode 100755 tests/case-01-version.bash create mode 100755 tests/case-13-classic.bash create mode 100755 tests/case-14-classic-opt.bash create mode 100755 tests/case-20-exit-status.bash create mode 100755 tests/case-20-fd-only-inclusion.bash create mode 100755 tests/case-20-handle-missing-files.bash create mode 100755 tests/case-20-offset-field.bash create mode 100755 tests/case-20-repeat-count.bash create mode 100755 tests/case-21-exit-Q-status.bash create mode 100755 tests/case-22-empty-process-name.bash create mode 100644 tests/common.bash create mode 100644 version create mode 100644 version.in create mode 100755 zipme 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..7baebeb --- /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 + fedora37: + docker: + - image: docker.io/fedora:37 + fedora38: + docker: + - image: docker.io/fedora:38 + centos8: + docker: + - image: quay.io/centos/centos:stream8 + 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 + bigsur: + macos: + xcode: 12.5.1 + steps: + - checkout + - run: + name: Install pkg-config + command: | + brew install pkg-config libtool + - 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 + 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 + 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, centos8, centos9, debian11, ubuntu2204, archlinux, opensuse15, alpine317] + - nixos + - bigsur diff --git a/.cirrus.yml b/.cirrus.yml new file mode 100644 index 0000000..a81f0a0 --- /dev/null +++ b/.cirrus.yml @@ -0,0 +1,23 @@ +task: + freebsd_instance: + cpu: 1 + matrix: + - image_family: freebsd-14-0-snap + - image_family: freebsd-13-1 + - image_family: freebsd-12-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..e4b9a97 --- /dev/null +++ b/00DIST @@ -0,0 +1,5594 @@ + 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 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 imcomplete, because I don't know how + to get inode number, size and link count. (There's + a new 00FAQ entry about that.) + + Investigated a report from Christopher J Warweg + 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 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 + abstact 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 protocal 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 numer 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 + +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..c626f65 --- /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 probblems +17.27.1 Why does Configure warn that ZFS support is not enabled? +17.28 Problems with Solaris 9 and above +17.28.1 Why does the compiler complain about lgrp_root on Solaris 9 + and above? + +18.0 Lsof Features +18.1 Why doesn't lsof doesn't report on /proc entries on my + system? +18.2 How do I disable the device cache file feature or alter + it's behavior? +18.2.1 What's the risk with a perverted device cache file? +18.2.2 How do I put the full host name in a personal device cache file + path? +18.2.3 How do I put the personal device cache file in /tmp? +18.3 Why doesn't lsof know about AFS files on my favorite dialect? +18.3.1 Why doesn't lsof report node numbers for all AFS volume files, + or how do I reveal dynamic module addresses to lsof? +______________________________________________________________________ + + +1.0 General Concepts + +1.1 Lsof -- what is it? + + Lsof is a UNIX-specific tool. Its name stands for LiSt + Open Files, and it does just that. It lists information + about files that are open by the processes running on a + UNIX system. + + See the lsof man page, the 00DIST file, the 00QUICKSTART + file, and the 00README file of the lsof distribution for + more information. + +1.2 Where do I get lsof? + + Lsof is available via anonymous ftp from lsof.itap.purdue.edu. + Look in the pub/tools/unix/lsof sub-directory. + + ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof + + Bzip2'd, compressed and gzip'd tar files with GPG certificates + are available. + +1.2.1 Are there mirror sites? + + On 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 encounted so far has been different enough + from its siblings to require special source code. + + If you're interested in an SVR4 version of lsof, here are + some existing ports you might consider: + + DC/OSx (This obsolete port is only available upon + special request.) + Reliant UNIX (This obsolete port is only available + upon special request.) + SCO|Caldera UnixWare (This is the most likely choice.) + Solaris + +2.4 Why isn't there an SGI IRIX port? + + Lsof support for IRIX was terminated at lsof revision 4.36, + because it had become increasingly difficult for me to + obtain information on the IRIX kernel structures lsof needs + to access. + + At IRIX 6.5 I decided the obstacles were too large for me + to overcome, and I stopped supporting lsof on IRIX. I have + sources to the last revision of lsof (4.36) for IRIX, but + that version of lsof does not work on IRIX 6.5 and is + vulnerable to the standard I/O descriptor attack. (See + the "Is lsof vulnerable to the standard I/O descriptor + attack?" Q&A for more information.) Contact me to discuss + obtaining those sources. + + If you wish to pursue the issue, don't contact me, contact + SGI. This case was opened with SGI on the subject: + + Case ID: 0982584 + Category: Unix + Priority: 30-Moderate Impact + + Problem Summary: + kernel structure header files needed for continued lsof + support + + Problem Description: + Email In 07/17/98 19:09:23 + +2.5 Why does lsof's Configure script report "WARNING: unsupported + dialect or version"? + + Lsof's Configure script issues this message when it encounters + a dialect or its version that lsof once supported, but no + longer does. Usually I drop support for a dialect or version + when I can no longer test lsof on it. + + However, it's worth trying to compile and use lsof. Be sure to + run the test suite. (See the answer to the "Is there a test + suite? question for information on the test suite.) + + If you have problems with an unsupported dialect or version, + contact me via e-mail at and I may be able to help. + Make sure "lsof" appears in the "Subject:" line so my e-mail filter + won't classify your letter as Spam. + + +3.0 Lsof Problems + +3.1 Configuration Problems + +3.1.1 Why can't Configure determine the UNIX dialect version? + + The lsof Configure script uses UNIX shell commands, often in a + command pipeline, to determine the UNIX dialect version. + (Consult the dialect stanza in Configure to determine which + commands are used.) If Configure can't determine the dialect + version, probably one of the commands is not behaving as + Configure expects. + + Symptoms of the failure include Configure warning messages and + incorrect version definitions in the Makefile CFLAGS. + + If you suspect that the lsof Configure script is failing to + determine the dialect version correctly, try running the + commands from Configure stanza one at a time. That will + usually reveal the source of the problem. Be particularly + mindful that the PATH environment variable can cause commands + to be executed from non-standard directories. + + If you can't determine the source of the problem, there is a + work-around. You can supply the UNIX dialect version in the + LSOF_VSTR environment variable. Use Configure as a guide to + forming what it expects in LSOF_VSTR. There is also some + information on LSOF_VSTR in the 00XCONFIG documentation file + of the lsof distribution. + +3.2 Compilation Problems + +3.2.1 Why does the compiler complain about missing header files? + + When you use make to build lsof, the compiler may complain + that it can't find header files -- e.g., + + $ make + (cd lib; make DEBUG="-O" CFGF="-DAIXA=0 -DAIXV=4330 \ + -DLSOF_VSTR=\"4.3.3.0\"") + gcc -DAIXA=0 -DAIXV=4330 -DLSOF_VSTR="4.3.3.0" -O \ + -c ckkv.c + In file included from ckkv.c:33: ../machine.h:70: \ + sys/types.h: A file or directory in the path name \ + does not exist. \ + + That type of complaint doesn't represent an lsof problem. + It represents a problem with a missing system header file + that probably should be found in /usr/include or in the + system source tree. + + As a first step try using find(1) to locate the problem + header file. If it's a system header file and can't be + found, here are some possible causes: + + 1. The file set, RPM or package containing the header files + has not been installed. Instructions for doing that + are specific to the UNIX dialect and beyond the scope + of this document. + + 2. If the compiler is gcc, the private gcc header files: + + * May not have been installed; + + * May have been installed incorrectly; + + * May not have been updated properly after the last + compiler or system update; + + * Ones from a previous installation may not have been + removed. + + A path leading to the gcc private header files can be + found with `gcc -v`. Consult the gcc documentation for + instructions on proper installation of the private gcc + header files. + + 3. On some dialects -- e.g., FreeBSD, NetBSD, OpenBSD -- + lsof may need to use header files that are located in + the system source tree -- /sys or /usr/src/sys, for + example. Make sure the system source tree has been + installed. + +3.2.2 Why does gcc complain about the contents of header files + distributed by the system's vendor? + + When you use make to build lsof and gcc to compile it, gcc + may complain that it finds errors in system header files + -- e.g., + + $ make + (cd lib; make DEBUG="-O" CFGF="-Dsolaris=80000 \ + -DHASPR_GWINDOWS -m64 -DHASIPv6 -DHAS_VSOCK \ + -DLSOF_VSTR=\"5.8\"") + gcc -Dsolaris=80000 -DHASPR_GWINDOWS -m64 -DHASIPv6 \ + -DHAS_VSOCK -DLSOF_VSTR="5.8" -O -c dvch.c + In file included from /usr/include/sys/proc.h:31, \ + from /homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/ \ + 3.2.1/include/sys/user.h:267, from /usr/include/kvm.h:13, \ + from ../dlsof.h:53, from ../lsof.h:172, from dvch.c:43: \ + /homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/\ + 3.2.1/include/sys/task.h:59: parse error before "uint_t" + + Errors like the above are most likely not problems in the + system's header files, but in the private copies of them + that were created when gcc was made or installed. Note + the presense of + ".../gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/3.2.1/include/..." + in the paths for user.h and task.h. It indicates both + header files are gcc-specific. + + To solve errors like this requires comparing the header + files in the vendor's /usr/include tree to the gcc-specific + ones in gcc's private gcc-lib/.../include tree. It may be + necessary to regenerate gcc-specific header files, correct + them or remove them. See the gcc distribution for the + appropriate tools. + + A possible temporary work-around is to direct gcc to use + the vendor's header files instead of its temporary ones by + declaring -I/usr/include in the compilation flags. + +3.2.3 Other header file problems + + Don't overlook any vendor tools that might validate the + vendor header files installed on the system -- e.g., the + Solaris pkgchk tool can be used to check the header files + that were installed from the SUNWhea package. + + For other header file problems contact me at . + 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 improvments to Internet-only file processing. You + can find more information on those topics in the answer to the + "Why doesn't my dialect support state name exclusion and + inclusion?" question. + + Older AIX lsof may be slow to start because of its oslevel + identity comparison. (Newer AIX lsof uses uname(2).) See the + "Why does AIX lsof start so slowly?" and "Why does lsof warn + "compiled for x ... y; this is z.?" sections for more + information. + +3.5 Why doesn't lsof's setgid or setuid permission work? + + If you install lsof on an NFS file system that has been + mounted with the nosuid option, lsof may not be able to + use the setgid or setuid permission you give it, complaining + it can't open the kernel memory device -- e.g., /dev/kmem. + + The only solution is to install lsof on a file system that + doesn't inhibit setgid or setuid permission. + +3.6 Does lsof have security problems? + + I don't think so. However, lsof does usually start with + setgid permission, and sometimes with setuid-root permission. + Any program that has setgid or setuid-root permission, + should always be regarded with suspicion. + + Lsof drops setgid power, holding it only while it opens + access to kernel memory devices (e.g., /dev/kmem, /dev/mem, + /dev/swap). That allows lsof to bypass the weaker security + of access(2) in favor of the stronger checks the kernel + makes when it examines the right of the lsof process to + open files declared with -k and -m. Lsof also restricts + some device cache file naming options when it senses the + process has setuid-root power. + + On a few dialects lsof requires setuid-root permission + during its full execution in order to access files in the + /proc file system. These dialects include: + + DC/OSx 1.1 for Pyramid systems + Reliant UNIX 5.4[34] for Pyramid systems + + When lsof runs with setuid-root permission it severely + restricts all file accesses it might be asked to make with + its options. + + The device cache file (typically .lsof_hostname in the home + directory of the real user ID that executes lsof) has 0600 + modes. (The suffix, hostname, is the first component of + the host's name returned by gethostname(2).) However, even + when lsof runs setuid-root, it makes sure the file's + ownerships are changed to that of the real user and group. + In addition, lsof checks the file carefully before using + it (See the question "How do I disable the device cache + file feature or alter it's behavior?" for a description of + the checks.); discards the file if it fails the scrutiny; + complains about the condition of the file; then rebuilds + the file. + + See the 00DCACHE file of the lsof distribution for more + information about device cache file handling and the risks + associated with the file. + +3.7 Will lsof show remote hosts using files via NFS? + + No. Remember, lsof displays open files for the processes + of the host on which it runs. If the host on which lsof + is running is an NFS server, the remote NFS client processes + that are accessing files on the server leave no process + records on the server for lsof to examine. + +3.8 Why doesn't lsof report locks held on NFS files? + + Generally lock information held by local processes on remote + NFS files is not recorded by the UNIX dialect kernel. Hence, + lsof can't report it. + + One exception is some patch levels of Solaris 2.3, and all + versions of Solaris 2.4 and above. Lsof for those dialects + does report on locks held by local processes on remotely + mounted NFS files. + +3.8.1 Why does lsof report a one byte lock on byte zero as a full + file lock? + + When a process has a lock of length one, starting at byte + zero, lsof can't distinguish it from a full file lock. + That's because most UNIX dialects represent both locks the + same way in their file lock (flock or eflock) structures. + +3.9 Why does lsof report different values for open files on the + same file system (the automounter phenomenon)? + + On UNIX dialects where file systems may be mounted by an + automounter with the ``direct'' type, lsof may sometimes + report difference DEVICE, SIZE/OFF, INODE and NAME values + when asked to report files open on the file system. + + This happens because some files open on the file system -- + e.g., the current directory of a shell that changed its + directory to the file system as the file system's first + reference -- may be characterized in the kernel with + temporary automounter node information. The cd doesn't + cause the file system to be mounted. + + A subsequent reference to the file system -- e.g., an ls + of any place in it -- will cause the file system to be + mounted. Processes with files open to the mounted file + system are characterized in the kernel with data that + reflects the mounted file system's parameters. + + Unfortunately some kernels (e.g., some versions of Solaris + 2.x) don't revisit the process that did only a change-directory + for the purpose of updating the data associated with the + open directory file. The file continues to be characterized + with temporary automounter information until it does another + directory change, even a trivial ``cd .''. + + Lsof will report on both reference types, when supplied + the file system name as an argument, but the data lsof + reports will reflect what it finds in the kernel. For the + different types lsof will display different data, including + different major and minor device numbers in the DEVICE + column, different lengths in the SIZE/OFF column, different + node numbers in the INODE column, and slightly different + file system names in the NAME column. + + In contrast, fuser, where available, can only report on + one reference type when supplied the file system name as + an argument. Usually it will report on the one that is + associated with the mounted file system information. If + the only reference type is the temporary automounter one, + fuser will often be silent about it. + +3.10 Why don't lsof and netstat output match? + + Lsof and netstat output don't match because lsof reports + the network information it finds in open file system objects + -- e.g., socket files -- while netstat often gets its + information from separate kernel tables. + + The information available to netstat may describe network + activities never or no longer associated with open files, + but necessary for proper network state machine operation. + + For example, a TCP connection in the FIN_WAIT_[12] state + may no longer have an associated open file, because the + connection has been closed at the application layer and is + now being closed at the TCP/IP protocol layer. + +3.10.1 Why can't lsof find accesses to some TCP and UDP ports? + + Lsof stands for LiSt Open Files. If there is no open file + connected to a TCP or UDP port, lsof won't find it. That's + the most common reason why lsof doesn't find a port netstat + might report open. + + One reason I've found on some UNIX dialects is that their + kernels set aside TCP and UDP ports for communicating with + support activities, running in application layer servers + -- the automounter daemons, and the NFS biod and nfsd + daemons are examples. Netstat may report the ports are in + use, but lsof doesn't. + + Another reason is that netstat may also be able to report + a port is open on a particular dialect, because it uses a + source of data different from what lsof uses -- e.g., + netstat might examine kernel tables or use streams messages + to MIB2, while lsof relies on the information it finds in + open file structures and their descendants. + + Sometimes it's possible to search the data netstat and lsof + use. For example, on Linux /proc/tcp and /proc/udp can be + examined. There might an entry there for a particular + protocol and port, but if the line on which the port appears + doesn't have an inode number that matches an inode number + of an open file, lsof won't be able to identify the process + using the port. + + This is a tough question to which there is no easy answer. + +3.11 Why does lsof update the device cache file? + + At the end of the lsof output you may see the message: + + lsof: WARNING: /Homes/abe/.lsof_vic was updated. + + In this message /Homes/abe/.lsof_vic is the path to the + private device cache file for login abe. (See 00DCACHE.) + + Lsof issues this message when it finds it necessary to + recheck the system device directory (e.g., /dev or /devices) + and rebuild the device cache file during the open file + scan. Lsof may need to do these things it finds that a + device directory node has changed, or if it cannot find a + device in the cache. + +3.12 Why doesn't lsof report state for UDP socket files? + + Lsof reports UDP TPI connection state -- TS_IDLE (Idle), + TS_BOUND (Bound), etc. -- for some, but not all dialects. + TPI state is stream-based TCP/IP information that isn't + available in many dialects. + + A fairly weak general rule is if netstat(1) reports UDP + TPI state, lsof may be able to report it, too. But don't + be surprised if lsof fails to report UDP TPI state for your + dialect. Other factors influence lsof's ability to report + UDP TPI state, including the availability of state number + data in kernel structures, and state number to state name + conversion data. + +3.13 I am editing a file with vi; why doesn't lsof find the file? + + Classic implementations of vi usually don't keep open the file + being edited. (Newer ones may do so in order to maintain an + advisory lock.) Instead classic vi opens the file, makes a + temporary copy (usually in /tmp or /usr/tmp), and does its work + in that file. When you save the file being edited from a + classic vi implementation, it reopens and rewrites the file. + + During a classic vi session, except for the brief periods when + vi is reading or rewriting the file, lsof won't find an open + reference to the file from the vi process, because there is + none. + +3.14 Why doesn't lsof report TCP/TPI window and queue sizes for my + dialect? + + Lsof only reports TCP/TPI window sizes for Solaris, because + only its netstat reports them. The intent of providing + TCP/TPI information in lsof NAME column output is to make + it easier to match netstat output to lsof output. + + In general lsof only reports queue sizes for both TCP and + UDP (TPI) connections on BSD-derived UNIX dialects, where + both sets of values appear in kernel socket queue structures. + SYSV-derived UNIX dialects whose TCP/IP implementations + are based on streams generally provide only TCP queue sizes, + not UDP (TPI) ones. + + While you may find that netstat on some SYSV-derived UNIX + dialects with streams TCP/IP may report UDP (TPI) queue + sizes, you will probably also find that the sizes are always + zero -- netstat supplies a constant zero for UDP (TPI) + queue sizes to make its headers align the same for TCP and + UDP (TPI) connections. Solaris seems to get it right -- + i.e., its netstat does not report UDP (TPI) queue sizes. + + When in doubt, I chose to avoid reporting UDP (TPI) queue + sizes for UNIX dialects whose netstat-reported values I + knew to be a constant zero or whose origin I couldn't + determine. OSR is a dialect in this category. + +3.14.1 Why doesn't lsof report socket options, socket states, and TCP + flags and values for my dialect? + + The lsof -T argument, 'f', that selects the reporting of socket + options, socket states and TCP flags was implemented at lsof + revision 4.71 for the following UNIX dialects, providing the + indicated information: + + AIX 4.3.2 and 5.1 and above + All socket options and values, socket states, and TCP + flags and values described in lsof(8) are reported. + Apple Darwin 7.2 and above + All socket options and values, socket states, and TCP + flags and values described in lsof(8) are reported. + 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 it's name, too -- e.g., + + $ lsof /dev/sd0a + + If the mounted-on device isn't a block device -- for example, + some UNIX dialects call a CD-ROM device a character device + (ls output starts with a `c') -- you can force lsof to + assume that the specified device names a file system with + the +f option -- e.g., + + $ lsof +f -- /dev/sd0a + + (Note: you must use ``--'' after +f or -f if a file name + follows immediately, because +f and -f can be followed by + characters that specify flag output selections.) + + When you use +f and lsof can't match the device to a file + system, lsof will issue a complaint. + + The +f option may be used in some dialects to ask lsof to + search for an NFS file system by its server name and server + mount point. If the mount application reports an NFS file + system mounted-on value that way, then this sample lsof + request should work. + + $ lsof +f -- fleet:/home/fleet/u5 + + Finally, you can use -f if you don't want a mounted file + system path name to be considered a request to report all + open files on the file system. This is useful when you + want to know if anyone is using the file system's mounted + path name. This example directs lsof to report on open + access to the `/' directory, including when it's being used + as a current working or root directory. + + $ lsof -f -- / + + The lsof -f option performs the same function as -f does + in some fuser implementations. However, since the lsof -c + option was chosen for another purpose before the `f' option + was added to lsof, +f was selected as the analogue to the + fuser -c option. (Sorry for the potential confusion.) + +3.21.2 Why doesn't lsof find all the open files in a file system? + + Lsof may not find all the open files in a file system for + several reasons. + + First, some processes with files open on the file system + may have been changing status when lsof examined the process + table, and lsof "missed" them. Remember, the kernel changes + much faster than lsof can respond to the changes. + + Second, be sure you have specified the file system correctly. + Perhaps you specified a file instead. You can use lsof's + -V option to have lsof report in detail on what it couldn't + find. Make sure the report for the file system you specified + says "file system." Here's some -V output: + + $ /lsof -V /tmp ./lsof.h ./lsof + COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME + lsof 2688 abe txt VREG 18,1,7 1428583 226641 ./lsof + lsof 2689 abe txt VREG 18,1,7 1428583 226641 ./lsof + lsof: no file use located: ./lsof.h + + You can also use lsof's +f option to force it to consider + a path name as a file system. If lsof can't find a file + system by the specified name, it will issue a complaint -- + e.g., + + $ lsof +f -- /usr + lsof: not a file system: /usr + + (/usr is a directory in the / file system.) + +3.21.3 Why does the lsof exit code report it didn't find open files + when some files were listed? + + Sometimes lsof will list some open files, yet return a + non-zero exit code, suggesting it hasn't found all the + specified files. + + The first thing you should when you suspect lsof is incorrect + is to repeat the request, adding the -V option. In the + resulting report you may find that your file system + specification really wasn't a file system specification, + just a file specification. + + Finally, if you specify two files or two file systems twice, + lsof will credit all matches to the first of the two and + believe that there were no matches for the second. It's + possible to specify a single file system twice with different + path names by using both its mounted directory path name + and mounted-one device name. + + $ lsof +f -V spcuna:/sysprog /sysprog + COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME + ksh 11092 abe cwd VDIR 39,0,1 1536 226562 /sysprog + (spcuna:/sysprog) + ... + lsof: no file system use located: spcuna:/sysprog + + All matches were credited to /sysprog; none to spcuna:/sysprog. + +3.21.4 Why won't lsof find all the open files in a directory? + + When you give lsof a simple directory path name argument + (not a file system mounted-on name), you are asking it to + search for processes that have the directory open as a + file, or as a process-specific directory -- e.g., root or + current working directory. + + If you want to list instances of open files inside the + directory, you need to 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 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 + wil be called libproc-based lsof. + + The /dev/kmem-based lsof sources may be found in the kmem + subdirectory of the dialects/darwin branch of the lsof source + tree. When the supporting version of Apple Darwin is released, + the libproc-based lsof sources will be found in + .../dialects/darwin/libproc. + +5.2 /dev/kmem-based Apple Darwin Questions + +5.2.1 Why does Configure ask for a path to the Darwin XNU kernel + header files? + + When lsof was ported to Apple Darwin by Allan Nathanson at + revision 4.53, some kernel header files needed by lsof + weren't being exported by the developers. (That's still + true at lsof revision 4.76.) + + At first a shell script that Allan provided would get the + missing header files by checking them out from the CVS + root. Although the script was updated from time to time, + eventually the re-organization of Darwin sources has made + it impossible to update the script to do an automatic + download of the missing header files. + + At lsof revision 4.69 and above it is necessary for the Darwin + lsof builder to download the Darwin XNU kernel headers before + attempting to build lsof. The download my be done via a web + browser, starting at this URL: + + http://www.opensource.apple.com/darwinsource/index.html + + Once there, select the link to the Mac OS X version that + matches the one on the system where lsof is to be built. + + Follow that link's "[ Source ]" link. Once there, select the + tar.gz link of the xnu* entry near the bottom of the page. + That entry should have a name that matches the xnu* name shown + by `uname -a` -- e.g., if uname reports: + + $ uname -a + ... root:xnu/xnu-517.7.21 ... + + Then the appropriate xnu* entry is xnu-517.7.21. Clicking + its link should lead to an "Apple Open Source" page requesting + an Apple ID and password. + + Enter them if they're available. If an Apple ID and password + are not available, get them by following the instructions on + the page -- i.e., follow the signin.apple.com link. + + Once a valid Apple ID and its password have been entered, + the download will begin. Select the saving of the downloaded + xnu*.tar.gz file in an appropriate place on the Mac OS X + system. + + Once the download completes, install it. Use gunzip to + decompress the download and tar to extract the archive -- e.g., + + $ gunzip -c xnu-517.7.21.tar.gz | tar xf - + + Remember the absolute path to the extracted archive. That is + its installed place. E.g., if the xnu-517.7.21.tar archive was + extracted to the lsof builder's home directory, its full + installation path will be something like: + + ~/xnu-517.7.21 + + Now run the lsof Configure script. When it asks for the path + to the installed Darwin XNU kernel header files, supply the + path to the gunzip'd and extracted xnu* archive -- e.g., + ~/xnu-517.7.21. + + The path to the Darwin XNU kernel headers may also be + supplied to the Configure script in the DARWIN_XNUDIR + environment variable, eliminating the need to enter it + interactively -- e.g., + + $ DARWIN_XNUDIR=~/xnu-344.49 ./Configure -n darwin + +5.2.1.1 Why does Configure complain that Darwin XNU kernel header + files are missing? + + These are some reasons why the lsof Configure script might + claim that Darwin XNU header files are missing: + + * The wrong path to them was specified. + + * The files and directories in the path are not readable + and searchable -- i.e., check the modes and ownerships. + + * The downloaded archive doesn't match the Mac OS X + version of the system. + + If in doubt, revisit the Darwin XNU kernel header file + download instructions in the answer to the question "Why + does Configure ask for a path to the Darwin XNU kernel + header files?" + + If Configure still can't find Darwin XNU kernel header + files, contact me via e-mail at 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 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 probblems + +17.27.1 Why does Configure warn that ZFS support is not enabled? + + To provide ZFS support it is necessary that lsof have access to + the definitions of ZFS structures used by the kernel. Those + definitions are made available to lsof when it runs by the + libctl library. + + If lsof's Configure script finds that ZFS is indicated by the + presence of the 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 + it's behavior? + + To disable the device cache file feature for a dialect, + remove the HASDCACHE definition from the machine.h file of + the dialect's machine.h header file. You can also use + HASDCACHE to change the default prefix (``.lsof'') of the + device cache file. + + Be sure you consider disabling the device cache file feature + carefully. Having a device cache file significantly reduces + lsof startup overhead by eliminating a full scan of /dev + (or /devices) once the device cache file has been created. + That full scan also overloads the kernel's name cache with + the names of the /dev (or /devices) nodes, reducing the + opportunity for lsof to find path name components of open + files. + + If you're worried about the presence of mode 0600 device + cache files in the home directories of the real user IDs + that execute lsof, consider these checks that lsof makes + on the file before using it: + + 1. To read the device cache file, lsof must gain + permission from access(2). + + 2. The device cache file's modes must be 0600 (0644 + if lsof is reading a system-wide device cache file) + and its size non-zero. + + 3. There must be a correctly formatted section count + line at the beginning of the file. + + 4. Each section must have a header line with a count + that properly numbers the lines in the section. + Legal sections are device, clone, pseudo-device, + and CRC. + + 5. The lines of a section must have the proper format. + + 6. All lines are included in a 16 bit CRC, and it is + recorded in a non-checksummed section line at the + end of the file. + + 7. The checksum computed when the file is read must + match the checksum recorded when the file was + written. + + 8. The checksum section line must be followed by + end-of-information. + + 9. Lsof must be able to get matching results from + stat(2) on a randomly chosen entry of the device + section. + + For more information on the device cache file, read the + 00DCACHE file of the lsof distribution. + +18.2.1 What's the risk with a perverted device cache file? + + Even with the checks that lsof makes on the device cache + file, it's conceivable that an intruder could modify it so + it would pass lsof's tests. + + The only serious consequence I know of this change is the + removal of a file whose major device number identifies a + socket from some user ID's device cache file. When such + a device has been removed from the device cache file, and + when lsof doesn't detect the removal, lsof may not be able + to identify socket files when executed by the affected user + ID. Only certain dialects are at risk to this attack -- + e.g., SCO OpenServer and Solaris 2.x, 7, 8, and 9. + + If you're tracking a network intruder with lsof, that could + be important to you. If you suspect that someone has + corrupted the device cache file you're using, I recommend + you use lsof's -Di option to tell it to ignore it and use + the contents of /dev (or /devices) instead; or remove the + device cache file (usually .lsof_hostname, where hostname + is the first component of the host's name returned by + gethostname(2)) from the user ID's home directory and let + lsof create a new one for you. + +18.2.2 How do I put the full host name in a personal device cache file + path? + + Lsof constructs the personal device cache file path name + from a format specified in the HASPERSDC #define in the + dialect's machine.h header file. As distributed HASPERSDC + declares the path to be ``.lsof_'' plus the first component + of the host name with the format ``.lsof_%L''. + + If you want to change the way lsof constructs the personal + device cache file path name, you can change the HASPERSDC + #define and recompile lsof. If, for example, you #define + HASPERSDC to be ``.lsof_%l'' (note the lower case `l'), + Configure and remake lsof, then the personal device cache + file path will be ``.lsof_'' plus the host name returned + by gethostname(2). + + See the 00DCACHE file of the lsof distribution for more + information on the formation of the personal device cache + file path and the use of the HASPERSDC #define. + +18.2.3 How do I put the personal device cache file in /tmp? + + Change the HASPERSDC definition in your dialect's machine.h + header file. + + When you redefine HASPERSDC, make sure you put at least + one user identification conversion in it to keep separate + the device cache files for each user of lsof. Also give + some thought to including the ``%0'' conversion to define + an alternate path for setuid-root and root processes. + + Here's a definition that puts a personal device cache file + in /tmp with the name ``.lsof_login_hostname_pers''. + + #define HASPERSDC "/tmp/.lsof_%u_%l_pers" + + Thus the /tmp personal device cache file path for login + "abe" on host "lsof.itap.purdue.edu" would be: + + /tmp/.lsof_abe_lsof.itap.purdue.edu_pers + + You can add the User ID (UID) with the "%U" conversion and + the first host name component with the ``%L'' conversion. + + CAUTION: be careful using absolute paths like /tmp lest + lsof processes that are setuid-root or whose real UID is + root be used to exploit some security weakness via /tmp. + Elect instead to add an alternate path for those processes + with the ``%0'' conversion. Here's an extension of the + previous HASPERSDC format for /tmp that declares an alternate + path: + + #define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L" + + When the lsof process is setuid-root or its real UID is + root, presuming root's home directory is `/' and the host's + name is ``lsof.itap.purdue.edu'', the extended format yields: + + /.lsof_vic + +18.3 Why doesn't lsof know about AFS files on my favorite dialect? + + Lsof currently supports AFS for these dialects: + + AIX 4.1.4 (AFS 3.4a) + Linux 1.2.13 (AFS 3.3) + 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..46cd142 --- /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 ehancements. + + 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 + definiton 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..6a21eae --- /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 whe + 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 excute individual tests, too. See the 00TEST file +of this distribution for more informaiton 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 it's 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..fb22927 --- /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 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..f42c1fe --- /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? Its 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 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. + + deafult: 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 suport. + + 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..02b444d --- /dev/null +++ b/Configure @@ -0,0 +1,5208 @@ +#!/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 devloper'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 + ;; + *) + 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..4607002 --- /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 curent 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..82eea4c --- /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 +# numer 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 +# , /