How to get filename of an open file descriptor

[Skip Ford]

Robert Watson wrote:
> On Wed, 14 Nov 2007, Skip Ford wrote:
> >Robert Watson wrote:
> >>On Tue, 13 Nov 2007, Yuri wrote:
> >>
> >>>Thank you for letting me know about this new feature procstat.
> >>>
> >>>But is there any workaround in 6.3? I need to port one package that 
> >>>needs to lookup file names by FDs to the current FreeBSD and need some 
> >>>solution now.
> >>
> >>If the port uses a script to extract the data, a tool like lsof may do 
> >>the trick.  However, I'm not sure there are any native APIs to query that 
> >>data "as shipped" in 6.3.  Once I've had some reasonable feedback on 
> >>procstat(1),
> >
> >Well, the header file procstat.h is still missing from the tarball AFAICT 
> >so I don't know how many people are using it.
> 
> Whoops!  While you have obviously extracted or recreated the file, here's a 
> URL for everyone else:
> 
>   http://www.watson.org/~robert/freebsd/20071115-procstat.tgz

I recreated the file and am running it on RELENG_7.  It applies with a
few small offsets.

> >I don't like having a procstat(1) utility along with a ps(1) utility. 
> >"procstat" seems short for process status as does "ps". Seems like 
> >procstat(1) should be a library with ps(1) the frontend, or ps(1) should 
> >be merged with procstat(1).
> >
> >Plus, the name "procstat" sounds an awful lot like a certain part of the 
> >body that makes me uncomfortable in my chair.  Do you really want to spend 
> >the rest of your life asking people to see their procstat output? ;-)
> 
> You are more evil than previously understood. :-)

Just try saying procstat with a straight face now...

> I agree regarding the duplication with ps(1) -- however, I'm generally of 
> the opinion that ps(1) is overburdened as tools go, and that the goals are 
> actually somehwat different--procstat(1) intentionally doesn't have the 
> ability to generate a list of processes, for example, taking pids 
> explicitly as the argument; likewise, historically ps(1) has not been 
> interested in printing more than one line per process (although I think -h 
> changed this). I'll do a bit more investigation as to how easily it can be 
> wedged in, and do recognize the concern here.

I understand, and I sort of knew that from the beginning which is why I
didn't provide feedback immediately.  I don't have a suggestion as to what
I think should be done.

While procstat(1) currently takes a list of pids, I wouldn't be surprised
if somebody adds code to list all processes, unless you block it.  I
think it would be useful, especially since some of it's options produce
single-line per pid output, such as credentials.

The two utilities do provide different information, it's just a little odd
to have two utilities with basically the same name.  But I can't think of
a more appropriate name for procstat(1).

-- 
Skip