Re: HELP! runaway sqlexec

} ijk@cbnewsh.cb.att.com (ihor.j.kinal) writes: } In article <255g3nINNa7b@emory.mathcs.emory.edu>, bill@tardis.co.uk (William Hails) writes: } > } > Why not hook in a C function, `on begin' in a form, or called from main } > in 4gl or esql/c or whatever is appropriate which installs a catcher } > for SIGHUP which in turn does an sqlexit()? On second thoughts, } > shouldn't informix do this for you? Anyway: } } [...] } } I assume that the software already does that. There are, } however, several possibilities that come to mine. } } We have seen lately our interface to DATAKIT [ a networking } product that our users come in on] itself dies [for whatever } reason]. This has caused us other problems when the user } exits [like the utmp file not being cleaned up, so we still } think the user is logged in]. Since this is the NORMAL parent } to the user process, I assume that it has the code that } signals the SIGHUP to the children. [I presume that } INIT doesn't - I might be wrong, since I'm not that familiar } with the internals of UNIX]. I could guess that the sqlexec/turbo might well ignore SIGHUP, also remember that an uncaught signal doesn't result in a normal exit(). Thinking about it though, how does the engine normally determine that the parent has gone away? SIGPIPE? Then that would work here as well, without needing to explicitly catch anything. } } Secondly, assuming that the parent is still functioning, } possibly somehow more than one SIGHUP signal is generated??? } [This is pure speculation]. In that case, if I remember } correctly, the SIGNAL handling immediately defaults, and } the second signal would kill process. } Depends on the O/S. BSD differs from SysV in this respect I believe. Anyway there shouldn't be more than one SIGHUP generated. } Finally, what if it's not a SGHUP, but instead, the } user hits delete or quit? Again, if the signal handling } code does not have an ignore at the top of the function, } a second signal would kill the parent. Even if there is } such a call, A SMALL WINDOW EXISTS (before the SIG_IGN } takes effect) where a second signal could kill the parent process in } such a case. I'm not sure of any way around this, except possibly } intercept the exit call, and make sure that sqlexit is called. Valid point, I think, but then you don't really want to ignore these signals, you want to do a clean shutdown, however you're right that my example should probably ignore the signal once it's caught, just in case. } } I'm not sure how to do that in C - code your own exit rtn? } [It can easily be done in C++, since you'd just have a } destructor called. Hmm, I guess you could code a simple } test case, and see what it calls and use that]. There is an on_exit() in SunOS, which allows you to push cleanup routines to run before the process exits, but I don't think any normal exit processing is done for an uncaught signal anyway, so C++ would exhibit the same behaviour. Maybe, just maybe, it's adequate simply to call exit() on catching the signal, assuming that Informix library code has installed a cleanup routine. =========================================================================== | Bill Hails <bill@tardis.co.uk> | | | C.L.I. Connect Ltd. | README: permission denied | | 19, Quarry St., Guildford, Surrey | | | GU1 3UY. Tel (UK) 0483 300 200 | | ===========================================================================