🐛 Fix handling of socketMap

[czunker]

Fixes #1434

[czunker]

This PR basically moves code from the port resource to the process resource to have the logic for the socketMap in one place.

[czunker]

I tried this with a local, ssh, and running container connection. OS were Ubuntu 22.04 and Alpine 3.something.

[czunker]

@arlimus Is this how you thought it should be?

[arlimus]

Sorry I'm late to respond @czunker !

I think it's good direction to move this to the process resource, as you are approaching it.

A few things:

1. The port resource has changed and a rebase is necessary.
2. The trickier part: The way the updated port resource works is it doesn't bug down the engine until the user requests anything related to processes. I.e. it is very fast simple checks that look for exposure and ports, without going into processes. I'd like to keep this around, even if we move resources, to keep things running fast. An alternative approach could be to find a more optimized solution for the the sockets (since we know most native tools do this in a split second, whereas the search takes a lot of effort).

No need to press this for v9, I have updated the tags.

[arlimus]

@czunker Given that the primary issue for this PR is closed right now, I'd recommend we get to this after the other priority items are resolved first.

[czunker]

This PR now also fixes an issue, where I didn't see data with a debian 11.

[czunker]

Sorry I'm late to respond @czunker !

I think it's good direction to move this to the process resource, as you are approaching it.

A few things:

1. The port resource has changed and a rebase is necessary.
2. The trickier part: The way the updated port resource works is it doesn't bug down the engine until the user requests anything related to processes. I.e. it is very fast simple checks that look for exposure and ports, without going into processes. I'd like to keep this around, even if we move resources, to keep things running fast. An alternative approach could be to find a more optimized solution for the the sockets (since we know most native tools do this in a split second, whereas the search takes a lot of effort).

No need to press this for v9, I have updated the tags.

For the performance issue:
We need to find out, what the actual performance issue is. This PR uses the find command only for ssh connections. local connections get the data in a different way. The local connection iterates over the /proc filesystem which we disabled for ssh. From my very limited tests, find isn't super fast, but takes only hundreds of milliseconds for a run which takes 3s - 4s in total. local takes much longer, more like minutes when I run it on my laptop.

[arlimus]

Awesome improvements! This should be green once rebased, nice job 🤘