Re: Linux Installation

On Fri, 14 Aug 1998, Nils Myklebust wrote: > On Fri, 14 Aug 1998, Rob Zook <rzook@informix.com> wrote: > >Nils Myklebust wrote: > >> On Fri, 07 Aug 1998, Pieter Huyser <pieter@netsys.co.za> wrote: > >> >I have installed the Informix on a Linux 2.0.0.0 Slackware release. > >> > > >> >Only problem that I have is that when I run any program that connect > >> >and then disconnect to/from the database a zombie process then > >> >appears in the process table. > >> > > >> >Any ideas what is wrong ? > >> > >> Yes, it's a bug that's reported to Informix and we assume it'll be > >> fixed in the next maintenance release. Normally it should be out > >> within a month or so, but we don't know yet how Informix will handle > >> this. > >> I don't know of any workarround. May be others do? > > > >Here's a kludgie kind of workaround, create a cron job which > >periodically kills the sqlexecd process and > >restarts it. Killing the sqlexecd process gets rid of any sqlexec > >zombies. > > That sounds very dangerous if you do it while programs are executing. No - killing sqlexecd should not be dangerous. Killing sqlexec would be lethal, and could easily corrupt a database, especially if you have transactions on it (because the transactions would not be rolled back). Now, the safety of killing sqlexecd does depend on whether the signal sent to it is also sent to its children. With just a small modicum of luck, the signal is not relayed to the children, but you'd need to read the manuals rather carefully and monitor (1) what sqlexecd does when it daemonizes itself and (2) what sqlexecd does after forking to isolate the sqlexec from its parent process and (3) what the sqlexec program does to isolate itself from its parent process. > In bad situations you may even corrupt your database although we have > found Informix SE to be very resistent against any form of corruptions. Yes; as long as you leave the sqlexec processes alone, SE is incredibly resilient. On the zombie issue, here's some speculative code (untested on Linux) which might relieve the problem. On SVR4, if the process ignores SIGCHLD, then no zombies are created. How about trying a wrapper program for sqlexecd which ignores SIGCHLD and then executes sqlexecd: #include <signal.h> #include <unistd.h> #include <stdio.h> int main(int argc, char **argv) { signal(SIGCHLD, SIG_IGN); execv(argv[1], &argv[1]); fprintf(stderr, "Failed to execv() %s\\n", argv[1]); return 1; } You could replace the execv() with an execvp() if desired, but it is not likely to be all that helpful. Compile this code as nozombie and then run it as: nozombie $INFORMIXDIR/lib/sqlexecd [servicename] I think it's worth a try -- it will work unless sqlexecd explicitly reenables child termination signal handling or Linux doesn't support the SVR4 model for handling SIGCHLD and zombies (which is unlikely since it is definitely part of Unix-98 and probably part of POSIX.1). Does Linux have an equivalent to truss which would tell you whether sqlexecd is calling the signal handlers to set a handler for SIGCHLD? Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn