ptrace in production systems

[Shachar Shemesh]

Lev Olshvang wrote:
> Hi Sha*C*har,
>
> About disadvantages of ptrace  (IMHO):
> 1. controlling process should take care of signal processing (signals 
> are delivered to the caller ??)
No. Signals halt the debugged process, and the controlling process gets 
notified. It just needs to call "ptrace( PTRACE_CONT" with the right 
signal - no big deal if you know what you are doing. Of course, you do 
need to block the SIGSTOP the process receives when it gets attached to.
>     or just resent them to the tracee.  I am not sure signal delivery 
> is reliable
Pretty reliable.
> 2. You introduce new daemon wasting  the  tiny RAM you have.
No, it is an already existing daemon. Besides, 32MB is not tiny. 32MB is 
yamba.

I'll just note that I can understand why people don't like ptrace. It is 
a complicated interface with a lot of platform specific cases, 
especially as you dive deeper and deeper into the application. Truth be 
told, after writing fakeroot-ng, I have lost a lot of my fear of it.

And one thing I did learn from working on fakeroot-ng: it is neither 
unreliable nor inconsistent. It can be a bit unpredictable at times, 
true, as you move between platforms, but not when what you are trying to 
do is as basic as what I offered here.

Still, given a better solution (such as Oron's), I will prefer a 
non-ptrace solution (not to mention that it required even less lines of 
code than the ptrace one, which was already fairly small).

Shachar