How to get filename of an open file descriptor
Robert Watson
rwatson at FreeBSD.org
Wed Nov 14 04:21:52 PST 2007
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
> Not sure what type of feedback you want, but I've been using it since you
> posted the link and it works as advertised. I like being able to see the vm
> map without using procfs.
Yeah, that was pretty much the motivation. I also plan to add the ability to
dump signal handler disposition information.
> 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. :-)
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.
> But, it works fine and provides access to information that's not readily
> available by other means.
Thanks for the feedback (working fine is useful feedback),
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-hackers
mailing list