Currently debugger decides whether to debug a particular application basing on the BPF_ALIAS environment variable set for that application.
There are some limits for the number of environment variables the debugger can process (#25, currently 256, can be increased to 1024, but I failed to increase to e.g. 4098).
In Kubernetes, the number of variables set for Mina node executable can be quite huge (kubelet injects a lot of variables, to enable service discovery). With high probability, the BPF_ALIAS will be out of that limit, and won't be processed by the debugger, so it won't process Mina node executable, and won't intercept any of its traffic.
We need another way to specify what process to debug. It might be a PID of the main Mina daemon process. Also it can be a path to executable that should be debugged. The later option would be very handy in case of VM-isolated nodes -- the executable name can be used to discover the main PID. There might also be other options.
Currently debugger decides whether to debug a particular application basing on the
BPF_ALIASenvironment variable set for that application.There are some limits for the number of environment variables the debugger can process (#25, currently 256, can be increased to 1024, but I failed to increase to e.g. 4098).
In Kubernetes, the number of variables set for Mina node executable can be quite huge (kubelet injects a lot of variables, to enable service discovery). With high probability, the
BPF_ALIASwill be out of that limit, and won't be processed by the debugger, so it won't process Mina node executable, and won't intercept any of its traffic.We need another way to specify what process to debug. It might be a PID of the main Mina daemon process. Also it can be a path to executable that should be debugged. The later option would be very handy in case of VM-isolated nodes -- the executable name can be used to discover the main PID. There might also be other options.