On 02/11/10 18:49, Brian Phillips wrote:
> Hello - I recently discovered that when we do a DBI->connect to an Oracle
> database, the process no longer responds to SIGINT signals. I'm not sure if
> it's something in DBD::Oracle (I can't find anything messing with $SIG{INT})
> or something in the Oracle client itself but the fix is relatively simple
> and I'm hoping it can be included in DBD::Oracle (unless there's a downside
> I'm not seeing).
>
> Here's some code that illustrates the problem:
> http://gist.github.com/660058#file_dbd_oracle_sigint_fail.pl
I'm not sure it illustrates what you describe for me. I changed all those warn
calls to print and added a few more prints and get:
forked 22958 from 22957, press <ENTER> when ready to try killing
connecting... (22958)
connected in child (22958)
iteration 1
waitpid returns 0
process still present
iteration 2
waitpid returns 22958
waitpid returns -1
So as far as I can see the child died and your example (for me) never gets the
the code:
print "terminating...\n";
kill TERM => $pid;
I am running on Linux Ubuntu 9.10 (karmic) with Oracle 11.1 server (on a remote
centos machine) and instant client 11.2.
Presumably this does not happen for you. Perhaps you could tell us which
platform, oracle client etc you are using and modify your script to show a
little better the route it takes for you.
> Basically, the forked child process discards the SIGINT signal once it's
> done a DBI->connect.
>
> The workaround seems fairly simple (a single-line change from the above:
> http://gist.github.com/660058#file_dbd_oracle_sigint_works.pl):
>
> {
> local $SIG{INT}; # make sure $SIG{INT} returns to normal after we
> leave this block
> $dbh = DBI->connect('dbi:Oracle:mydb', 'user', 'password');
> warn "connected in child ($$)\n";
> }
>
> Is this something that would be appropriate to go in the
> DBD::Oracle::dr::connect
> sub? I have not checked any other signal handlers besides INT and TERM (TERM
> seems to work fine) but perhaps it'd be better to localize the entire %SIG
> hash:
> local @SIG{ keys %SIG };
>
> Thoughts?
> Brian
>
>From time to time something similar to Brian's post turns up on this list
>although it is usually something to do with pipes not working as you expect.
I have to say I would be strongly against returning all signals to their
original state after a connect call. I know for a fact that some oracle clients
(depending on how you connect to Oracle) install a SIGCHLD handler for
instance. Who is to say what operations in the Oracle client library might be
rendered useless if we destroy any signal handlers it has set up.
Is it really worth changing DBD::Oracle for what effectively is a one liner?
Perhaps some better documentation on connect would suffice once we get to the
bottom of Brian's observation.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
