DESCRIPTION

The proc tools are utilities that exercise features of /proc
(see proc(4)
).
Most of them take a list of process-ids (pid
);
those that do also accept /proc/nnn
as a process-id, so the shell expansion /proc/*
can be
used to specify all processes in the system. Some of the proc tools can
also be applied to core files (see core(4)
);
those that do accept a list of either process ID
s or
names of core files or both.

pflags

Print the /proc
tracing flags, the pending and held signals, and other /proc
status information for each lwp in each process.

pcred

Print
the credentials (effective, real, saved UIDs
and GID
s) of each process.

pmap

Print
the address space map of each process.

pldd

List the
dynamic libraries linked into each process, including shared objects explicitly
attached using dlopen(3DL)
.
See also ldd(1)
.

Print
the process trees containing the specified pid
s
or user
s, with child processes indented from
their respective parent processes. An argument of all digits is taken to
be a process-id, otherwise it is assumed to be a user login name. Default
is all processes.

ptime

Time
the command
, like time(1)
,
but using microstate accounting for reproducible precision. Unlike time(1)
, children of the command are not timed.

OPTIONS

The following options are supported:

-r

(pflags
only) If the
process is stopped, display its machine registers.

-r

(pmap
only) Print the process's reserved addresses.

-x

(pmap
only) Print resident/shared/private mapping details.

-l

(pmap
only) Print unresolved dynamic linker map names.

-a

(ptree
only) All; include children of process 0.

-v

(pwait
only) Verbose; report terminations to standard output.

-F

Force; grab
the target process even if another process has control.

USAGE

These proc tools stop their target processes while inspecting them
and reporting the results: pfiles
, pldd
, pmap
, and pstack
. A process can do nothing
while it is stopped. Thus, for example, if the X server is inspected by
one of these proc tools running in a window under the X server's control,
the whole window system can become deadlocked because the proc tool would
be attempting to print its results to a window that cannot be refreshed.
Logging in from from another system using rlogin(1)
and killing the offending proc tool would clear up the deadlock in this
case.

Caution should be exercised when using the -F
flag.
Imposing two controlling processes on one victim process can lead to chaos.
Safety is assured only if the primary controlling process, typically a debugger,
has stopped the victim process and the primary controlling process is doing
nothing at the moment of application of the proc tool in question.

Some of the proc tools can also be applied to core files, as shown
by the synopsis above. A core file is a snapshot of a process's state and
is produced by the kernel prior to terminating a process with a signal or
by the gcore(1)
utility. Some of the proc
tools may need to derive the name of the executable corresponding to the
process which dumped core or the names of shared libraries associated with
the process. These files are needed, for example, to provide symbol table
information for pstack(1)
. If the proc
tool in question is unable to locate the needed executable or shared library,
some symbol information will be unavailable for display. Similarly, if a
core file from one operating system release is examined on a different operating
system release, the run-time link-editor debugging interface (librtld_db
) may not be able to initialize. In this case, symbol
information for shared libraries will not be available.