Re: How to get filename of an open file descriptor

On Sun, 18 Nov 2007, Skip Ford wrote:

> Thomas Hurst wrote:
>> * Skip Ford ([e-mail]) wrote:
>>
>>> It would be interesting to know for sure, though, if Solaris uses 
>>> hardlinks and, if so, what their utility is called.
>>
>> Nope.  They *do* use hardlinks in that they have 32bit wrappers in /usr/bin 
>> etc which dispatch to the relevent architecture, but the commands 
>> themselves are all seperate.
>
> Indeed, and each utility is quite complex as compared to what ours would be 
> if split.
>
> I would just rename procstat(1) to pargs(1) then hardlink the others since 
> ours are much less complex, but I'll take anything at this point.
>
> As for the procstat(1) code itself, I've found one bug and have two 
> sugestions:
>
> 1)  procstat_args() doesn't use a local variable and the buffer doesn't
> get cleared between calls:
>
> $ procstat -a 797
>  PID ARGS
>  797 audacious
> $ procstat -a 795 797
>  PID ARGS
>  795 xterm -xtsessionID 11c0a80103000118536826300000007680000
>  797 audacious essionID 11c0a80103000118536826300000007680000
> $
>
> Other option's functions are not similarly affected.
>
> 2)  I think it should handle requests for information about pid 0 instead of 
> requiring at least pid 1 as it currently does.  Solaris suggests '/proc/*' 
> to see all processes.  If we use `ps axopid=` then it aborts on the swapper 
> (pid 0) immediately.
>
> 3)  Similarly, I think all of the sysctl(3) calls within the individual 
> option functions (procstat_bin(), procstat_args(), etc.) should just go 
> ahead and print the header and pid, then print any sysctl(3) error in the 
> PID's row instead of erroring out.  We're either about to finish executing 
> anyway if that was the only pid requested, or we're moving on to another pid 
> that has nothing to do with the previous pid.  There's not really any reason 
> to stop processing further pids.  This also affects attempting to list all 
> pids since it currently stops processing pids as soon as one doesn't exist. 
> A global error variable could just be incremented with every call and 
> returned at process exit, that way it'd still be meaningful for single PIDs.

Actually, I think I've fixed all of the above in p4 with some changes 
yesterday; I'll do a new code drop for you to try:

   http://www.watson.org/~robert/freebsd/20071118-procstat.tgz

The kernel patch is identical, so you can just rebuild procstat.

> Since this is a per-process tool, I think it needs to complete "procstat -c 
> `ps axopid=`" if at all possible.

Yes, I agree.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[e-mail]"