Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LinuxInternetProtocolStats IPConnection invoke getOwningProcessId always return -1 #2639

Closed
yourancc opened this issue May 14, 2024 · 3 comments · Fixed by #2645
Closed

LinuxInternetProtocolStats IPConnection invoke getOwningProcessId always return -1 #2639

yourancc opened this issue May 14, 2024 · 3 comments · Fixed by #2645
Labels
compatibility Extending OSHI compatibility to OSs or versions confirmed bug Confirmed bugs. Highest priority to fix. good first issue Good issues for new contributors to work on up for grabs Issues the maintainers want community help with

Comments

@yourancc
Copy link
Contributor

yourancc commented May 14, 2024

ProcessStat.querySocketToPidMap return the map key use integer ,but socketId sometimes use the big int like 2247483647 in linux. so querySocketToPidMap function return Map<Long,Integer> to fix thr bug

@dbwiddis
Copy link
Member

dbwiddis commented May 18, 2024

Looks like socklen_t is an unsigned integer of at least 32 bits, but applications are recommended to stay under 32 bits for compatibility. So while in theory we could fit it into an Integer there's no reason to not just use a Long since we're parsing strings.

Tracing through the code getting to the connection object, it's the same as the inode in /proc/net/<protocol> output. The inode number is an unsigned (native) long which is 32-bit or 64-bit depending on OS bitness.

Changing the ProcessStat.querySocketToPidMap() return to a Map<Long, Integer> and updating the inode parsing in LinuxInternetProtocolStats.queryConnections() to also parse to a long seems like the right approach.

Can you submit a PR for this fix?

@dbwiddis dbwiddis added confirmed bug Confirmed bugs. Highest priority to fix. good first issue Good issues for new contributors to work on compatibility Extending OSHI compatibility to OSs or versions up for grabs Issues the maintainers want community help with labels May 18, 2024
@yourancc
Copy link
Contributor Author

Thank you for inviting me to contribute to the project!
I will certainly work on a fix and submit a pull request as soon as possible. I appreciate your trust and support, and I'm looking forward to collaborating with the team on this.
If there are any specific guidelines or procedures I should follow for submitting the PR, please let me know.
I'll get started right away!

@dbwiddis
Copy link
Member

yourancc added a commit to yourancc/oshi that referenced this issue May 23, 2024
socklen_t is an unsigned (native) long which is 32-bit or 64-bit depending on OS bitness.
yourancc added a commit to yourancc/oshi that referenced this issue May 25, 2024
yourancc added a commit to yourancc/oshi that referenced this issue May 25, 2024
socklen_t is an unsigned (native) long which is 32-bit or 64-bit depending on OS bitness.
yourancc added a commit to yourancc/oshi that referenced this issue May 25, 2024
socklen_t is an unsigned (native) long which is 32-bit or 64-bit depending on OS bitness.
dbwiddis pushed a commit that referenced this issue May 25, 2024
socklen_t is an unsigned (native) long which is 32-bit or 64-bit depending on OS bitness.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Extending OSHI compatibility to OSs or versions confirmed bug Confirmed bugs. Highest priority to fix. good first issue Good issues for new contributors to work on up for grabs Issues the maintainers want community help with
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants