Re: How to get filename of an open file descriptor
Robert Watson wrote: The main missing feature right now, from my perspective, is signal information, but are there other pieces of detailed process information we could usefully be displaying? I'm not sure I want to get into teaching procinfo about generating stack traces, which is something the Solaris tools can do, but perhaps there are other things we could be displaying. The functionality I'd use most if implemented would be process trees. But, I wouldn't really call it a missing feature since we already have parent pids in ps(1). I'm not so sure generating a tree is something your tool should do either. A lot of OSes seem to have such a tool, but I don't know if they provide more information than we could put together just using ps(1) and your tool once committed. Think I'll play around with creating a kern.proc.tree, just to see if I can, so a tool could dump it with a few lines, but I think it doesn't belong. Although it occurs to me that, in many ways, it would be nice to be able to generate a kernel stack trace for each user thread--often when debugging a hung process, that's one of the pieces of information I'd really like to have, as just seeing a generic wchan sleep on a lock is not very useful. That would be invaluable, and isn't functionality we can gain currently by scripting other tools. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Sun, 18 Nov 2007, Skip Ford wrote: 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 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ Other option's functions are not similarly affected. Indeed, it turned out I fixed another related bug but not this bug (that if there was no pathname returned, we would print the previous pathname). The bug here is not so much the buffer handling, but rather, that the termination condition for the printing loop was wrong. I coded it to look for a double-nul, but in fact, I just needed to loop through until I hit the limit of the data returned by sysctl. So this should now also be fixed. I'm going going to hack a bit more on procstat today and then put up a new drop. The main missing feature right now, from my perspective, is signal information, but are there other pieces of detailed process information we could usefully be displaying? I'm not sure I want to get into teaching procinfo about generating stack traces, which is something the Solaris tools can do, but perhaps there are other things we could be displaying. Although it occurs to me that, in many ways, it would be nice to be able to generate a kernel stack trace for each user thread--often when debugging a hung process, that's one of the pieces of information I'd really like to have, as just seeing a generic wchan sleep on a lock is not very useful. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
* Skip Ford ([EMAIL PROTECTED]) 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. A quick glance at the OpenSolaris source repository finds: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/ptools/ i.e. they're just a bunch of losely related commands under the ptools banner. -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Thomas Hurst wrote: * Skip Ford ([EMAIL PROTECTED]) 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 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ 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. Since this is a per-process tool, I think it needs to complete procstat -c `ps axopid=` if at all possible. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Sun, 18 Nov 2007, Skip Ford wrote: Thomas Hurst wrote: * Skip Ford ([EMAIL PROTECTED]) 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 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
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 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Fri, 16 Nov 2007, Skip Ford wrote: Hi, How about renaming procstat(1) to proc(1), rolling up all of calling it proc(1), I think, is actually not a good idea either. That is way more confusing for people who still think about /proc and do not know the difference between (1) or (4). I like the procstat as it aligns well with other things like fstat netstat sockstat systat vmstat gstat iostat pmcstat ... I admit we also have some *info tools like ffsinfo/diskinfo/rpcinfo/.. but ``pinfo'' seems to better fit the *stat category of tools;-) I am not able to find anything but a simple C wrapper for /proc/*/stat for linux on the web easily (which I suppose could as well be a sh skript) and cannot even find something like procstat on the linux machines I have access to. But there seems to be a procinfo that seems to as well extract information from /proc/ on linux. So having pinfo or procinfo might more confuse people to expect something differently and even worse might mean to be the same tool with compatible command line. While thinking we should try to aling with other OSes and not confuse users coming from non-BSD worlds, procstat to mee seems to be the thing that would best fit for our tree. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Bjoern A. Zeeb wrote: On Fri, 16 Nov 2007, Skip Ford wrote: How about renaming procstat(1) to proc(1), rolling up all of calling it proc(1), I think, is actually not a good idea either. That is way more confusing for people who still think about /proc and do not know the difference between (1) or (4). I like the procstat as it aligns well with other things like fstat netstat sockstat systat vmstat gstat iostat pmcstat ... I admit we also have some *info tools like ffsinfo/diskinfo/rpcinfo/.. but ``pinfo'' seems to better fit the *stat category of tools;-) I am not able to find anything but a simple C wrapper for /proc/*/stat for linux on the web easily (which I suppose could as well be a sh skript) and cannot even find something like procstat on the linux machines I have access to. But there seems to be a procinfo that seems to as well extract information from /proc/ on linux. So having pinfo or procinfo might more confuse people to expect something differently and even worse might mean to be the same tool with compatible command line. While thinking we should try to aling with other OSes and not confuse users coming from non-BSD worlds, procstat to mee seems to be the thing that would best fit for our tree. I don't mind the name procstat(1), I just think we already have one that happens to be abbreviated ps(1) instead of being spelled out. If we end up with hardlinks for a proc tool family of utilities, users will be pointed to the actual tool they need rather than proc(1) so I don't think new user confusion would be that great. But, the same argument also really nullifies my argument for the name as well. If we have hardlinks, I care much less about the name of the base utility since it won't be used everyday. With hardlinks, pinfo(1), proc(1), and procstat(1) are all fine with me. The OP in this thread would then just use pfiles(1) to get a list of open files, same as Solaris, no matter what we call it. It would be interesting to know for sure, though, if Solaris uses hardlinks and, if so, what their utility is called. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Wed, 14 Nov 2007, Skip Ford wrote: 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). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: 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). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? Either of those options works for me. If I were the first person ever to make the decision, I'd go with pinfo(1). However, Linux doesn't have separate utilities like Solaris but does have a procinfo(8) utility in addition to their ps(1). Their procinfo(8) displays system status as gathered from procfs. In other words, anything that's not process related that's available via procfs gets displayed with procinfo(8). So, needless to say, it isn't per-process like ours would be nor does it provide anywhere near the same type of information as pinfo(1) currently (or ever) would: http://www.linuxcommand.org/man_pages/procinfo8.html So, even though the Solaris way of separate utilities seems like overkill to me, that's what I'd vote for following. If that's what you decide should be done and you want a hand, I can do the work. Just let me know the names of the utilities and supply Solaris manpages if they have matching commands, and I can convert your code so you can be working on bigger and better things. But, again, even pinfo(1) would be better than procstat(1) to me so if that's what you decide, I don't have a problem with that. At least our two utilities wouldn't have essentially the same name. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: 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). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? How about renaming procstat(1) to proc(1), rolling up all of the Solaris proc tools functionality into that (someday), then creating hardlinks for all of the individual utilities? I just found the Solaris manpage for their proc tools and I really like how they've done it. The first command listed on that page is proc but then it isn't listed in the synopsis and no man page is listed in the links. So, that plus their single proc tools manpage makes it look to me like that's what they actually do, use a single utility with hardlinks. I've never used Solaris or seen the source so I could be wrong, but that's how it looks from the manpage. That's a great solution, IMO. Plus, it would buy more time. It could go in immediately to all branches then be improved later without breaking anything. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Yuri [EMAIL PROTECTED] writes: 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. You can not reliably obtain a file name from a file descriptor. The best you can hope for is to find a file name that resolves to the vnode that the file descriptor is associated with. The file name you find (if you do - there is no guarantee) may or may not be the name by which the file was opened. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
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. 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. 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? ;-) But, it works fine and provides access to information that's not readily available by other means. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Wednesday 14 November 2007, 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. I'm not completely certain what you are looking for, but doesn't lsof do just that? 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), I'll merge it into CVS and start it on the MFC route, but 6.3 is almost certainly too soon for it to ship as part of that release. I don't know if there will be a 6.4 or not, but I would anticipate procstat(1) appearing in 7.1, and 6-STABLE if there are requests. procstat(1) mostly relies on existing sysctls, and adds two new ones for the purposes of exporting the file descriptor and VM information only, so it is a fairly straight forward MFC. Robert N M Watson Computer Laboratory University of Cambridge Yuri Quoting Robert Watson [EMAIL PROTECTED]: On Mon, 12 Nov 2007, Yuri wrote: Thank you for your response. I attempted to compile procstat but procstat.h seems to be missing in tgz. Yuri, Indeed -- looks like I forgot to p4 add on my development box. I've updated the tarball to now include procstat.h. If there are any other problems, do let me know. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News signature.asc Description: This is a digitally signed message part.
Re: How to get filename of an open file descriptor
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), I'll merge it into CVS and start it on the MFC route, but 6.3 is almost certainly too soon for it to ship as part of that release. I don't know if there will be a 6.4 or not, but I would anticipate procstat(1) appearing in 7.1, and 6-STABLE if there are requests. procstat(1) mostly relies on existing sysctls, and adds two new ones for the purposes of exporting the file descriptor and VM information only, so it is a fairly straight forward MFC. Robert N M Watson Computer Laboratory University of Cambridge Yuri Quoting Robert Watson [EMAIL PROTECTED]: On Mon, 12 Nov 2007, Yuri wrote: Thank you for your response. I attempted to compile procstat but procstat.h seems to be missing in tgz. Yuri, Indeed -- looks like I forgot to p4 add on my development box. I've updated the tarball to now include procstat.h. If there are any other problems, do let me know. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Mon, Nov 12, 2007 at 11:33:38AM -0800, Yuri wrote: I am looking for functionality similar to Linux's /proc/PID/fd/FD. I need to know what is the file name of an open file descriptor. Note that there is not necessarily a unique (or any) filename associated with a file descriptor. This is an inherent part of the Unix approach to files. You could look at ports/sysutils/lsof or fstat(1). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an RFC2821-compliant MTA. pgpQPdPjDBoxX.pgp Description: PGP signature
Re: How to get filename of an open file descriptor
Robert, 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. Yuri Quoting Robert Watson [EMAIL PROTECTED]: On Mon, 12 Nov 2007, Yuri wrote: Thank you for your response. I attempted to compile procstat but procstat.h seems to be missing in tgz. Yuri, Indeed -- looks like I forgot to p4 add on my development box. I've updated the tarball to now include procstat.h. If there are any other problems, do let me know. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to get filename of an open file descriptor
I am looking for functionality similar to Linux's /proc/PID/fd/FD. I need to know what is the file name of an open file descriptor. /proc/PID/fd is missing on FreeBSD. There's something called 'fdescfs'. In /dev/fd/ it shows the list of file descriptors. But they don't seem to be symbolic links to open files. And also it only shows FDs of the current process. So why there's no /proc/PID/fd in FreeBSD? And how do I work around this? Or should I just invest time and write a kernel patch implementing /proc/PID/fd/? Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert, Thank you for your response. I attempted to compile procstat but procstat.h seems to be missing in tgz. Yuri Quoting Robert Watson [EMAIL PROTECTED]: On Mon, 12 Nov 2007, Yuri wrote: I am looking for functionality similar to Linux's /proc/PID/fd/FD. I need to know what is the file name of an open file descriptor. /proc/PID/fd is missing on FreeBSD. There's something called 'fdescfs'. In /dev/fd/ it shows the list of file descriptors. But they don't seem to be symbolic links to open files. And also it only shows FDs of the current process. So why there's no /proc/PID/fd in FreeBSD? And how do I work around this? Or should I just invest time and write a kernel patch implementing /proc/PID/fd/? You can give these patches a try: http://www.watson.org/~robert/freebsd/20071112-procstat.tgz They reflect a work-in-progress procstat(1) tool, which inspects process state in various ways. They are developed against 8-CURRENT, but likely still apply fairly easily to 7-STABLE. They suffer various deficiencies, such as relying on the name cache in-kernel to generate file paths for mapped files and open file descriptors, so don't currently work with devfs nodes (for example). However, they may do what you need. Any feedback would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Mon, 12 Nov 2007, Yuri wrote: I am looking for functionality similar to Linux's /proc/PID/fd/FD. I need to know what is the file name of an open file descriptor. /proc/PID/fd is missing on FreeBSD. There's something called 'fdescfs'. In /dev/fd/ it shows the list of file descriptors. But they don't seem to be symbolic links to open files. And also it only shows FDs of the current process. So why there's no /proc/PID/fd in FreeBSD? And how do I work around this? Or should I just invest time and write a kernel patch implementing /proc/PID/fd/? You can give these patches a try: http://www.watson.org/~robert/freebsd/20071112-procstat.tgz They reflect a work-in-progress procstat(1) tool, which inspects process state in various ways. They are developed against 8-CURRENT, but likely still apply fairly easily to 7-STABLE. They suffer various deficiencies, such as relying on the name cache in-kernel to generate file paths for mapped files and open file descriptors, so don't currently work with devfs nodes (for example). However, they may do what you need. Any feedback would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
I looked at the patch. It retrieves file description information through 'sysctl' calls with proprietary keys. Isn't it better architecturally to expose the same information through procfs interface? At least from the filesystem level and up standard tools like ls/cat will be able to show the the same information instead of the specialized utility. Thanks, Yuri Quoting Robert Watson [EMAIL PROTECTED]: You can give these patches a try: http://www.watson.org/~robert/freebsd/20071112-procstat.tgz They reflect a work-in-progress procstat(1) tool, which inspects process state in various ways. They are developed against 8-CURRENT, but likely still apply fairly easily to 7-STABLE. They suffer various deficiencies, such as relying on the name cache in-kernel to generate file paths for mapped files and open file descriptors, so don't currently work with devfs nodes (for example). However, they may do what you need. Any feedback would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Mon, 12 Nov 2007, Yuri wrote: Thank you for your response. I attempted to compile procstat but procstat.h seems to be missing in tgz. Yuri, Indeed -- looks like I forgot to p4 add on my development box. I've updated the tarball to now include procstat.h. If there are any other problems, do let me know. Robert N M Watson Computer Laboratory University of Cambridge Yuri Quoting Robert Watson [EMAIL PROTECTED]: On Mon, 12 Nov 2007, Yuri wrote: I am looking for functionality similar to Linux's /proc/PID/fd/FD. I need to know what is the file name of an open file descriptor. /proc/PID/fd is missing on FreeBSD. There's something called 'fdescfs'. In /dev/fd/ it shows the list of file descriptors. But they don't seem to be symbolic links to open files. And also it only shows FDs of the current process. So why there's no /proc/PID/fd in FreeBSD? And how do I work around this? Or should I just invest time and write a kernel patch implementing /proc/PID/fd/? You can give these patches a try: http://www.watson.org/~robert/freebsd/20071112-procstat.tgz They reflect a work-in-progress procstat(1) tool, which inspects process state in various ways. They are developed against 8-CURRENT, but likely still apply fairly easily to 7-STABLE. They suffer various deficiencies, such as relying on the name cache in-kernel to generate file paths for mapped files and open file descriptors, so don't currently work with devfs nodes (for example). However, they may do what you need. Any feedback would be most welcome. Robert N M Watson Computer Laboratory University of Cambridge -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Mon, 12 Nov 2007, Yuri wrote: I looked at the patch. It retrieves file description information through 'sysctl' calls with proprietary keys. Isn't it better architecturally to expose the same information through procfs interface? At least from the filesystem level and up standard tools like ls/cat will be able to show the the same information instead of the specialized utility. Over the last several years, we have been working to deprecate procfs as a means as the official means of querying information. This has been for several reasons: (1) procfs has been a major source of security vulnerabilities in every operating system that implements it. You need only look at the vulnerability history of Solaris, Linux, and earlier versions of FreeBSD to see the rather copious list of problems. My belief is that this derives from the fundamental misalignment of the concepts of processes and files: their life cycles are very different, and there appear to be particular problems relating to execve(), which may reflect a security transition that has no logical equivilent revocation point for files. Most of the vulnerabilities have to do with a failure to properly revoke across execution of setuid binaries, and these vulnerabilities seem remarkable persistent over time. (2) procfs is an unstructured query mechanism--sysctl defines certain atomicity properties, has a structured get/set model, and standardized tools for querying simple data. There are well-defined interfaces for requesting the size of the data, etc. Especially for objects that are dynamic in nature, properly implementing buffering of potentially stateful non-atomic queries in a synthetic file system is quite a mess. (3) For non-human interpretation of data, such as monitoring programs, visualization programs, debugging programs, etc, we can avoid marshaling to text and then demarshaling all data on its way through the query interface, which is a common source of bugs (especially when it comes to parsing data that may be defined by untrusted processes, or even just signed vs. unsigned data). I agree there are real trade-offs being made here that can reasonably be debated, but procstat(1) is pretty consistent with our overall direction, and the reasons for the direction are relatively sound. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
On Mon, 12 Nov 2007, Yuri wrote: Y I looked at the patch. It retrieves file description information through Y 'sysctl' calls with proprietary keys. Y Y Isn't it better architecturally to expose the same information through procfs Y interface? At least from the filesystem level and up standard tools like ls/cat Y will be able to show the the same information instead of the specialized utility. IIRC, procfs interface (and existing procfs implementation in particular) has been mostly dropped due to various privilege escalation vulnerabilities existed in the past. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
