1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340
|
Making and Installing lsof 4
********************************************************************
| The latest release of lsof is always available via anonymous ftp |
| from vic.cc.purdue.edu. Look in pub/tools/unix/lsof. |
********************************************************************
Contents
Making Lsof
Other Configure Script Options
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
Bug Reports
The 00FAQ File
The lsof-l Mailing List
Field Output Example Scripts
Dialect Notes
AFS
AIX
Auspex LFS
BSDI BSD/OS
DEC OSF/1, Digital UNIX, Tru64 UNIX
FreeBSD
HP-UX
IPv6
Linux
NetBSD
NEXTSTEP and OpenStep
OpenBSD
Pyramid DC/OSx and Reliant UNIX
SCO OpenServer
SCO UnixWare
Sequent PTX
Solaris 2.x, 7, 8 BETA, and 8 BETA-Refresh
SunOS 4.1.x
Ultrix
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
===========
Making Lsof
===========
$ cd <lsof source directory>
$ ./Configure <your dialect's abbreviation>
$ make
(Consult the 00XCONFIG file of the lsof distribution for information
about using the CFGF, CFGL, and DEBUG make strings to override lsof
default Makefile options.)
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 and the Environment Variables Affecting the Configure
Script section 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, Solaris,
and SunOS) 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 subdirectory to construct the appropriate source
files in the top-level distribution directory.
Configure may also run the MkKernOpts script in the dialect
subdirectory 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 4.1.[45], 4.2[.1], and 4.3[.123] using IBM's C
Compiler
aixgcc IBM AIX 4.1 through 4.3[.123], using gcc
bsdi BSDI BSD/OS 2.1, 3.[01], and 4.[01]
decosf DEC OSF/1, Digital UNIX, Tru64 UNIX 2.0, 3.2, 4.0,
and 5.0
digital_unix Digital UNIX, DEC OSF/1, Tru64 UNIX 2.0, 3.2, 4.0,
and 5.0
du Digital UNIX, DEC OSF/1, Tru64 UNIX 2.0, 3.2, 4.0,
and 5.0
freebsd FreeBSD 2.1.[67]. 2.2[.x], 3.[01234], and 4.0
hpux HP-UX 9.01, 10.20, and 11.00 using HP's C Compiler
hpuxgcc HP-UX 9.01, 10.20, and 11.00 using gcc
linux Linux
netbsd NetBSD 1.[234]
next NEXTSTEP 3.[13]
nextstep NEXTSTEP 3.[13]
ns NEXTSTEP 3.[13]
nxt NEXTSTEP 3.[13]
openbsd OpenBSD 2.[0123456]
openstep OpenStep 4.x
os OpenStep 4.x
osr SCO OpenServer Release 3.0 and 5.0.[0245], using
the C compiler from the SCO developer's kit
osrgcc SCO OpenServer Release 3.0 and 5.0.[0245], using
gcc
sco SCO OpenServer Release 3.0 and 5.0.[0245], using
the C compiler from the SCO developer's kit
scogcc SCO OpenServer Release 3.0 and 5.0.[0245], using
gcc
ptx Sequent PTX 2.1.9, 4.2.[13], 4.[34], and 4.4.[124]
pyr Pyramid DC/OSx 1.1 and Reliant UNIX 5.4[34]
pyramid Pyramid DC/OSx 1.1 and Reliant UNIX 5.4[34]
solaris Solaris 2.5.1 and 2.[67] using gcc
solariscc Solaris 2.5.1, and 2.[67] using Sun's cc
sunos SunOS 4.1.x using gcc
sunoscc SunOS 4.1.x using Sun's cc
tru64 Tru64 UNIX, DEC OSF/1, Digital UNIX 2.0, 3.2, 4.0,
and 5.0
ultrix Ultrix 4.2
unixware SCO UnixWare 2.1.[123] and 7[[.0].1]
uw SCO UnixWare 2.1.[123] and 7[[.0].1]
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.
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).
Lsof is distributed with the security mode disabled -- HASSECURITY
is not defined. 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. (See the
The Customize Script section.)
The lsof -h output indicates the state HASSECURITY had when lsof
was built, reporting: "Only root can list all files," if only root
can list all open files; or "Anyone can list all files," if anyone
is permitted to list all open files.
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.
All pre-compiled binaries on vic.cc.purdue.edu or its mirrors were
constructed without the HASSECURITY definition.
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 <tar@ksu.ksu.edu>.
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
subdirectories, 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(<some group name>) 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 <stolcke@ICSI.Berkeley.EDU>. 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 <Robert.Ehrlich@inria.fr> 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
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 <dialect_abbreviation>
...
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.
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. Although I have no evidence that they
exist, the potential for similar restrictions exists in Solaris
versions of lsof.
AN LSOF BINARY, COMPILED FOR ONE SOLARIS ARCHITECTURE, ISN'T
GUARANTEED TO WORK ON A DIFFERENT SOLARIS ARCHITECTURE.
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.
Before you send me a bug report, please check the lsof frequently
asked questions file, 00FAQ, for a question and answer relevant to
your query.
Please send all bug reports, requests, etc. to me via email at
<abe@purdue.edu>.
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 subdirectory of the lsof distribution.
The scripts subdirectory contains a 00README file with information
about the scripts.
=============
Dialect Notes
=============
AFS
===
Lsof recognizes AFS files on the following combinations of UNIX
dialect and AFS versions:
AIX 4.1.4 (AFS 3.4a)
HP-UX 9.0.5 (AFS 3.4a)
Linux 1.2.13 (AFS 3.3)
NEXTSTEP 3.2 (AFS 3.3) (untested on recent lsof revisions)
Solaris 2.5.1 and 2.6 (AFS 3.4a)
SunOS 4.1.4 (AFS 3.3a)
Ultrix 4.2 RISC (AFS 3.2b)
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],
and 4.3[.123]. Specify aixgcc to use the gcc compiler. (Gcc can
only be used to compile lsof for AIX 4.1 and above, because of
kernel structure alignment differences between it and xlc.) Gcc
compilation of lsof for AIX 4.3[.123] hasn't been tested yet
(October 1999).
The Configure script uses /usr/bin/oslevel to determine the AIX
version. If /usr/bin/oslevel isn't executable, the Configure script
issues a warning message and uses ``uname -rv'' to determine the
AIX version.
When Configure must use ``uname -rv'' to determine the AIX version,
the result will lack a correct third component -- e.g., the `4' of
``4.1.4''. If your AIX 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
<rudi@acs.bu.edu> 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
<bobcook@SLAC.Stanford.EDU> and Jan Tax <jan_tax@unc.edu> who
provided test systems.
Henry Grebler <henryg@optimation.com.au> and David J. Wilson
<davidw@optimation.com.au> helped with lsof for AIX 4.2.
Bill Pemberton <wfp5p@tigger.itc.virginia.edu> provided an AIX 4.3
test system. Andrew Kephart <akephart@austin.ibm.com> and Tom
Weaver <tvweaver@austin.ibm.com> provided AIX 4.3 technical
assistance. Niklas Edmundsson <nikke@ing.umu.se> did 4.3.1 testing.
Doug Crabill <dgc@purdue.edu> provided an AIX 4.3.2 test system.
Jeff W. Stewart <jws@anaconda.cc.purdue.edu> 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.
Auspex LFS
==========
Lsof 4.45 and above support the Auspex LFS on SunOS 4.1.4. It has
been tested with Auspex versions 1.8.1 and 1.9.2. Auspex support
was added with help from Quentin Fennessy <quentin@dvorak.amd.com>.
Since Auspex doesn't distribute a header file that defines the LFS
kernel memory node structure, the structure definition was created
by examining debugger dumps. It is altogether possible that future
Auspex versions could change the structure and render lsof's LFS
support inoperable.
Some Auspex processes appear to have open files that use /dev/ipc
as though it were a clone master -- e.g., with a device number
converted from (37,80) to (80,0). Unfortunately there is not enough
evidence for lsof to make the same connection, since the files do
not have a stream. Consequently, lsof reports no node number or
name for these open files.
BSDI BSD/OS
===========
Terry Kennedy <terry@spcvxa.spc.edu> provided a 2.1 test system so
that support for BSDI BSD/OS could be revived. (BSDI BSD/OS support
was dropped at from version 3 at revision 3.21 when a test system
was no longer available.) Terry has also provided 3.0 and 3.1 test
systems.
Jim Reid <jim@mpn.cp.philips.com> helped with the 3.0 port and
Terry Kennedy provided a test system.
Jeffrey C. Honig <jch@bsdi.com> packaged lsof for inclusion on the
BSDI user-contributed software CD.
DEC OSF/1, Digital UNIX, Tru64 UNIX
===================================
Dean Brock <brock@cs.unca.edu>, Angel Li <angel@flipper.rsmas.miami.edu>,
Dwight McKay <mckay@gimli.bio.purdue.edu>, Berkley Shands
<berkley@cs.wustl.edu>, and Ron Young <ron@screamer.nevada.edu>
have kindly provided test systems. Jeffrey Mogul <mogul@pa.dec.com>
has provided technical assistance. Dave Morrison <dmorriso@us.oracle.com>
and Lawrence MacIntyre <lpz@nautique.epm.ornl.gov> did Digital UNIX
V3.2 testing.
Lsof supports the ADVFS/MSFS layered file system product. Lsof
can locate all the open files of an ADVFS/MSFS file system when
its path is specified, provided the file system is listed in
/etc/fstab with an ``advfs'' type. (This /etc/fstab caveat applies
only to Digital UNIX 2.0.) At Digital UNIX 4.0 and Tru64 UNIX,
using code provided by David Brock, lsof 4.20 and above can locate
ADVFS file paths.
FreeBSD
=======
Bill Bormann of the Purdue University Computing Center provided
access to several FreeBSD test systems. Ade Barkah <mbarkah@hemi.com>,
John Clear <jac@dragonfly.vet.purdue.edu>, Ralph Forsythe
<ralph@contact-paging.com>, Kurt Jaeger <pi@complx.stgt.sub.org>,
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.
David O'Brien <obrien@NUXI.com> maintains the lsof FreeBSD port
package.
HP-UX
=====
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 <ppk@atk.tpo.fi> helped with the HP-UX port, especially
with its CCITT x.25 socket support.
Richard Allen <ra@rhi.hi.is> provided HP-UX 10.x and 11.00 test
systems, as did Mark Bixby <markb@cccd.edu>, and Elias Halldor
Agustsson <elias@rhi.hi.is>. Marc Winkler <marc@healthchex.com>
helped test the 10.20 port. Richard J. Rauenzahn <rrauenza@cup.hp.com>
provided a 64 bit HP-UX 11 test system.
AFS support for HP-UX was added thanks to help from Chaskiel Moses
Grundman <cg2v+@andrew.cmu.edu>, who provided a test system.
The HP-UX 11.00 support is 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 changings a kernel structure critical
to lsof could break lsof in some way.
IPv6
====
Lsof has IPv6 support that has been tested for these UNIX dialects:
AIX 4.3.x; the INRIA FreeBSD IPv6 package; /proc-based Linux; the
INRIA and KAME NetBSD implementations; and Solaris 8 BETA-Refresh.
Lsof has IPv6 support that hasn't been tested for: BSDI 4.x; FreeBSD
(KAME); OpenBSD (KAME); and Tru64 Unix 5.
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 <jtk@arthur.cs.purdue.edu>, Steve Logue <stevel@mail.cdsnet.net>
Joseph J. Nuspl Jr. <nuspl@nvwls.cc.purdue.edu>, and Jonathan
Sergent <sergent@purdue.edu> have provided Linux test systems.
Michael Shields <shields@tembel.org> helped add and test automatic
handling of ELF/COFF form names in /System.map, Marty Leisner and
Keith Parks <emkxp01@mtcc.demon.co.uk> 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 <earle@isolar.Tujunga.CA.US> and Paul Kranenburg
<pk@cs.few.eur.nl> have assisted with the NetBSD ports. Paul
has provided test systems.
The NetBSD dialect version of lsof is compiled using the dialect
sources it shares with OpenBSD in the n+obsd dialect subdirectory.
NEXTSTEP and OpenStep
=====================
Virtual memory header files that allow lsof to display text references
were derived from the contents of /usr/include/vm of NEXTSTEP 2.0.
NeXT did not ship the virtual memory header files with other NEXTSTEP
or OpenStep versions.
You may use the RC_FLAGS environment variable to declare compiler
options outside the Makefile. A common use of this variable is to
define the architecture types to be included in a "fat" executable.
See the comments in dialects/next/Makefile for an example.
OpenBSD
=======
David Mazieres <dm@amsterdam.lcs.mit.edu> has provided an OpenBSD
test system. The OpenBSD dialect version of lsof is compiled using
the dialect sources it shares with NetBSD in the n+obsd dialect
subdirectory.
Kenneth Stailey <kstailey@disclosure.com> has provided OpenBSD
testing and advice.
<Zube@cs.colostate.edu> reports, "lsof 4.33 compiles and runs on
OpenBSD 2.3 for the pmax architecture (decstation 3100)."
Pyramid DC/OSx and Reliant UNIX
===============================
These two UNIX dialects are very similar and share dialect-specific
source files from the pyramid subdirectory.
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 <stdio.h> and <string.h>.
Bruce Beare <bjb@pyramid.com> and Kevin Smith <kevin@pyramid.com>
provided test systems.
SCO OpenServer
==============
Dion Johnson <dionj@sco.com>, Bela Lubkin <belal@sco.com>, and
Nathan Peterson <nathanp@sco.com> 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 <hughd@sco.COM>, Bela Lubkin, Craig B. Olofson
<craigo@sco.COM>, 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 <chrisd@dlpco.com> provided a 5.0.4 test
system and Lee Penn <lee@dlpco.com> provided one for 5.0.5.
The <netdb.h> 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 <netdb.h> and the <sys/cdefs.h> header file
it includes are located in the dialects/os/include subdirectory
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 <abe@purdue.edu>. 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.
SCO UnixWare
============
D. Chris Daniels <chrisd@dlpco.com>, Ken Laing <ken@compclass.com>,
Andrew Merril <andrew@compclass.com>, Lee Penn <lee@dlpco.com>,
and Matthew Thurmaier <matt@compclass.com> provided test systems.
Bela Lubkin <belal@sco.COM> provided technical assistance.
Sequent PTX
===========
Allen Braunsdorf <ab@physics.purdue.edu>, Peter Jordan <petej@sequent.com>,
Gerrit Huizenga <gerrit@sequent.com>, Andrew J. Korty <ajk@purdue.edu>,
Kevin Smallwood <kcs@sequent.com>, Mike Spitzer <mjs@sequent.com>,
and Bruce Summers <bsum@sequent.com> provided access to test systems
and gave technical advice.
Thomas A. Endo <tendo@netcom.com>, Bob Foertsch <foertsch@uiuc.edu>,
David Putz <PutzDW@PO1.LMB.unisys.com>, Joel White <jdwhite@netcom.com>
have helped test lsof for PTX. Laurent P. Montaron <lpm@sequent.com>
has provided fixes and proting modifications.
Lsof may not compile under all versions of PTX because of header
file complications resulting from the absence of a particular
layered product. I have accommodated only the CD-ROM and NFS
layered products in the lsof sources. If you have problems compiling
lsof because your C compiler complains about missing header files,
please email a description of your problems to me.
Solaris 2.x, 7, 8 BETA, and 8 BETA-Refresh
==========================================
SEE THE CAUTIONS SECTION OF THIS DOCUMENT.
The latest Solaris revision of lsof 4 might work under Solaris 2.[1-4],
but hasn't been tested there.
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 support for 64 bit kernels depends on a Sun WorkShop
Compilers C compiler version that supports the "-xarch=v9" flag --
usually 5.0 or greater. As of this writing (April 21, 1998) no
version of gcc was available for building 64 bit applications.
See "How do I install lsof for Solaris 7?" in 00FAQ for instructions
on installing 32 and 64 bit Solaris 7 versions on the same system.
Dave Curry <davy@ecn.purdue.edu> and Steve Kirsch <stk@infoseek.com>
provided resources for Solaris 2.x ports. Casper Dik <casper@fwi.uva.nl>
and Gerry Singleton <Gerry.Singleton@Canada.Sun.COM> consulted and
provided valuable assistance.
Henry Katz <hkatz@panix.com>, Joseph Kowalski <jek3@jurassic.Eng.Sun.COM>,
Charles Stephens <cfs@jurassic.eng.Sun.COM>, Mike Sullivan
<Mike.Sullivan@Eng.Sun.COM>, and Mike Tracy <mtrac@jurassic-45.Eng.Sun.COM>
provided technical assistance.
AFS support was added to Solaris lsof with help from Curt Freeland
<curt@grumpy.cse.nd.edu>, Heidi Hornstein <heidi@cmf.nrl.navy.mil>,
Michael L. Lewis <mlewis@morgan.com>, Terry McCoy <terry@anubis.cc.nd.edu>,
Phillip Moore <wpm@morgan.com>, and Sushila R. Subramanian
<sushi@cmf.nrl.navy.mil>
Casper Dik <casper@holland.Sun.COM> provided valuable assistance
for the Solaris 8 BETA and 8 BETA-Refresh support.
SunOS 4.1.x
===========
SEE THE CAUTIONS SECTION OF THIS DOCUMENT.
The distribution will build a usable lsof for SunOS 4.1.3. It may
build distributions that will work under SunOS 4.1.1 and 4.1.2,
and 4.1.4.
To use lsof with SunOS versions, configure for sunos or sunoscc.
You have two compiler choices -- gcc or cc. Select the abbreviation
that fits your system, sunos for gcc, or sunoscc for Sun cc. If
you use gcc less than version 2.8, make sure the gcc-specific
includes have been updated for your version of Solaris -- i.e.,
run the gcc fixincludes (fininx.svr4 for Solaris) script.
It is also important to understand that a SunOS 4.1.x executable
may only work for the architecture on which it is compiled. For
example, compiling lsof on a S690MP server produces a lsof that
will only run on the server; that lsof won't run on the server's
IPC clients. To obtain a lsof that will run on the IPC clients,
one must compile lsof on an IPC.
This awkward condition is a result of differences in the user
structure (in <sys/user.h>) between Sun architectures. Some standard
Sun executables -- e.g., /bin/ps -- have the same problem. Sun
has "solved" the problem by symbolically linking them to architecture-
specific executables in /usr/kvm. Thus, /bin/ps becomes a symbolic
link to /usr/kvm/ps.
Following this pattern, lsof is usually installed in /usr/kvm under
SunOS. Sometimes people will make a symbolic link from a more
common place, e.g., /usr/local/etc/lsof to /usr/kvm/lsof, to make
it easier to find lsof.
You may not want to install lsof in /usr/kvm with a symbolic link
from somewhere else. In that case you might want to try a strategy
suggested by Steinar Haug <Steinar.Haug@runit.sintef.no>. First,
install the architecture-specific revisions of lsof in the place
of your choice, each with a suffix matching the architecture value
produced by the -m option of the uname command -- e.g., lsof.sun4,
lsof.sun4c, lsof.sun4m. Then, install the following shell script
as lsof.
#! /bin/sh
prog=$0.`uname -m`
exec $prog ${1+"$@"}
AFS support was added for SunOS lsof thanks to help from Chaskiel
Moses Grundman <cg2v+@andrew.cmu.edu>. Chaskiel provided a test
system and valuable AFS consulting.
Ultrix
======
Terry Friedrichsen <terry@venus.sunquest.com>, Dwight McKay
<mckay@gimli.bio.purdue.edu>, and Jeffrey Mogul <mogul@pa.dec.com>
helped me with this port.
DECnet support was added to Ultrix lsof with the help of John Beacom
<beacom@wisnud.physics.wisc.edu>, 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.
================================
User-contributed Dialect Support
================================
There are some user-contributed dialect versions of lsof; more
information on them can be found at:
ftp://vic.cc.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
MIPS RISC/os 4.52
Motorola V/88
Novell UnixWare 1.x
Sequent DYNIX
Remnants of the support lsof once provided for these dialects may
be found in:
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/OLD/binaries
and
ftp://vic.cc.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 Pyramid DC/OSx, /proc-based Linux,
and Pyramid Reliant UNIX 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. See the
discussion of the SunOS 4.1.x /usr/kvm strategy for another
perspective on the siting of the lsof executable.
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.
DC/OSx 1.1
/proc-based Linux (generally 2.1.72 and above)
Reliant UNIX 5.4[34]
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]
BSDI BSD/OS 2.1, 3.[01], and 4.[01]
DEC OSF/1, Digital UNIX, Tru64 UNIX 2.0, 3.2, 4.0, and 5.0
FreeBSD 2.1.6, 2.2[.x], 3.[01234], and 4.0
HP-UX 9.01, 10.20, and 11.00
Linux 2.0.3[2346]
NetBSD 1.[234]
NEXTSTEP 3.[13]
OpenBSD 2.[0123456]
OpenStep 4.x
SCO OpenServer Release 3.0 and 5.0.[0245]
SCO UnixWare 2.1.[123] and 7[[.0].1]
Sequent PTX 2.1.9, 4.2.[13], 4.[34], and 4.4.[124]
Solaris 2.5.1 and 2.[67]
SunOS 4.1.x
Ultrix 4.2
====================================
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, vic.cc.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.0.33 system and you want to
Configure and build lsof for Linux 2.1.42.
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 envionment 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 Special 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 <abe@purdue.edu>
Purdue University Computing Center (PUCC)
January 14, 2000
|