The first problem with running into trouble when using proot, and trying to debug it, is that ptrace can only be used to attach to a process once.
Are there any tools these days using any of the various new kernel tracing features (ebpf/seccomp?, ftrace+trace-cmd) to do something like strace? This way the ptrace single-attach limitation could be worked around.
The -v flag can help with debugging but the manual contains no information about its possible levels.
Would there be any way for proot to warn about unsupported system calls? The obvious issue here is that there are many system calls that proot isn't supposed to support? (I suppose those could be whitelisted.)
If such a thing could be done, it could be good to have a "learning" mode, where it would be suggested to users to test their application in that mode first, and find out if they are doing anything unsupported. Then when they can be more sure they don't have any silent breakage they can run their application in the normal mode.
All of this might be nice for a troubleshooting section in the manual.
oxr463
commented
1 year ago
Leveraging my experience with https://github.com/proot-me/proot/pull/338 ; (fixes https://nixos.wiki/wiki/Nix_Installation_Guide#Troubleshooting_2 ) I ran into the case where lack of support for a relatively recently added system call resulted in very strange issues. I actually ran into such a thing twice - the first time, I was on an old version of proot that hadn't implemented statx yet.
The first problem with running into trouble when using proot, and trying to debug it, is that ptrace can only be used to attach to a process once.
Are there any tools these days using any of the various new kernel tracing features (ebpf/seccomp?, ftrace+trace-cmd) to do something like strace? This way the ptrace single-attach limitation could be worked around.
The -v flag can help with debugging but the manual contains no information about its possible levels.
Would there be any way for proot to warn about unsupported system calls? The obvious issue here is that there are many system calls that proot isn't supposed to support? (I suppose those could be whitelisted.)
If such a thing could be done, it could be good to have a "learning" mode, where it would be suggested to users to test their application in that mode first, and find out if they are doing anything unsupported. Then when they can be more sure they don't have any silent breakage they can run their application in the normal mode.
All of this might be nice for a troubleshooting section in the manual.