Community
Participate
Working Groups
Created attachment 95509 [details] Patch fixing the described bug. Build ID: M20080221-1800 Steps To Reproduce: Remotetools uses (on linux systems) the output of /proc/net/<networkProtocol> to check used ports. A problem was detected on that procedure, ignoring the first valid entry of the output of that file, losing the information of one connection. More information: The problem is solved on attached patch.
Created attachment 95554 [details] Simplier patch.
Thanks Daniel HB. The patch solves this issue.
Reopening so I can apply the patch. I'm assuming I should apply the second one?
Yes, apply the second one.
Applied. I noticed that this code is very architecture specific. e.g. MacOS X does not have a /proc/net device, so this may produce unexpected results on a non-Linux system. I'm wondering if (a) you should check the operating system first (e.g. uname -a), or (b) use a more generic method of finding the ports. I think one way would be to use 'netstat'. On MacOS X: netstat -a -n -p tcp | tail -n +3 | sed 's/ */ /g' | cut -d ' ' -f 4 | sed 's/.*\.\([0-9][0-9]*\)$/\1/' | sort -n | uniq On Linux: netstat -a -n -t | tail -n +3 | sed 's/ */ /g' | cut -d ' ' -f 4 | sed 's/.*:\([0-9][0-9]*\)$/\1/' | sort -n | uniq Comments?
Currenly we support only Linux hosts, since we do not have a Mac OS for testing. We decided to prefer querying /proc devices instead of executables (like netstat) since we had several concerns. 1) Output of executable is often locale dependent and may break parsing on non English environment. 2) For performance reasons, we don't want to call a pipe of executables on the remote host, since this query might be called several times in a short period of time. 3) /proc produces data that is closer targeted to data that we want to query. Therefore, no filtering isrequired on the remote host, nor on the local, that improves performance. 3) Nearly no parsing is required for /proc. Does Mac OS have a /proc like devices to query system information?
Other good question here in my opinion is: does Windows or others OS matter for PTP? Because then even the solution using netstat should not work.
MacOS X does not have the equivalent of /proc, so the only way to get this information is running a command (netstat or lsof are the only ones I know about). I agree parsing output is problematic. PTP currently supports both Linux and MacOS X as targets, but not Windows. It's possible that we might support Windows as a target in the future, but for now it's not required. I think the the point I'm making here is that the method does not necessarily have to support MacOS X (although this would be nice), but should at least deal with non-Linux targets gracefully. It should also be documented as only working on Linux, if this is the case.
Greg, would you agree if I close this bug and open other one to discuss the /proc issue separately?
Before it's closed, I think the StatusTools class needs either a comment that it will only work if the target host is Linux, or you need to check for the string "No such file or directory" when you execute the command, or both. Feel free to open another bug for the /proc issue.
Added comment to HEAD.
