Oron Peled wrote:
Why not have it restart itself?
execve(argv[0], argv, yada, yada)
if( restart ) {
execv( argv[0], argv )
syslog( LOG_CRIT, Configuration reload failed: %m )
}
at the end of main.
from some signal handler?
Oooh, no. The entire idea is to allow an orderly
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(
On Sunday, 1 בFebruary 2009, Shachar Shemesh wrote:
Oron Peled wrote:
On Sunday, 1 בFebruary 2009, Shachar Shemesh wrote:
Then again, it is a daemon. It has no parent (well, init is its parent).
It's not clear from your description (or your replies to other posters)
why you
The second point is that I don't need advice about how
it can be done. I can think of three or four ways not
mentioned here at all. They have disadvantages in relation
to what I implemented, mostly in how long it takes to figure
out that the daemon has, indeed, finished, and in how much
Hi all,
I've been bad. I know I have. This goes against any instinct that I
have, but I am failing to see a good reason WHY.
The setup - I have an embedded system that is composed of several
daemons. The situation is that one of the daemons has to restart another
daemon. The restarted
Valery Reznic wrote:
What about following:
#!/bin/sh
while :; do
snmp_agen
done
A daemon returns immediately. Even had that been what I wanted (it's not
- sometimes we really want to shut down the agent) what you wrote is a
busy loop that keeps trying to launch the agent.
Shachar,
What you need is the functionality of a watchdog.
HA clusters provide this functionality. Anyhow, I guess you don't have/need
an HA cluster, so what you might want to look at is monit:
http://mmonit.com/monit/
I understand that you want to monitor it using your own daemon, but I don't
--- On Sun, 2/1/09, Shachar Shemesh shac...@shemesh.biz wrote:
From: Shachar Shemesh shac...@shemesh.biz
Subject: ptrace in production systems
To: linux-il linux-il@cs.huji.ac.il
Date: Sunday, February 1, 2009, 3:42 PM
Hi all,
I've been bad. I know I have. This goes against any
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
--- On Sun, 2/1/09, Shachar Shemesh shac...@shemesh.biz wrote:
From: Shachar Shemesh shac...@shemesh.biz
Subject: Re: ptrace in production systems
To: valery_rez...@yahoo.com
Cc: linux-il linux-il@cs.huji.ac.il
Date: Sunday, February 1, 2009, 4:18 PM
Valery Reznic wrote:
What
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
Yedidyah Bar-David wrote:
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.
The very fact you bundle ltrace into it suggests that ptrace is not the
On Sunday, 1 בFebruary 2009, Shachar Shemesh wrote:
Then again, it is a daemon. It has no parent (well, init is its parent).
It's not clear from your description (or your replies to other posters)
why you don't want init to babysit this daemon. So I'll explore two
possibilities:
1. The daemon
Oron Peled wrote:
On Sunday, 1 בFebruary 2009, Shachar Shemesh wrote:
Then again, it is a daemon. It has no parent (well, init is its parent).
It's not clear from your description (or your replies to other posters)
why you don't want init to babysit this daemon.
Because I do not want
14 matches
Mail list logo
