Using austin with kubectl debug

[rbagd]

I was trying to prototype running profiling on a long-running process by attaching a debug container (with austin pre-installed) to a running pod inside Kubernetes with

kubectl debug my-api --profile=general --image=image-with-austin-installed:latest --target=api

Permissions, including SYS_PTRACE, seem OK, albeit the errors indicate clearly that not much seems to be working here

austin[21]: ====[ AUSTINP ]====
austin[21]: Cannot open binary file /usr/local/bin/python3.12
austin[21]: Cannot open binary file /usr/local/lib/libpython3.12.so.1.0
...
austin[35]: Cannot read remote memory
austin[35]: Cannot copy PyThreadState head at (nil) from PyInterpreterState instance
...
austinp[49]: Cannot read remote memory
austinp[49]: > Cannot get remote interpreter state
...
P1;T6878229683678114671;:INVALID: 154
austin[118]: Failed to retrieve OS thread information
austin[118]: Cannot read remote memory
austin[118]: > Cannot read remote PyCFrame
...

One thing is correct - containers still work in different filesystems, even though target container filesystem can be accessed under /proc/$PID/root. Debugging container lives in the same IPC and PID namespace as target, so I'm still surprised memory is not being read. It should be OK, right?

What would be necessary (if even possible) to get austin to work in this setting?

[P403n1x87]

That's an interesting use-case. The latest versions of Austin should have support for inspecting processes running in a container from the host (however there has been reports that this might not always work #210). What you describe shouldn't be too different from this scenario. I believe that, even if permissions are set, one would still have to invoke austin with elevated privileges (e.g. with sudo). If that doesn't work, we would have to look into what's causing it to fail, and understand if we can fix it. Adding support for /proc/<pid>/root might improve things, as we might be able to read the actual binaries and resolve the symbols (assuming that the read errors that you have observed are simply due to invalid memory addresses, rather than a permission issue).