<tt>> regarding the flat ndo2db init script with it's tough "killall > ndo2db..." I reviewed the signal processing in ndo2db. > > Intro: > As we know ndo2db forks first to become a daemon, no problem up to here, > and forks again for each client connection. > Each client connection has the daemon as session leader but if we send > this leader a SIGTERM the parent process is exiting, deleting the > socket, cleaning up and 'over and out'. > Bad thing: The forked connection child is still alive, hanging around in > read() from the (non existing) socket descriptor. </tt> <tt>In my opinion ndo is totally missing a proper handling of itself and</tt> <tt>its children. What you describe is just a designflaw in my eyes.</tt> <tt>What ndo2db should have:</tt> <tt>- a pidfile handling via /var/run</tt> <tt>- a subsys handling via /var/lock/subsys</tt> <tt>So it makes it easier to identify ndo2db processes and handle them</tt> <tt>properly.</tt> <tt>If ndo is getting pushed again now, I'm more then happy to contribute</tt> <tt>my init script, which is much more sophisticated then the usual</tt> <tt>one. Put it to good use :) I'll attach it as file, so the indenting</tt> <tt>doesn't get broken.</tt> <tt>But - I wrote it for RedHat Enterprise Linux 5 and I am not sure</tt> <tt>how well it works on other distributions. I always wanted to take</tt> <tt>a look into that, but I'm currently under too much pressure at work</tt> <tt>here.</tt> <tt>Regards</tt> <tt> Sascha</tt> GFKL Financial Services AG Vorstand: Dr. Peter Jänsch (Vors.), Jürgen Baltes, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522