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 _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
