Dear all,
I've just received the following mail from Vic Abell, I forward it to
the list for those who are interested.
Cheers,
Jean-Loup
-------------------------------------------------------
> [my reply to Vic]
> I understand why lsof might not report the full path names, but
> not why it behaves differently on similar platforms with the same OS.
> This may be due to Digital Unix.... or an improperly installed stuff.
The different behavior stems from the dynamics of the system -- i.e.,
what's going on at the time lsof probes the kernel cache. Often the
kernel cache is not large and if a number of processes are making
sycalls that require use of the cache, older entries can be pushed
from it very quickly.
Yesterday I did some testing on my two DEC OSF/1 (aka Digital UNIX)
hosts and found that name cache handling could be simplified, if not
improved by making this change to lsof_3*/dialects/osf/dproc.c:
*** /tmp/,RCSt1006641 Tue Jan 14 07:00:33 1997
--- dproc.c Mon Jan 13 12:44:49 1997
***************
*** 678,684 ****
#define NCACHE namecache /* kernel's structure name
*/
#define NCACHE_NM nc_name /* name in NCACHE */
#define NCACHE_NMLEN nc_nlen /* name length in NCACHE */
- #define NCACHE_NXT nc_nxt /* link in NCACHE */
#define NCACHE_NODEADDR nc_vp /* node address in NCACHE */
#define NCACHE_NODEID nc_vpid /* node ID in NCACHE */
#define NCACHE_PARADDR nc_dvp /* parent node address in
NCACHE */
Without the NCACHE_NXT definition the code that probes the kernel
name cache will read it as a simple, linear array, rather than a
linked list. Treating the kernel cache as a linked list (which it
really is for purposes of fast lookup via hashing) prevents lsof
from becoming entangled in stale links.
When I made this change on my test systems the amount of successful
name lookups that lsof could do didn't change appreciably -- either
for the better or the worse -- but I think the non-linked-list code
is more robust.
The change will appear in lsof revision 3.85.
Received on Tue Jan 14 1997 - 14:10:57 NZDT