githubmirror/lsof

NEW/lsofAPI/lsofAPI.1
277 строк9 KB
Masatake YAMATO
Import the final source tree published by Vic, the original lsof maintainer.
23 июл 2018, 06:45
23 июл 2018, 06:458662085

			Current lsof data sources
		      and what it does with the data.

    From the proc and user structures:

	process status (p_stat) (e.g., SZOMB)

	    Lsof uses this information to decide if the process
	    is active or is a "zombie" it should ignore.

	command name

	    Lsof reports this information to the user.

	Process IDentification number (PID) (p_pid)

	    Lsof reports this information to the user and uses
	    it in some error messages.

	Process Group ID (PGRP) (p_pgrp)

	    Lsof reports this information to the user, if requested
	    to do so with an option.  Lsof post-processing scripts
	    may use this information to establish process chains.

	Parent PID (PPID) (p_ppid)

	    Lsof reports this information to the user, if requested.
	    to do so with an option.

	User ID (UID) (p_uid)

	    Lsof reports this information to the user.  By
	    default it converts UID to login name, but the default
	    mode can be change with an option.

	Current working directory vnode pointer (p_cdir)

	    Lsof normally reports CWD, but its reporting can be
	    suppressed.  CWD vnode pointer processing is handled as
	    any other vnode pointer from the file structure would be.

	Root directory vnode pointer (p_rdir)

	    Lsof normally reports a root directory, if it exists,
	    but the reporting can be suppressed.  Root directory
	    vnode pointer processing is handled as any other
	    vnode pointer from the file structure would be.

	Text and loader file information (via VM map)
	
	    Lsof follows the pregion and region changes leading
	    from the process' VM pointer to any vnodes that are
	    shadowed by memory regions.  It then processes their
	    vnode pointers just as it processes any others.  This
	    results in a display of the text file used by the
	    process, and the shared library files it uses.

    From file structures:

	The file structure address (from the open file "chunk")

	    Lsof uses this pointer to read the file structure.

	    It also reports the address for post-processing scripts
	    that need to identify unique file structure usage --
	    e.g., check for file descriptor leakage between child
	    and parent processes.

	The usage count (f_count)

	    Lsof uses this to determine if the file structure is
	    worth further examination.

	The node address (f_data)

	    Lsof uses this to read file structure successor --
	    e.g., socket, vnode.

	    Lsof also reports this address for post-processing
	    scripts that need to identify unique file usage.

	The access code (f_flag)

	    Lsof uses this code to report whether the file was opened
 	    for read access, write access, or read/write access.  Lsof
 	    can also be asked to report the full contents of f_flag.

	The file structure type (f_type)

	    Lsof determines the processing to be applied to the
	    file structure successor, pointed at by f_data.

	The file offset (f_offset)

	    Lsof saves this *most* useful information for reporting
	    to the user.  It's particularly interesting, for example,
	    on character device tape files, because when it changes,
	    the tape user knows the tape is moving.

    From socket structures:

	Lsof sometimes uses the file structure alone to identify
	socket files.  At other times it also uses the socket stream
	header pointer.

	Lsof gets the socket structure pointer from f_data in file
	structures whose f_type is DTYPE_SOCKET.  (UNIX dialects
	whose socket implementations are stream based often don't
	have file structure types.)  It then reads the socket
	structure and uses these fields:

	    Socket type (so_type)

		Lsof uses the socket type -- e.g., SOCK_RAW for
		special processing of its structures.

	    Socket protocol (so_proto)
	
		Lsof reads the protocol domain switch, protosw,
		to get the domain structure, so it can find out
		to what domain -- e.g., AF_INET -- the socket
		belongs.

	    Socket receive buffer parameters (so_rcv)
	    Socket send parameters (so_snd)

		Lsof reads these buffer parameters to be able to
		report file size or position.  For example, an
		advancing position on an ftp socket can be used
		as an indicator that the transfer is making progress.

	    Socket protocol control block address (so_pcb)

		Lsof gets TCP/IP addresses from the protocol control
		block.

	    Socket stream header (so_sth)

		Lsof sometimes uses the stream head pointer to
		learn information about the socket file.  It reads
		the stream module names, looking for IP, TCP and
		UDP modules and their private q_ptr addresses.

		If an IP q_ptr is located, lsof reads the ipcs_s
		structure to which it points to get TCP/IP connection
		addresses.

		Lsof also reads other TCP and UDP structures to
		get state and read/write buffer information that
		it can report to the lsof user.

    From the vnode:

	Lsof gets the vnode address from the f_data member of file
	structures.

	It saves the vnode address for use in extracting path
	name components from the kernel name cache.

	Reading the vnode:

	    Usually f_data values point to vnodes.  Lsof reads the
	    structure appropriate to the file type.

	Vnode type (derived from v_op)

	    Lsof must know the vnode type in order to be able to
	    read any further information about the open file from
	    the structures that follow the vnode.  It determines
	    the vnode type by comparing the v_op address to a
	    set of *_vnodeops switch addresses it gets from the
	    kernel via nlist().

	Vnode locks (v_locklist)

	    If the vnode has a lock list pointer, lsof examines
	    the chain it addresses, looking for locks belonging
	    to the process owning the file.

	Vnode virtual file system structure (v_vfsp)

	    Lsof reads the virtual file system structure to
	    determine the file system on which the vnode resides.
	    The vfs structure yields the file system information --
	    mounted-on directory, mounted-on device, NFS device
	    number, etc.  This information is cached by vfs structure
	    address so vfs information for later vnodes can be
	    found quickly.

	Vnode successors (v_data)

	    Based on the vnode type it established from v_op, lsof
	    reads the vnode successor structures addressed by v_data.

	    AFS type vnodes lead to an AFS node structure; VxFS type
	    vnodes lead to a vxnode; CDFS nodes to a cdnode; NFS vnodes
	    to an rnode; etc.

	    There are many special cases -- e.g., FIFOs and pipes.
	    The most special are VCHR nodes.  They can lead to
	    snodes, and from there back to vnodes.  They can lead
	    to device nodes on a special file system -- e.g., /dev
	    nodes on a VxFS file system.  They can lead to simple
	    inodes.

	    Eventually lsof derives the following data from the
	    nodes it reads:

		Vnode address

		File device numbers -- cooked and raw

		File node number

		   Most node structures have a number, but lsof may
		   have to generate a node number from /dev information
		   for some character device files.

		File size

		Link count

		File type (v_type) (e.g., FIFO, VREG, etc.)

		    It's a good indicator of the purpose of the file.

	Streams (v_stream)

	    Lsof saves the device numbers for streams and checks
	    their module names for IP, TCP, and UDP.  If any of
	    those three appear, lsof processes the vnode stream as
	    a socket stream.

    The kernel name cache:

	While device and inode  number uniquely identify files,
	they aren't easy to use by people who read lsof output.
	Lsof output readers want path names.

	Lsof tries to accommodate that by reading the contents of
	the kernel name cache, keyed by vnode addresses, and matching
	that to vnode addresses accumulated while reading open file
	structures and vnodes.

	Since the kernel cache for a particular vnode also points
	to the vnode of its parent, lsof is often successful in
	constructing an entire path name from the kernel cache.
	Sometimes it can't construct the entire name, but some
	terminating components, and even that is helpful.

    The mount table:

	Lsof reads the mount table via the setmntent()/getmntent()
	interface and stores the information for decoding file
	system residence, especially when printing open file results.
	The file system, for example, is the first component of a
	full path name, derived from the kernel name cache, even
	when lsof finds all other path name components in the kernel
	name cache.

    The device table:

	Lsof reads the device table (/dev) using opendir(), readdir(),
	and stat() calls, so it can report full device names on
	VCHR files.

	Since the above operations are sometimes time-consuming
	and the information seldom changes, lsof caches the
	information and tries to get it first from a cache file,
	located in the user's home directory.  (The cache file may
	be stored globally, but it's much more restricted [for
	security reasons] in that case.)


    Vic Abell <abe@purdue.edu>
    March 15, 1999