ptrace in production systems

[Yedidyah Bar-David]

On Sun, Feb 01, 2009 at 05:36:43PM +0200, Shachar Shemesh wrote:
> I think there are a couple of points that did not come across.
>
> The first is that this is an embedded system. It runs an ARM CPU, has  
> 32MB of RAM and 4MB of flash. If we pass the 2MB of (somewhat  
> compressed) filesystem usage mark, we will be in deep s%^$ when we get  
> to the "switching banks" part of the software upgrade.
>
> From the Monit web site:
>> It is a small program and weights in at just over 300kB
> That is a HUGE price to pay just to do what I need (15% of my total  
> allocated storage).
>
> The second part that did not come across is that there is no problem to  
> implement what I need. I already did, and it is working beautifully. My  
> question was whether anyone can give a reason why using ptrace in a  
> production system is not a good idea, because I have my doubts.

I agree that using ptrace does not sound very clean. I never used ptrace
directly, only using strace/ltrace, and these two do sometimes have
issues, which might be bugs in them but also in ptrace. I also read in
lwn some time ago that there is some project to reimplemnt ptrace using
some new tracing subsystem, partly because ptrace is considered broken.

Don't you have any control on the process you want to restart? What
about using inotify/dnotify to look at some file it has open? What about
making it not fork into the background (and get a signal when it dies)?
What about changing init to do something? It should get a signal in this
case. IIRC init from busybox (I don't know which one you use) is very
simple, it might be not very hard to change it.
-- 
Didi