On Wed, 26 Jan 2005, Csillag[iso-8859-2] Tamás wrote:

> On 01/25, Vincent Danen wrote:
> > 
> > Odd thing here is that I tried a few other apps that were 
> > dietlibc-compiled and didn't see a problem.

That would depend on which functions were called, I would think.

> > Hmmm... spoke too soon.  None of the services requiring tcpsvd were 
> > installed, so I tried with rsync and if I start supervise on those 
> > services, nothing happens.  But if "sh -x run" myself, I can see the 
> > services are starting.  Not sure if recompiling ipsvd without dietlibc 
> > will help, but it's something I'll have to try.
> You cannot predict when will it happen.
> In fnord-cgi it only happend when it executed the cgis. I blamed myself
> that something is missing inside it's chroot, but it worked well if I
> ran it 'strace -f' (I mean fnord).
> 
> In runsv when you signal a service runsv itself gets killed, and
> runsvdir will restart it (you can see that log -service has the same
> 'uptime' as the supervisioned process).

That would suggest to me that the service is relaying the signal to its 
process group, and that process group includes the supervising runsv. 
Apache2 is known to do this, for instance.

Note that runsvdir will not restart the previously running service if 
runsv dies and there is a down file present.

I still think that it would be better for runsv to protect itself from 
such errors by creating a new process group before it execs "run".

---
Charlie