Date: Sun, 18 Nov 2007 17:13:17 -0500 From: Skip Ford <skip@menantico.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, freebsd-hackers@FreeBSD.org, Yuri <yuri@rawbw.com> Subject: Re: How to get filename of an open file descriptor Message-ID: <20071118221317.GF813@menantico.com> In-Reply-To: <20071118205541.U97497@fledge.watson.org> References: <20071114112304.GA835@menantico.com> <20071114121812.U2025@fledge.watson.org> <20071114132743.GB835@menantico.com> <20071116144356.S10677@fledge.watson.org> <20071116212342.GD835@menantico.com> <20071117215003.U53707@maildrop.int.zabbadoz.net> <20071117223910.GD813@menantico.com> <20071118151712.GA21185@voi.aagh.net> <20071118204743.GE813@menantico.com> <20071118205541.U97497@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Sun, 18 Nov 2007, Skip Ford wrote: >> >>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 Yes, I like it. We must be thinking alike, which is ultimately bad news for you, I'm afraid. The bug mentioned first above is still present, and the other bug I mentioned outside of this thread also is, AFAIK. Other than those, I like it. -- Skip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071118221317.GF813>