== In praise of Solaris's _pfiles_ command

I'm sure that at one point I was introduced to _pfiles_ through a
description that called it the Solaris version of _lsof_ for a
single process. This is true as far as it goes and I'm certain that
I used _pfiles_ as nothing more than this for a long time, but it
understates what _pfiles_ can do for you. This is because _pfiles_
will give you a fair amount more information than _lsof_ will, and
much of that information is useful stuff to know.

Like _lsof_, _pfiles_ will generally report what a file descriptor
maps to (file, device, network connection, and Solaris IPC 'doors',
often with information about what process is on the other end of
the door). Unlike on some systems, the _pfiles_ information is good
enough to let you track down who is on the other end of Unix domain
sockets and pipes. Sockets endpoints are usually reported directly;
pipe information generally takes cross-correlating with other
processes to see who else has an ((S_IFIFO)) with the specific _ino_
open.

(You would think that getting information on the destination of
Unix domain sockets would be basic information, but on some systems
it can take [[terrible hacks ../linux/GdbGetpeername]].)

Pfiles will also report some socket state information for sockets,
like the socket flags and the send and receive buffers.  Personally
I don't find this deeply useful and I wish that _pfiles_ also showed
things like the TCP window and ACK state. Fortunately you can get
this protocol information with '_netstat -f inet -P tcp_' or '_netstat
-v -f inet -P tcp_' (if you want lots of details).

Going beyond this _lsof_-like information, _pfiles_ will also report
various _fcntl()_ and _open()_ flags for the file descriptor.  This
will give you basic information like the FD's read/write status,
but it goes beyond this; for example, you can immediately see whether
or not a process has its sockets open in non-blocking mode ([[which
can be important ../programming/PollBlockingWritesBad]]). This is
often stuff that is not reported by other tools and having it handy
can save you from needing deep dives with DTrace, a debugger, or
the program source code.

(I'm sensitive to several of these issues because my recent Amanda
troubleshooting left me needing to chart out the flow of pipes and
to know whether some sockets were nonblocking or not. I could also
have done with information on TCP window sizes at the time, but I
didn't find the _netstat_ stuff until just now. That's how it goes
sometimes.)